When to use an agent and when to use a script

Agents are useful when the sequence of steps cannot be known in advance. When it can, an agent is a slower, more expensive, less predictable way to run a script.

This sounds obvious stated plainly. It is worth stating because the current default runs the other way: teams reach for an agent first and discover the determinism problem in production, at which point the agent is load-bearing and hard to remove.

The distinction that matters

A script encodes a decision you already made. An agent makes the decision at runtime. That flexibility costs latency, tokens, and determinism, and it is worth paying only when the decision genuinely cannot be made ahead of time.

A useful test: can you draw the flowchart? If you can, write the flowchart. Reaching for an agent to execute a known sequence adds a nondeterministic layer between you and an outcome you already understand.

The test has a failure mode worth naming. Sometimes you can draw the flowchart but it has forty branches, and writing it feels worse than delegating to an agent. That instinct is usually wrong. Forty branches you can enumerate are forty branches you can test. An agent replaces them with a decision process you cannot enumerate, which is a different thing from simplifying them.

The genuine case for an agent is not that the branches are numerous. It is that you cannot list them.

The middle ground

Between a script and an agent sits an option that gets skipped: a single constrained model call inside otherwise deterministic code.

Classification, extraction, summarisation, and format conversion are model-shaped problems with script-shaped control flow. The model handles the part that resists rules, and the surrounding code does everything else. One call, no loop, no tool selection, no planning step.

This covers a large share of what gets built as an agent. If your agent makes one model call and then stops, it was never an agent — it is a function with an unnecessary framework around it. Removing the framework makes it faster, cheaper, and easier to test.

Reach for the loop only when the second call depends on what the first one found.

Where agents earn their cost

Agents fit when the input space is open and the path depends on what is found along the way.

Investigating a failure, where each finding determines the next thing to check. You cannot pre-specify the sequence because the second step depends on what the first one turned up.

Research across sources whose structure is unknown until opened. A script can fetch a known endpoint; it cannot decide that a document is irrelevant and try a different source.

Tasks where the number of steps varies by an order of magnitude between runs. If one input needs two operations and another needs sixty, fixed control flow either wastes work or truncates it.

The common thread is that enumerating the branches in advance would be impractical, not merely tedious.

Where scripts win

Fixed transformations, scheduled jobs, and anything whose correctness you need to guarantee. If the same input must always produce the same output, an agent is the wrong tool. Determinism is a feature, and agents trade it away by design.

Cost compounds too. A script that runs a thousand times a day costs the same each time. An agent doing the same work re-derives its plan on every run, paying for reasoning that produced an identical conclusion the previous nine hundred and ninety-nine times.

Latency follows the same pattern. A script's runtime is roughly fixed. An agent's varies with how many steps it decides to take, which makes it awkward to put in a request path where someone is waiting.

They fail differently

This is the operational difference and it gets underweighted.

A script fails at a known line, with a stack trace, in a way that reproduces. You fix it once and it stays fixed.

An agent fails by making a defensible-looking wrong decision partway through a sequence. There is no stack trace, because nothing threw. Reproducing it may not be possible, because the same input can produce a different path. And the fix is a change to instructions or tools whose effect on other cases is not obvious.

This means agents need observability that scripts do not: a record of each step, the reasoning, the tool calls, and the results. Without it, debugging is guesswork. Build that before the agent handles anything that matters, because retrofitting it means reproducing failures you cannot reproduce.

The hybrid case

Most real systems want both. An agent decides what needs to happen and then calls deterministic tools to do it. The agent handles the open-ended part; the scripts handle the parts where you need a guarantee.

The design question is where to draw the line, and there is a reliable heuristic: anything worth being certain about belongs in a tool the agent calls, not in the agent's reasoning.

If a calculation must be right, do not ask the model to perform it — give it a function. If an operation is destructive, do not let the agent construct the command — give it a tool with constrained parameters. If a sequence must always run in order, make it one tool rather than three the agent could call out of order.

Each of those moves work out of the nondeterministic layer without giving up flexibility, because the agent still decides whether and when to call them.

Migrating between them

The choice is not permanent, and the useful direction is agent to script.

Start with an agent when the problem is genuinely open. Log the paths it takes. If it turns out that ninety percent of runs follow the same three sequences, those sequences are now the flowchart you could not draw at the start. Encode them as scripts and let the agent handle the remainder.

This works because the agent doubles as a discovery mechanism. What it cannot do is stay the permanent implementation of a path you now understand.

The shape most durable systems converge on is a thin layer of judgement over a thick layer of things that behave the same way every time — and the layer of judgement gets thinner as you learn what the system actually does.