When you do not need an AI agent

Many requests for an AI agent describe a fixed workflow that a simple script would serve better. Choosing an agent where a pipeline would do makes the system harder to test, harder to audit and more expensive to run, so the difference matters before anything is built.

What makes a system 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, remembers what happened in earlier steps, chooses its next action from that, and acts inside your systems with permissions to do so. Each of those three features makes a system harder to test, harder to audit and harder to take through a governance review than a fixed sequence of steps (a 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.

How do you tell a workflow from an agent?

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 simple script around it that always does the same thing, and the model called once with fixed instructions and a fixed format for its answer. 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.

Why does predictability matter so much?

Predictability 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 pays for the model to think 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.

What does an agent cost in permissions and governance?

Permissions are where the cost appears in governance. A pipeline needs credentials for the systems its steps touch, and those credentials can be limited 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 giving each system only the access it needs, and it needs a person to approve before anything that matters: a payment, a change to a record, a message sent in the organisation’s name. Widely used AI ethics principles ask for accountability, human oversight and reliability from deployed systems, and security 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 model usage 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.

When is an agent the right choice?

Where an agent is the right shape, the discipline is explicit. The steps it can take are written out, so they and the moves between them can be checked; the tools the agent may use are clearly defined, with the permissions each one carries; a set of test cases is built from real work 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 at the start rather than added after the first incident. Built that way, an agent can pass the same review a pipeline would. Our use case library shows tasks where an agent fits and who approves each step.

Part of planning 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 real choices at each step that cannot be written as a simple list, consequences if they go wrong, and a person who approves before anything important 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.