What it takes to put an AI agent into production
An agent demo is a weekend. An agent with real tool access, running unattended against your systems, is a distributed system with a non-deterministic component in the middle of it.
Agents are the most genuinely exciting thing in this space and the easiest to get badly wrong. The gap between a demo and something you would let run against production systems is much wider than it looks, and almost none of that gap is about the model.
The demo hides all the hard parts
In a demo, the agent is given a goal, calls a couple of tools, and produces a good result. The tools respond quickly and correctly. Nothing times out. The task converges in four steps. Somebody is watching.
In production, a third-party API is slow, one call returns a partial result, the agent misreads it and plans a step that does not make sense, retries something it has already done, and takes an action nobody wanted. Nobody is watching, because the entire point was that nobody has to.
Draw the boundary by consequence
The most important design decision is which actions the agent may take alone. I do not draw that line by how confident the model seems — confidence is not correlated with correctness in any way you can rely on. I draw it by what happens if the action is wrong.
Reversible actions run unattended. Anything that cannot be undone — money moving, a message going to a customer, a record being deleted — stops and waits for a person, with the reasoning and the exact proposed action laid out for review.
This sounds like it undermines the automation. In practice it is what makes the automation adoptable, because it lets an organisation say yes to the ninety per cent that is safe instead of no to all of it.
Narrow tools beat broad access
Give an agent database access and you have to reason about every query it could conceivably construct. Give it three specific, typed operations and you only have to reason about three.
Bounding what the agent can do at all — before any reasoning happens — is far more reliable than trying to constrain what it decides to do through instructions. Prompts are a request. Tool scope is a guarantee.
Validate at the boundary
Anything the model produces that another system will consume should be schema-validated before it is acted on. Malformed output should fail immediately and visibly, at the point of generation, rather than propagating and causing a confusing failure three steps later.
This one change removes an entire category of production incidents, and it costs almost nothing to implement.
The unglamorous list
Everything that makes any distributed system reliable applies here, and applies harder because a non-deterministic component is now inside the loop:
- Idempotency — a retried step must not perform its action twice. Agents retry more than you expect.
- Bounded iteration — a hard cap on steps, so a task that cannot converge escalates rather than looping until somebody notices the bill.
- Timeouts and circuit breakers — a slow dependency should degrade the run, not hang it indefinitely.
- Durable state — a task must survive a restart mid-sequence and resume, not start again from the top.
- Full tracing — every step, input, tool call and result recorded. You cannot debug reasoning you cannot see, and you certainly cannot improve it.
- Cost ceilings — per-task and per-day. A looping agent is a financial incident as well as an operational one.
Observability is the feature
The traces turn out to be as valuable for improving the agent as for debugging it. Reading what it actually did on a hundred real cases tells you where the reasoning breaks, which tool descriptions are ambiguous, and which checkpoints are firing so often that the step should just be automated differently.
Teams that build this in early improve steadily. Teams that add it after the first incident spend a long time guessing.
Where agents genuinely earn their place
When the work needs several steps, the next step depends on what the last one found, and the path differs case by case — that is a shape traditional automation expresses badly and an agent expresses naturally.
When the path is the same every time, you do not need an agent. You need a workflow, and it will be cheaper, faster and considerably easier to reason about at three in the morning.