Skip to content
All insights
31 March 2026·10 min read

AI agents in production: what actually matters

Running AI agents in a real business environment is nothing like the demos. Here's what breaks, what matters, and what nobody tells you.

AI agents in production: what actually matters

AI agents in production: what actually matters

The demo version of AI agents is compelling. An agent that monitors your inbox, drafts responses, logs actions in your CRM, and escalates edge cases to a human — all without intervention. It's real technology. These things can be built.

What the demos don't show you is what happens at 11pm on a Tuesday when the agent misclassifies a high-value customer enquiry as spam, or when an API it depends on changes its response format, or when the underlying model produces a confident but incorrect answer that nobody catches for three days.

Running AI agents in production is an operational discipline, not a deployment event. Here's what actually matters.

Observability first

You cannot manage what you cannot see. Before any agent goes into production, you need complete visibility into what it's doing: every decision, every action, every error, and every escalation.

This means logging at a level of detail that most developers consider overkill. It means dashboards that show you agent behaviour over time, not just current status. It means alerting on anomalies — not just failures.

The businesses that run agents successfully treat observability as a first-class requirement, not an afterthought. The ones that don't are the ones who discover problems through customer complaints rather than their own monitoring.

Failure mode design

Every agent will fail. The question is how.

Good agent design assumes failure and specifies what happens when it occurs. Does the agent escalate to a human? Does it fail silently or visibly? Is there a fallback to a manual process? What's the blast radius of an incorrect decision?

The failure modes that matter most are the ones where the agent is confidently wrong — where it produces an output that looks correct but isn't. These are harder to catch than obvious errors and more damaging. Designing for them means building validation checkpoints, human review triggers, and output constraints that make confident-but-wrong outputs less likely.

Scope containment

The most dangerous thing you can do with an AI agent is give it broad permissions and minimal constraints. Narrow scope, clear boundaries, and well-defined action sets are what separate controllable agents from unpredictable ones.

This is counterintuitive — the value proposition of agents seems to be their generality. But in production, generality is a liability. You want an agent that does a specific thing reliably, not one that can theoretically do anything.

As your confidence in a specific agent grows, you can expand its scope. Start narrow.

Model maintenance

AI models change. The underlying models that power your agents are updated by their providers, sometimes with behaviours that differ materially from the version you deployed against. Prompts that worked reliably can produce different outputs after a model update.

This means your agents need maintenance on a cadence that matches your risk tolerance. Low-stakes agents can tolerate periodic reviews. High-stakes agents need continuous monitoring and regular re-evaluation against your production cases.

"Set and forget" is not a viable operating model for AI agents.

Human integration, not human replacement

The best agent deployments we've seen treat humans and agents as partners, not substitutes. Agents handle volume and consistency. Humans handle judgement and exceptions. The system is designed so that the handoffs between them are smooth, clear, and reliable.

The worst deployments try to eliminate human involvement entirely — and then discover that the edge cases the agent can't handle are exactly the ones where human judgement is most valuable.


AI agents in production are powerful tools and genuine operational liabilities if you're not prepared to run them properly. The gap between a demo and a production system is not a technical gap. It's an operational one. And it requires the same discipline you'd apply to any other critical business system.