When is an agent the wrong shape for a problem?

The test is whether you can draw the flowchart

Take the twenty requests your system will most often receive and try to draw the steps for each. If the same handful of shapes covers nearly all of them, you do not have an agentic problem; you have a workflow with two or three places where judgement is required, and the right architecture is a fixed pipeline with a model call at those places. Classify the request, extract the fields, retrieve, generate, validate, act. Every edge is code you wrote, every step has a known input and output, and the model is doing the part that genuinely needs a model.

Teams reach for a planning loop instead because it feels more general and because it demonstrates well. The demonstration is misleading: an agent that finds its way through a task in eleven steps looks impressive precisely because you did not have to specify the eleven steps, and the same property is why you cannot predict what it will do on the twelfth request.

What the loop costs, stated plainly

Reliability compounds against you. Suppose each autonomous step is right ninety-five per cent of the time, which is generous for a step that involves choosing a tool and constructing its arguments. Ten such steps give roughly a sixty per cent chance that the whole run is clean, from an assumption most people would call good. The pipeline does not escape per-step error, but its steps are mostly deterministic code, and the two or three model calls it does make are narrow enough to evaluate individually and constrain with a schema. Autonomy is the multiplier, not the model.

Cost and latency stop being predictable. A pipeline's cost is roughly the sum of a known set of calls; an agent's cost is a distribution with a long tail, because context grows with every tool result and every step re-sends it. Latency has the same shape, which matters a great deal if a human is waiting.

Testability is the one that hurts a year in. A pipeline stage has a signature, so you can write cases for it, mock its neighbours, and get a failure that points at a line. An agent's behaviour is a property of the whole loop, so your tests become end-to-end trajectory evaluations that are slow, expensive, and non-deterministic enough that a real regression and a reroll are hard to distinguish. Debugging inherits the same problem: a wrong answer from a pipeline localises to a stage, whereas a wrong answer from a run is a transcript to read, and the mistake is often three steps upstream of where it became visible.

And there is a governance cost worth naming in a design interview. A fixed pipeline has enumerable side effects — you can list every write it can perform. An agent with a tool set has a reachable action space you can bound only by policy, which makes the review conversation with security and compliance substantially longer.

The signals that do warrant an agent

Be specific, because "the task is complex" is not one. The honest indicators:

• The sequence of tool calls cannot be enumerated in advance. Not merely branching — genuinely open-ended, where the number of steps and their order depend on what earlier steps returned, and the space of plausible sequences is too large to encode.
• The environment verifies the work. A test suite, a compiler, a type checker, a schema validator, a query that either returns rows or does not. When failure is legible to the loop, iteration converges; when the only judge is the model's own opinion, iteration mostly produces confident drift.
• The search itself is the task. Investigation, triage across unfamiliar systems, exploration where the answer's location is unknown.
• The input space is genuinely unbounded, as with an open-ended user instruction rather than a known set of intents.

Two of those together is a strong case. Open-endedness without verification is where agents look best in a demonstration and behave worst in production, because nothing in the loop can tell the difference between progress and plausible nonsense.

The middle is where most good systems live

The choice is not binary, and presenting it as such is the weakest form of this answer. A router that classifies a request and dispatches to one of six fixed pipelines handles variety without autonomy. A plan-once architecture asks the model for a plan, validates that plan against what is permitted, and then executes it as a deterministic sequence — you get flexibility at one point and auditability everywhere else. A directed graph of steps with model calls at a few nodes covers a surprising amount of ground. A constrained state machine where the model chooses the transition, from a small legal set, gives adaptivity with a bounded reachable space.

A good rule is to spend autonomy where it buys something and nowhere else. If retrieval, validation and the final write are pinned down, letting the model decide only which of four investigative tools to try next is a small, testable freedom. Most systems described as agentic in production are this, and describing yours accurately is worth more than the label.

How to settle the argument rather than have it

Build the fixed pipeline for the common cases first, measure what fraction of real traffic it handles correctly, and look at the residue. If the failures are cases you could add a branch for, add the branch. If they are cases whose shape you cannot anticipate, you have found your evidence for a loop — and you now have the pipeline to fall back to, which is a better position than having only the loop.

When you do compare, compare on the four axes together: success rate on a held-out set of real requests, cost per resolved request, ninety-fifth percentile latency, and the effort to diagnose a failure. Agents frequently win on the first while losing badly on the rest, and a decision made on success rate alone is the reason so many of these systems get rewritten as pipelines eighteen months later. Saying that in an interview reads as someone who has done the rewrite.