Most of Your AI Agents Are Workflows in a Trench Coat

Imagine hiring a senior consultant — brilliant, expensive, billed by the hour — and asking them one question every morning:

“Should we send the ‘your package has shipped’ email?”

They think about it. They check the order status. They weigh it up. Then they say yes, and you pay the invoice.

Nobody would do this. The answer is a lookup, not a judgement. You’d write an if statement and go home.

And yet this is what a surprising share of production “AI agents” are doing right now: a reasoning model, in a loop, with tools, deciding between two or three steps that everyone involved already knew in advance. Paying consultant rates for a yes/no.

I think of them as workflows in a trench coat. Two kids stacked on each other’s shoulders, wearing a long coat, trying to get into an R-rated film. From a distance it looks like an agent. Up close, it’s a fixed sequence of steps with a language model standing in front of it, pretending to decide.

What the disguise looks like

Here’s the tell. Watch what the model is actually choosing between.

If it’s choosing between steps you could have listed before it ran — classify the ticket, look up the account, draft the reply, send it — then the model isn’t exercising judgement about what to do. It’s exercising judgement about which of your pre-written options to take. That’s a routing decision. Routing is a workflow.

The confusion is understandable, because the model is genuinely doing something clever at each step. It’s reading the ticket well. It’s writing a good reply. But “the model does clever work inside a step” and “the model decides which steps happen” are completely different things, and only the second one makes it an agent.

A sharper way to put it, which I’ve borrowed and can’t improve on: if the model is choosing between known steps, you probably built a workflow badly disguised as an agent.

The one question

Everything comes down to a single test, and it fits on a sticky note:

Can you draw the full graph of steps before the model runs?

If yes — if you could stand at a whiteboard and sketch every step and every branch with reasonable confidence — build a workflow. Use a model inside steps where it helps (extraction, classification, drafting). But the shape of the work is fixed, and fixed shapes don’t need a reasoning loop to find them.

If no — if the next step genuinely depends on what the model discovers at the previous one, and you couldn’t have predicted the path — that’s an agent. The structure emerges during execution. Nothing else needs one.

Notice this has nothing to do with how hard the task is. A workflow can be enormous and intricate. An agent can be three steps. The question isn’t complexity. It’s whether the path is known or discovered.

What the trench coat costs you

Wearing the disguise isn’t free. It’s expensive in four specific ways — and if you’ve read my earlier pieces, you’ll recognise every one of them.

It costs five to twenty times more per task. A task that takes one model call in a workflow can take five to fifteen calls in an agent loop, each one re-sending the growing context. That’s the quadratic bill from The Cost of Thinking — and here you’re paying it for flexibility the task never uses.

It’s slower. Every loop iteration is a round-trip to a model. A workflow runs the three steps it needs. An agent reasons about which three steps to run, then runs them, then reasons about whether it’s done.

It’s non-deterministic. The same input can take a different path tomorrow. For a routine task that’s not flexibility — it’s a bug you haven’t seen yet. Compliance and audit teams, in particular, hate this: “the same documented checks, every time” is a workflow property that an agent cannot promise.

It’s harder to debug. When a workflow fails, you know which step failed. When an agent fails, you’re reconstructing what it decided and why — which is the whole reason silent failures are so nasty in agent systems.

Most failed AI projects don’t fail because of a bad model. They fail because someone picked the wrong pattern — and the most common wrong pattern is an agent where a workflow would have done.

When the agent is genuinely earned

None of this is an argument against agents. It’s an argument for spending them where they pay off.

An agent earns its place when the path genuinely can’t be known in advance:

• “What’s driving the churn spike in Q2?” — the analysis explores several dimensions, notices a correlation, digs into it, abandons a dead end. A workflow would have to pre-list every correlation worth checking. It can’t.
• Fixing a bug across a codebase — read, hypothesise, test, read something else, try again. The sequence is shaped by what each step reveals.
• A complex customer escalation — where the right resolution depends on a chain of lookups whose order depends on what each one returns.

The common thread: discovery is the bottleneck. The task is hard precisely because you don’t know the shape until you’re inside it. That’s the only situation where paying for a model to find the path is worth more than it costs.

A good second test, from the practitioner guidance that’s emerged this year: an agent is a fit when the path depends on the input, and a wrong step is cheap to catch, and success can be checked automatically, and users can wait a few extra seconds. Four yeses, build the agent. Mostly noes, don’t.

The middle answer most people miss

The best-kept secret in this whole debate is that it isn’t binary.

Between “pure workflow” and “full agent” sits the pattern most mature production systems actually use: a workflow with an agent inside it. A fixed path you control — with a reasoning loop handed only the one step that genuinely needs judgement.

Your support pipeline is a workflow: receive, classify, route, respond, log. But “respond to a complex multi-system escalation” — that one step — might need an agent. So you give that step an agent, and keep everything around it fixed. You get the agent’s judgement exactly where it’s needed, and the workflow’s determinism, cost and auditability everywhere else.

Most teams find this gives them a better balance than a fully autonomous agent. It also tends to be the answer when the four-question test comes back mixed — some yeses, some noes. Put the agent where the yeses are.

Should this be an agent?

Here’s the whole argument as a tool. Describe the task you’re about to build by answering five questions, and it’ll tell you which pattern fits — and why.

Run it on the thing you’re building this week. If it comes back “workflow” and you’ve already started an agent, that’s worth a moment.

The honest limits

Three places where “workflow first” has a ceiling.

Workflows hit a wall when edge cases pile up. You start with three branches. Then five. Then a special case for one customer, then another. At some point the branch count means the path was never really known — you just hadn’t admitted it. That’s the signal to upgrade the messy step to an agent. Workflow first doesn’t mean workflow forever.

“Draw the graph” assumes you understand the task. Early in a new domain, you may not know whether the path is predictable. It’s fine to prototype with an agent to discover the graph — then, once you can draw it, rebuild the routine parts as a workflow. Use the agent to learn the shape; don’t leave it running the shape once you know it.

Some tasks shouldn’t be automated at all. If a wrong answer is expensive, hard to catch, and hard to undo — and no automatic check can verify success — the honest answer isn’t “workflow” or “agent.” It’s a human with a good tool. The decision tool above has that verdict for a reason.

Spend agents carefully

Agents are the most powerful pattern we have. That’s exactly why they should be spent, not sprayed.

Every agent you deploy is a bet that the task’s path is worth discovering at runtime — a bet paid in cost, latency, and your ability to explain what happened. Make that bet where discovery is genuinely the bottleneck, and it pays off enormously. Make it where the path was known all along, and you’ve hired a consultant to answer yes or no.

Draw the graph first. If you can, you have your answer.