When you do not need an agent

"Agent" has become the word for almost any system that calls a model more than once, and the looseness is expensive. An agent, defined properly, holds state across steps, chooses its next action from that state, and acts inside your systems with permissions to do so. Each of those three properties makes a system harder to test, harder to audit and harder to take through a governance review than a fixed pipeline with a model doing one step inside it. A large share of the requests that arrive asking for an agent describe a workflow that needs none of the three.

The tell is the sequence. If the task follows the same three or four steps in the same order every time, and the model is needed for one of them (extracting fields from a letter, classifying a request, drafting a reply for a person to check), it is a pipeline and should be built as one: a scheduled job or an API endpoint, a deterministic script around it, and the model called once with a fixed prompt and a schema it must return. An agent earns its place only when the next action genuinely depends on what the previous one revealed, and when that dependency cannot be written out as a flowchart anyone would maintain.

Determinism is worth more than it looks. A script does the same thing given the same input, so it can be tested against a fixed set of cases and the tests mean something; its failure modes are the ones its author wrote; its logs record what it did rather than what it decided; and it costs the same to run on Thursday as it did on Sunday. An agent that chooses its own route spends tokens reasoning about what to do next on every run, produces a different trace each time, and fails in the places its author did not anticipate, often quietly, by completing the task in a way nobody asked for. For a back-office workflow that runs ten thousand times a month, that difference is the whole budget.

Permissions are where the cost appears in governance. A pipeline needs credentials for the systems its steps touch, and those credentials can be scoped to exactly those steps. An agent that chooses its own actions needs credentials broad enough for whatever it might choose, which is the opposite of least privilege, and it needs a human checkpoint before anything consequential: a payment, a change to a record, a message sent in the organisation’s name. SDAIA’s AI ethics principles ask for accountability, human oversight and reliability from deployed systems, and the NCA’s controls on identity and access management apply to a software identity as they do to a person. The more a system decides for itself, the more evidence a review will ask for that it decided correctly, and the harder that evidence is to produce.

The mistake is expensive in a specific way. An agent built to wrap a fixed sequence carries the agent’s overhead with none of its benefit: more tokens per run, more places to fail silently, a harder audit, and permissions broader than the task required. It is a worse system than the pipeline would have been, and it usually costs more to keep running than anyone budgeted, because the cost scales with reasoning rather than with work done.

Where an agent is the right shape, the discipline is explicit. The orchestration is written out, so the states and the transitions between them can be inspected; the tools the agent may call are typed, with the permissions each one carries; the evaluation set is built from production cases before the build starts and run on every change; every run leaves a trace; and the points at which a person must approve before the system continues are agreed during scoping rather than added after the first incident. Built that way, an agent can pass the same review a pipeline would.

Part of scoping any automation is saying, when it is true, that what was described as an agent is a workflow, and pricing it as the smaller job it is. The tasks that need an agent have branching that cannot be flattened, consequences if they go wrong, and a person in the loop before anything material happens. Everywhere else the simpler architecture is the correct one, and the organisation that chose it will find it easier to explain to its board, its regulator and its own engineers.