An Agent Is Not Always The Answer: Scripts, Workflows, And Agents Compared

“Build an agent” has become the default opening move for almost every automation problem. It is also the most expensive one. Not because agents are bad — because most problems teams bring to us do not need a model deciding anything, and paying for that flexibility in cost, latency, and untestability is how a simple automation turns into a system nobody can debug.

There are three layers of automation. They solve different problems, they cost different amounts, and the decision between them is much clearer than it usually gets credit for.

The three layers

A script. A fixed sequence of deterministic steps: read from here, transform it, write it there, on a schedule or a trigger. No model involved. It runs the same way every time, and when it breaks it breaks loudly because there was only one path to break.

A workflow. A deterministic skeleton with a model inside specific joints. The steps are fixed and owned by your code; the model is called where the input is unstructured and the output needs judgement — classify this, extract these fields, summarise this thread, draft this reply. Each call has a defined input, a defined output shape, and a place it can fail.

An agent. The model chooses the sequence. It decides which tool to call next, what to do with the result, whether it has enough information, and when it is finished. The loop is the product.

The difference that matters is not intelligence. It is who chooses the order of operations. In the first two layers, that is you. In the third, it is the model — and that single change is where the cost, the latency, and the difficulty of testing all come from.

What choosing the top layer actually costs

An agent’s flexibility is real, but it is paid for in four places at once.

Debugging changes shape. When a script produces a wrong result, there is one path to read. When an agent does, you have a transcript of decisions that may not repeat identically on the next run — the same input can take a different route. You are now debugging a distribution, not a function.

Testing stops being binary. A deterministic workflow can be regression-tested: same input, expected output, pass or fail. An agent can be evaluated, but “it usually works” is a genuinely different claim from “it works”, and the difference shows up in production, not in the demo.

Cost becomes variable and unbounded by design. A workflow makes a known number of model calls per task. An agent makes as many as it decides to make, which means a task that costs a few cents in testing can cost many times that on an unusual input. That variability is the reason a cost ceiling belongs in the design before the model choice is even made, which we argued at length in why your AI project should start with a cost cap.

And the failure modes get quieter. A script that cannot parse an input throws. An agent that cannot find what it needs may confidently produce a plausible answer instead — which is why an agent without a human review path is a decision, not a default.

The signal that tells you which layer you need

Ask one question first: can you write the steps down, in order?

If yes — the automation is a script, possibly with a model called inside a step or two. That is a workflow, and it should be built that way even if a demo of an agent would have impressed the room more. Being able to write the steps down is not a limitation of the problem; it is a gift. Deterministic code is cheaper, faster, testable, and easier to hand over to whoever maintains it next.

If you cannot write the steps down, the next question is are the branches enumerable? A workflow can carry conditional logic — if the document is an invoice do this, if it is a contract do that. What it cannot carry is a rule you cannot name in advance.

Only when the correct next step genuinely depends on something the system will not see until it is midway through the task are you in agent territory. Research that has to follow whatever it finds. Triage where the routing decision comes from the content itself. Exception handling across a long tail of cases no one has catalogued. If you can name the branches, you do not need a model choosing them.

Escalate. Don’t start at the top.

The trap is starting high because agent work seems like the more serious investment. In practice, teams that start with an agent usually end up rebuilding the deterministic parts anyway — because once the thing is in production and misbehaving, the first fix is always to pin down the parts that did not need to be flexible. The skeleton gets added back, one guardrail at a time.

Going the other direction is far cheaper. A script that hits its limits becomes a workflow by inserting model calls at the joints where judgement is needed. A workflow that hits its limits — a branch you cannot enumerate, an input variety you did not anticipate — grows an agent for the exception path specifically. Each step up is a small, justified change with evidence behind it.

Moving down is a rewrite. Which is why the question is worth asking before the first line of code, not after the first incident.

Most production systems are all three

The honest picture of an automation that has survived contact with real work is usually a hybrid: a deterministic shell that owns the schedule, the retries, the validation and the audit trail; a small number of model calls at the joints where judgement is required; and an agent, if it exists at all, confined to the branch where the path genuinely cannot be predicted. That is the same structure as the five pieces every deployed agent ends up needing, and it is not a compromise — it is the shape that makes the system operable by someone who did not build it.

Four questions for the next automation meeting

1. Can we write the steps down, in order? If yes, it is a script or a workflow.
2. Are the branches nameable in advance? If yes, they belong in code, not in a prompt.
3. What is the correct next step depending on that we only learn mid-task? If nothing, the model should not be choosing.
4. When it is wrong, who finds out, and how fast? If the answer is “nobody”, the layer does not matter yet.

The discipline is not to avoid agents. It is to spend the least complexity that solves the actual problem, and to be able to say why that layer was chosen. That decision — and the ceiling, the review step and the four numbers that go with it — is usually the first thing we work through with a team. If you want the shape of that engagement, it is on our services page.

Picking the wrong layer rarely fails immediately. It fails at the point where the system is too important to turn off and too opaque to fix.