What can AI agents do for business operations, really

Every operations lead has now been shown a demo where something called an agent reads an inbox, decides what to do and does it. The demo works. The question nobody answers in the demo is which of your actual processes that approach suits, and the honest answer is a minority of them.

That is not scepticism about the technology. It is the position taken by the engineering teams building agent systems. Anthropic's guidance, drawn from work with dozens of teams building these things, recommends you find the simplest solution possible, and only increasing complexity when needed, and then says the part a vendor never will: this might mean not building agentic systems at all.

So the useful framing is not what agents can do. It is which of two shapes your process is, because they cost differently and fail differently.

The distinction that decides the build

The word agent is used for two quite different things, and conflating them is why projects come in at three times the estimate.

A workflow, in the engineering sense, is a system where LLMs and tools are orchestrated through predefined code paths. You decide the sequence. The model does the judgement at specific points you chose: classify this, extract that, draft this reply. If it misbehaves, you know which step.

An agent is the other thing: LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks. You give it tools and a goal, and it decides the order. That is genuinely more capable and genuinely harder to predict, bound and bill for.

The guidance puts the trade off in one line each way: workflows offer predictability and consistency for well-defined tasks, while agents are the better option when flexibility and model-driven decision-making are needed at scale.

Most business operations are the first kind. Invoice arrives, fields come out, record goes in, exception goes to a person. There is nothing to decide at runtime, so paying for a system that decides at runtime buys you variance you did not want.

What the composable patterns actually are

Before anyone builds an agent, there are five documented workflow patterns that cover most of what operations teams ask for. Named plainly: prompt chaining, routing, parallelisation, orchestrator-workers, and evaluator-optimizer.

• Prompt chaining: break one hard step into several easy ones, each checkable. Most document processing is this.
• Routing: classify the input, then send it down the right specialised path. Shared inbox triage is this.
• Parallelisation: run independent subtasks at once, or run the same task several times and take the consensus.
• Orchestrator-workers: a model splits a task it cannot size in advance, workers do the pieces. This is the first pattern that starts to feel agentic.
• Evaluator-optimizer: one pass produces, another critiques against criteria, repeat. Useful where quality is judgeable but not specifiable.

The practical value of knowing these names is negotiation. When a proposal says agent and the task is routing, you are being quoted for the expensive shape of a cheap problem. The guidance is blunt about the baseline too: for many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough.

Where an agent earns its cost

There is a real set of operations tasks that suit an agent, and they share a property: you cannot write the sequence in advance because the sequence depends on what the system finds.

A supplier query that might need the order history, or the delivery note, or the credit terms, or all three, depending on what the first lookup returns. A reconciliation where the number of places to check varies per discrepancy. A research task across internal systems where the second question depends on the first answer. In each of these, hard coding the path means hard coding every branch, and the branches outnumber the cases.

What makes these buildable rather than theoretical is two constraints the guidance names explicitly. Agents can then pause for human feedback at checkpoints or when encountering blockers, and it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control.

Treat both as requirements rather than features. An agent with no iteration cap is an unbounded bill, and an agent with no checkpoint is a system taking actions nobody approved. In an operations context the checkpoint is usually the only reason the thing is deployable at all, and it is the same principle as the review step in AI email triage for shared inboxes.

The tools are the build, not the model

The part that surprises people commissioning this work: almost none of the effort goes into the model, and most of it goes into the tools you hand it. A tool here means a defined action against your systems, read an order, create a ticket, post a journal entry.

Anthropic's guidance on writing those tools is specific and worth holding a supplier to. Make sure each tool you build has a clear, distinct purpose, and resist wrapping every existing API endpoint, because too many tools or overlapping tools can also distract agents from pursuing efficient strategies.

Two details from the same guidance tell you whether a build is serious. Responses have to be bounded: for Claude Code, Anthropic notes they restrict tool responses to 25,000 tokens by default, with pagination and filtering rather than returning everything. And errors have to teach: they should clearly communicate specific and actionable improvements, rather than opaque error codes or tracebacks.

If a proposal has no answer on either point, it has not been built before. A tool returning an entire table and a tool returning "error 500" are the two most common reasons an agent loops expensively and then gives up.

How you would know it works

The thing that separates a deployed agent from a demo is an evaluation, and the guidance is direct: building an evaluation allows you to systematically measure the performance of your tools, using realistic multi-step tasks, tracking runtime, tool call counts, token use and errors.

In practice that means collecting thirty or forty real cases from the last quarter, with the right answer attached, before anything is built. It is unglamorous and it is the only way to tell an improvement from a change. One warning from the same source applies directly here: avoid overly strict verifiers that reject correct responses due to spurious differences, because a grader that marks a right answer wrong for formatting will send the whole project chasing the wrong fix.

The ROI side of this is a separate discipline and an easy place to fool yourself, which is the subject of measuring ROI of AI automation honestly.

The honest limits

Three things we will not tell you.

We will not give you a percentage for how much work an agent removes from an operations team. There is no credible general figure, the numbers in circulation come from vendors measuring their own best cases, and the honest answer depends entirely on how much of your process is decision and how much is transcription. The second kind automates well and was already automatable before any of this.

We will not tell you an agent is the right build for most operations work. On the evidence of the guidance written by people who build them, it is not. Most of what gets asked for here is routing or chaining with a human checkpoint, and that is a cheaper, more predictable system that will still be running next year. The sibling question of when custom software is justified at all is in signs you need custom software.

And we will not pretend the human checkpoint is temporary. The pattern where a person approves before an action commits is not scaffolding to be removed once accuracy improves. It is the control that makes the system acceptable to the people whose work it touches, and the same holds for the document side of this, covered in AI document processing and where it still needs a person.

What is solid enough to plan against: the workflow and agent distinction is real and changes the cost, five named patterns cover most operations requests, agents need a stopping condition and a checkpoint, the tool definitions are the bulk of the build, and nothing is deployable without an evaluation set you made from your own cases. A scoring model is a good first candidate precisely because it is checkable, which is the case made in AI lead scoring for sales.