Why most AI agents never make it into production

The demo is the easy half

An agent that completes a task once, on a curated input, in a notebook, is a feasibility signal. It is not a system. The distance between that signal and an operational system is almost entirely engineering work that the demo deliberately avoided.

In our experience the failure is rarely the model. It is the absence of explicit boundaries: what the agent may read, what it may act on, what happens when it is wrong, and how anyone would know.

Four gaps that stop deployment

When an agent stalls before production, the cause usually falls into one of four categories.

• Reliability — behaviour varies run to run and no one has quantified how much.
• Integration — the agent needs write access to systems that were never designed for non-human callers.
• Observability — there is no trace, no evaluation harness and no way to reconstruct a decision.
• Economics — per-run cost was never measured against the cost of the work being replaced.

Designing for the second half

Treat the agent as one component inside a distributed system. Give it a narrow tool surface with real permissions, an orchestrator that owns retries and escalation, an evaluation suite that runs in CI, and traces that a support engineer can read at 2am.

Once those exist, the interesting question changes from whether the agent works to where its automation boundary should sit.