Moving AI agents from proof-of-concept to production.

An AI agent proof-of-concept is designed to impress. It shows the best-case path: the user asks a clear question, the agent retrieves the right information, reasons correctly, and produces a useful output. The demo works.

Production is different. In production, the user asks an ambiguous question. The retrieved information is incomplete. The agent's reasoning produces a confident but wrong answer. The user acts on it. In a regulated context, the wrong answer has consequences.

The gap between demo and production is not primarily a model capability problem. Current LLMs are capable enough for most operational use cases. The gap is an architecture problem: the demo wasn't designed to handle failure gracefully, to escalate ambiguity to a human, to log its reasoning for audit review, or to operate within defined confidence thresholds.

The first production requirement is a human-in-the-loop design. This doesn't mean every agent output requires human approval — that defeats the purpose. It means the system has a defined escalation path for cases where the agent's confidence is below a threshold, the request is outside the defined scope, the output would trigger a regulated action, or the user explicitly requests human review. Each of these cases routes to a human. The routing logic is explicit and auditable.

The second requirement is structured output and logging. An agent that produces free-text output is hard to audit and hard to integrate. An agent that produces structured output — a JSON object with defined fields, a confidence score, a reasoning summary, and a list of retrieved sources — can be logged, monitored, and audited. The reasoning summary is particularly important in regulated contexts: it's the evidence that the agent made the recommendation for legitimate reasons.

The third requirement is scope constraint. A production agent has a defined scope: the set of questions it can answer, the data sources it can access, and the actions it can take. Anything outside that scope is escalated or declined. Scope constraint prevents the agent from reasoning about things it doesn't have reliable information about — which is the primary source of confident but wrong answers.

The fourth requirement is monitoring. A production agent runs thousands of times per day. The distribution of inputs shifts over time. A monitoring system tracks input distribution, output confidence distribution, escalation rate, and user feedback signals. When the escalation rate rises, it indicates that the agent is encountering cases it wasn't designed for. When output confidence drops systematically, it indicates a data freshness or retrieval problem. Neither of these is visible without monitoring.

The path from proof-of-concept to production is not a path from simple to complex. It's a path from 'works when everything goes right' to 'handles everything that can go wrong'. That's a design problem, not a model problem. The model you used for the demo is probably fine for production. The architecture around it almost certainly isn't.

Working through a similar problem?