When a Workflow Beats an Agent

The decision to build an agent is usually made at the wrong altitude. The question that matters is narrower: does the path through the task change from run to run, or only the data? If only the data changes, the path can be fixed, and a fixed path is a workflow.

What actually differs

A workflow can call a model at every step and still be a workflow, because you decided the steps. What you give up by fixing the sequence is the ability to handle inputs whose shape you did not anticipate. What you gain is that every run is the same run, and the same run is one you can test.

Run the task through that diagram honestly and most candidates land on the left.

The blast radius argument

An agent’s blast radius is every combination of tools it can use, in any order. With n tools there are n(n minus one) ordered ways to chain any two of them.

A workflow’s evaluation harness grows roughly with the number of steps; an agent’s grows with the number of reachable states.

Where the engineering time goes

Keep the model, drop the loop

The middle path is a fixed sequence where steps call a model for judgement, but the order never varies. Structured outputs make this reliable.

// the model decides the category — code decides what happens next
const { category } = await classify(input, {
schema: { category: "billing | technical | account" },
});

// no agent, just a switch. every branch is testable in isolation.
return ROUTES[category](input);

Where to land

Start every design as a workflow. Move a step to an agent only when you have tried to enumerate its branches and genuinely cannot — and even then, give it the smallest tool set that does the job. Autonomy you did not need is surface area you now have to defend.