When an agent should just be a workflow

A lot of what gets called an agent is a fixed sequence of steps with a language model deciding, at each step, to do the step that was always going to happen next. It costs a model call per decision, it fails in more ways than a switch statement, and it is harder to test. The label is doing work the architecture is not.

This matters beyond vocabulary. Choosing agency you do not need means paying for it in latency, cost, debuggability and reliability, on every request, forever.

The test

Before building an agent, write down the sequence of steps for the ten most common requests you expect.

If those sequences are largely the same, you have a workflow. Write it as code. Use models inside the steps where the work is genuinely fuzzy — classification, extraction, generation — and let control flow be control flow.

If the sequences genuinely differ, if the second step depends on what the first one returned in a way you cannot enumerate, then dynamic decision-making is earning its cost. That is an agent, and it should be.

What you give up

Dynamic control flow costs more than the extra tokens.

• Testability. A workflow has enumerable paths you can assert on. An agent has a distribution of behaviours, and testing it means sampling rather than proving.
• Debuggability. When a workflow misbehaves, the trace tells you which step. When an agent misbehaves, you are reconstructing why a model chose one branch over another from a transcript.
• Latency. Every routing decision is a model call on the critical path. Deterministic routing is free.
• Predictability. Identical inputs can take different paths. Support burden rises accordingly, because 'it worked when I tried it' is now a normal state of affairs.

None of these are arguments against agents. They are the price, and it is worth paying when the flexibility is real. The mistake is paying it for a sequence you could have written down.

The useful middle

In practice the systems I have been happiest with are not at either pole. They are workflows with bounded discretion: the shape of the process is fixed in code, and within each stage the model has real freedom over how to accomplish that stage.

fixed by code:     stage 1 ──► stage 2 ──► stage 3
                      │           │           │
model decides:     which      which      how to
                   tools,     tools,     summarise
                   what to    whether
                   ask        to retry

The stage boundaries are enforced by the application, not requested in the prompt. If stage three must not run before stage two has completed, the tools belonging to stage three are simply not available yet. Instructing a model not to skip ahead works most of the time, and most of the time is not a useful reliability target for anything that matters.

A note on how this gets decided in practice

The pull toward agents is often not technical. Agent is the word the industry is excited about, and building one feels like building the future, while writing a state machine with three model calls in it feels like ordinary work.

Ordinary work that behaves predictably in production is a better outcome than an architecture that reads well in a diagram.

The honest version of the question is not what would be most interesting to build. It is what the ten most common requests actually need. Usually that is a workflow with good judgement inside its steps — and the parts of the system that genuinely need to reason are easier to identify once everything that does not has been written as code.