Agent demos succeed because they are three steps long. Production agents are twenty steps long, and they fail somewhere in the second half — usually after the expensive work is already done.
The failure is structural, not intellectual
When a run dies at step nine, the model is rarely the problem. The problem is that step nine assumed something step four established, and nothing wrote that assumption down. The run holds its state in the conversation, the conversation exceeds its budget, and the earliest, most load-bearing decisions are the first to be squeezed out.
Three failure modes account for most of it:
- Lost premise. A decision made early is no longer visible when it matters.
- Non-idempotent retries. A step is retried and does its work twice — two invoices, two branches, two emails.
- Partial commitment. A step half-succeeded, and there is no record of which half.
Write the intent before the side effect
The single highest-value change is ordering. Most agent loops act and then record what happened. Invert it: record what you are about to do, with an idempotency key, then do it, then record the outcome. A crash between the intent record and the action leaves a resumable run. A crash after the action leaves a run that can tell whether the work landed.
This is not novel — it is the outbox pattern from distributed systems, and it applies unchanged. The novelty is only that the caller is a language model.
Make every tool idempotent or make it approve
Retries are not optional; models produce malformed calls, networks fail, rate limits bite. So every tool has to be safe to call twice, or it has to be gated by something that is called once. In practice this means a natural key on writes — a stable identifier the agent computes from the work itself rather than a random one — so that a duplicate call collides instead of duplicating.
Where you cannot make an operation idempotent, put a human in front of it. That is not a failure of automation; it is the correct place to spend attention.
Compensate, don’t pretend to roll back
Agents touch systems that have no shared transaction. You cannot roll back an email. What you can do is write a compensating action for each irreversible step and record enough to run it: the message id, the created record, the branch name. A run that fails at step nine should be able to walk backwards through seven compensations and leave the world roughly where it started.
The important discipline is honesty about which steps are reversible. Systems that claim rollback they do not have are more dangerous than systems that admit they are one-way, because people plan around the claim.
Budget the context like memory
Long runs die of context exhaustion as often as logic errors. Treat the window as a cache with an eviction policy you chose deliberately: pin the goal and the constraints, summarise completed phases into short factual records, and keep raw tool output out of history unless a later step needs it. If a step needs detail from step four, it should re-read it from state, not scroll back for it.
What to take away
Reliability in agent systems comes from the same places it comes from everywhere else — durable state, idempotent effects, explicit compensation, honest failure. The model is a very good planner attached to a very forgetful process. Build the process so forgetfulness is survivable.