Why agents fail in production

When an agent breaks in production, the first instinct is to blame the model. Usually the model is fine. The failure is somewhere around it.

Here are the failures I see most often described:

• A tool call times out halfway through a multi-step task.
• An API returns a rate limit error and the agent gives up.
• The process restarts during a deploy and the run is lost.
• A write succeeds, the response is lost, and the agent writes again.
• The conversation grows until it no longer fits in the context window.
• The agent loops on the same step because nothing tells it to stop.

None of these are language problems. They are the same problems any distributed system has: partial failure, retries, duplicate work, and lost state.

What this changes

If you accept that, the design priorities shift. The prompt matters, but so do:

• where state lives and when it is saved
• which operations are safe to repeat
• how long each step is allowed to run
• what happens when the process dies

A demo agent can ignore all of this because it runs once, on a good day, on one machine. A production agent cannot.

I will go through these topics one at a time in the next posts. The common thread is simple. Treat the agent as a long-running workflow that happens to call a model, and design it the way you would design any workflow that must not lose work.