What an agent actually is, and why the demos fail

The definition, without the marketing

An agent is a loop. The model gets tools, gets a goal, and on each turn decides which tool to call next. It also decides when to stop. That is the whole thing.

messages = [{"role": "user", "content": goal}]
for step in range(MAX_STEPS):
    r = model(messages, tools)
    messages.append(assistant(r))
    if r.stop_reason != "tool_use":
        return r                      # it decided it was finished
    messages.append(run_tools(r, session=session))
raise StepBudgetExceeded(goal, step)  # loud, not a shrug

Compare that with a pipeline, where *you* decide the steps — extract, then look up, then draft, then send. Same model, same tools. The only difference is who chooses the next move.

That difference is everything, and it is why the demo is beautiful and the production version is a support ticket.

Reliability multiplies

Suppose each step is right 95% of the time. That sounds strong. Over a 20-step run, if the steps depend on each other, you get 0.95 to the power of 20, which is about 0.36. The agent completes correctly roughly one time in three.

This is the single most important fact about agents, and it explains most of what teams observe:

• The demo worked because the demo was four steps.
• A better model takes each step from 95% to 97%, which moves 20 steps from 36% to 54%. Real, but not the difference between broken and shippable.
• Cutting the chain from 20 steps to 6 takes 95% per step to 74% overall, without touching the model.

Shorter chains beat cleverer ones. Every step you can move out of the loop and into deterministic code is a step that cannot fail.

Why failures are hard to see

A long run produces a fluent summary at the end: "I checked the three invoices, reconciled them against the ledger, and flagged one discrepancy." It reads like success. Steps 4 through 7 may have returned nothing useful, and the model wrote around the gap, because writing around gaps is what language models are good at.

Three specific things go wrong and hide:

Silent tool failures. A tool that returns {"status": "ok", "results": []} on an error teaches the model that there is nothing to find. Make failures explicit and make them loud.

No ground truth mid-run. The model cannot tell that step 4 quietly failed. It only sees the text it got back.

Loops. Same tool, same arguments, ten times. Detect repeats and break, rather than paying for the same mistake in a circle.

What actually ships

The useful production systems people call agents are mostly short, constrained loops:

• A hard step budget. Four to eight. When it runs out, raise, do not summarise.
• A cost budget too. Track tokens across the run and stop at a ceiling.
• Few tools, sharply separated. Twenty tools with overlapping descriptions is a routing problem you gave yourself.
• Deterministic checkpoints. After the drafting step, run a real check in code: does the invoice id exist, does the total match, is the recipient in this user's contacts. Do not ask the model whether it did well.
• Reversible, idempotent actions. Draft rather than send. Stage rather than commit. Where an action is irreversible, put a person in front of it.
• A plan first. Ask for the plan, check it in code or with a human, then execute the approved steps. This turns one twenty-step gamble into a checkable decision and a shorter run.

None of this is exciting, and all of it is the difference between something you can leave running and something you have to watch.

When not to use a loop

If you can write down the steps, write down the steps. Autonomy is worth its unreliability only when the sequence genuinely varies with the input and you cannot enumerate the cases. Most features people build as agents are pipelines that were never given the chance to be pipelines.