AgentOps: Running AI Agents in Production Without Silent Drift

The Gap Between Working and Operating

There is a specific moment in most enterprise AI deployments when the team feels confident. The eval scores look good. The demo impressed the executives. The pilot users reported positive results. The system goes live. And then, six months later, nobody is quite sure why the accuracy has drifted — but it has, and by the time anyone noticed, the downstream decisions made on the basis of the agent's outputs were already downstream.

The gap between a working AI agent and an operating AI agent is the gap between AgentOps and everything that came before it.

What AgentOps Actually Covers

AgentOps is not a product category. It is a set of operational disciplines applied to AI agents running in production. It covers three areas: observability (knowing what the system is doing), boundary testing (knowing when it is operating outside its reliable range), and feedback loops (detecting and correcting degradation before it compounds).

Observability: Production Traffic Is the Only Metric That Matters

Static test sets are useful during development. They are insufficient in production. The reason is distributional: production inputs do not match the distribution you tested against. They evolve with the organisation, the corpus, and the users. An agent that scores 94% on a benchmark from six months ago may be scoring 76% on the inputs it is actually receiving today.

Production observability requires three instrumented signals: response latency per request, confidence scores when the model exposes them, and a sampled human review rate that is actually staffed. Google Cloud Trace and Cloud Logging provide the infrastructure. The hard part is building the review workflow and keeping it staffed — which is an organisational decision, not an engineering one.

Boundary Testing: Know When the Agent Is Outside Its Zone

Every agent has a reliable operating range — the class of inputs for which it performs well under real conditions. Outside that range, the agent will still produce outputs. It just will not be reliably right. Boundary testing identifies the edges of that range before production users discover them the expensive way.

The practical implementation is a set of out-of-distribution prompts that are refreshed with each corpus update. When the agent's response to a boundary test degrades, that is a signal to review the corpus, the model, or the prompt strategy — not to wait for user complaints.

Feedback Loops: The Instrument That Catches Silent Drift

Silent drift is the production failure mode that does not look like a failure. The agent continues to respond. No alerts fire. But accuracy on the actual input distribution is declining, because the corpus has gone stale, the model was updated, or the nature of incoming queries has shifted.

The feedback loop that catches silent drift requires two things: a human-review sample drawn from production traffic (not from a static test set) and a process for turning review findings into corpus updates or prompt revisions within a defined cycle. The sample rate can be low — 3 to 5 percent of production requests is often sufficient — but the review must happen on a cadence and the findings must have a clear owner.

Rollback Triggers

A rollback trigger is a pre-agreed threshold at which the team reverts from the AI-assisted path to the human-only path. It should be defined before deployment, not discovered during an incident. The trigger should be expressible in terms of measurable production signals: a review failure rate above X%, a response latency above Y milliseconds, or a human-escalation rate that crosses a defined threshold.

Rollback must be operable by the team that owns the business outcome. If it requires an engineering deployment, it is too slow for most operational contexts. The practical architecture is a feature flag or a routing rule that a product owner can toggle without touching code.

The Operational Posture

Running AI agents in production is infrastructure work, not research work. The mental model that produces reliable deployments is the same mental model that produces reliable distributed systems: instrument everything, test the boundaries, build the feedback loop before you need it, and treat degradation detection as a first-class operational concern alongside latency and availability.

The teams that get this right do not have better models. They have better operating practices. The model is a component. The operating practices are what make the component reliable.