When an AI agent is the wrong answer

I have built agentic systems that won competitions and agentic systems I later tore out and replaced with a hundred lines of ordinary control flow. The second kind taught me more.

An agent is a model deciding, at runtime, what to do next. That is genuinely powerful when you cannot know the sequence of steps in advance. It is a liability when you can, because you have replaced deterministic code with a probabilistic planner that occasionally picks differently.

The test

Write down the steps needed to handle a typical request. If you can write them down, you do not need an agent — you need a pipeline that calls a model at the steps requiring language understanding. If the steps genuinely depend on what earlier steps discover, and the branching is wide enough that enumerating it is unreasonable, an agent is earning its place.

What you give up

• Predictable cost. An agent that loops three times costs triple. Occasionally it loops eleven times.
• Predictable latency. Users tolerate four seconds. They do not tolerate four seconds sometimes and forty seconds otherwise.
• Debuggability. A failed pipeline has a stack trace. A failed agent run has a transcript you have to read like a detective.
• Testability. The same input can take a different path on a rerun, which makes assertions awkward and flaky.

A concrete comparison

The data analyst assistant I built lets users upload a spreadsheet and ask questions in plain English. Every request follows the same shape: understand the question, inspect the schema, generate a query, run it, decide whether a chart helps, render the answer.

flowchart LR
    Q[Question] --> U[Understand intent]
    U --> S[Inspect schema]
    S --> G[Generate query]
    G --> V{Valid?}
    V -->|no| G
    V -->|yes| X[Execute]
    X --> C{Chart helps?}
    C -->|yes| R[Render chart]
    C -->|no| T[Render table]

That shape never varies, so there is nothing for a planner to plan. Three model calls sit inside a fixed sequence. It is testable, its cost per request has a ceiling, and when it breaks the traceback names the step.

The campus safety assistant was different. A question might need the code of conduct, or the complaints procedure, or an escalation contact, or two of those and a form — and which ones only becomes clear after reading what the first lookup returned. Enumerating that branching was genuinely unreasonable. That one is an agent, and it should be.

If you do need one

1. Cap the iterations. A hard ceiling on steps, and a defined behaviour when it is hit.
2. Give it few tools. Twenty tools means twenty chances to pick wrong; five well-named ones are chosen far more reliably.
3. Make tools total. Every tool returns a usable result or a clear error the model can act on — never an exception that ends the run.
4. Log every step. The transcript is your only debugger, so treat it as a first-class artefact.
5. Evaluate end to end. Unit tests on individual tools tell you almost nothing about whether the agent completes real tasks.

Agents are a legitimate tool for genuinely open-ended problems. They are also the most fashionable answer in the field right now, which means they get chosen for reasons that have nothing to do with the problem. Being able to say "this does not need one" is worth more than being able to build one.