AgentOps: How to Operate AI Agents in Production

Picture a refund agent at an online retailer. AgentOps is the practice of operating AI agents in production with the tools of site reliability engineering (SRE) plus continuous measurement of correctness, so that every release, alert and rollback is tied to a versioned agent and a quality score. The refund agent is an illustrative scenario, not a client story. On Tuesday the team ships version 14: a newer model snapshot and a shorter system prompt, released together. By Thursday every dashboard is green. The error rate is flat, 95th-percentile latency has improved and token spend is down. Then finance finds 41 refunds above the policy limit, each approved without a single call to the agent's policy-check tool. Nothing crashed. The agent was up, fast and wrong.

SRE already tells you how to run a service: service level objectives (SLOs), canary releases, rollbacks, on-call and blameless postmortems. AgentOps keeps all of it and changes one assumption. An agent can pass every infrastructure check and still be wrong, so correctness has to be measured continuously, not inferred from uptime.

If you read only this:

• Version the whole agent. That means the model snapshot, instructions, tools, retrieval settings and graders. Stamp the version on every trace so you can compare versions and roll back.
• Gate every change twice. First a regression eval suite in continuous integration (CI), each case run several times, then a canary judged against the current version on quality, tool behaviour and cost, as well as errors and latency.
• Grade production continuously. Score a sample of live traces, alert on quality the way you alert on any SLO, and turn every incident trace into a new eval case.

What AgentOps adds to SRE

Google's SRE book chapter on monitoring distributed systems names four golden signals of monitoring: latency, traffic, errors and saturation. An agent still needs all four. They cannot see the failure in the opening scene: nothing was slow or broken. The agent took a different path through its tools and produced a confident, well-formed, wrong outcome.

So AgentOps adds signals and changes a few habits. (The name is also used by a commercial tracing product; here it means the practice.)

The rest of this note follows the loop below and tests each step on the refund agent.

Open the diagram full size:

Version the whole agent, then stamp the version everywhere

Version 14 changed two things at once, and the team could not say which one caused the refunds. You cannot roll back what you cannot name. This is release engineering applied to agents: the SRE book wants binaries and configurations "built in a reproducible, automated way", and for an agent the model snapshot, prompt and tool definitions are configuration. An agent version should pin six things:

1. The model snapshot, a dated or fixed identifier rather than an alias that moves.
2. The instructions, by content hash.
3. The tool allow-list and each tool definition, because a reworded tool description changes behaviour as surely as a prompt edit.
4. Retrieval settings: index version, chunking and filters.
5. Enforced limits, such as the maximum refund and the maximum number of tool calls per run.
6. The eval suite and grader versions the release was approved against.

A small manifest per version is enough. The format below is our own suggestion, not a standard:

# agent-release.yaml: one file per agent version (illustrative format)
agent: refund_agent
version: v14
model: MODEL_SNAPSHOT_ID      # placeholder: a pinned snapshot, never an alias
instructions: prompts/refund_agent.md@sha256:PROMPT_HASH
tools:                        # the allow-list, each definition versioned
  - lookup_order@3
  - check_refund_policy@2
  - issue_refund@5            # write tool; limit enforced outside the model
retrieval: refund-policy-index@2026-10-20
limits: {max_refund_amount: 200, max_tool_calls: 12}
approved_against:
  eval_suite: regression@31
  graders: [policy_adherence@4, task_success@2]

Then put the version on every trace. The OpenTelemetry generative AI (GenAI) semantic conventions for agent spans, still marked Development as of late October 2026, define a gen_ai.agent.version attribute on the client invoke_agent span, for an agent called over the network. The in-process invoke_agent span does not list it at that commit, so set it there yourself as an extra attribute. With it, any dashboard, alert or evaluation can be split by version, which is what makes a canary comparison possible later on.

Pinning a model does not freeze it forever. Anthropic gives at least 60 days' notice before retiring a publicly released model, according to its model deprecations page, and requests to a retired model fail. Google's model versions and lifecycle page lists a retirement date for every available model, and says those dates may be extended but "won't be moved to an earlier date than what is listed."

Release gates: regression evals in CI

Anthropic's engineering guide Demystifying evals for AI agents draws the distinction that matters here. Capability evals ask "What can this agent do well?" and should start at a low pass rate. Regression evals ask "Does the agent still handle all the tasks it used to?" and should have a nearly 100% pass rate. The regression suite is your release gate. The guide's advice on where to begin: "20-50 simple tasks drawn from real failures is a great start."

Run each case more than once

Agent outputs vary from run to run, so one green run proves less than it looks. Anthropic's guide defines pass^k as the probability that all k trials succeed, and notes that it "especially matters for customer-facing agents".

In a simplified model with independent trials, a case that succeeds 90% of the time passes one trial 90% of the time, but passes all five only 59% of the time. A case that succeeds 99% of the time passes all five 95% of the time. One trial barely separates those two; five do.

The same arithmetic warns against the opposite mistake: thirty cases at 99% each, all required to pass once, give a green suite only 74% of the time, so the gate blocks about one release in four for noise. A noisy gate teaches people to rerun until it passes, so keep the regression suite to cases that reliably pass and move flaky ones to the capability suite.

Grade outcomes, and check order only where order is the policy

Anthropic's guide advises that "it's often better to grade what the agent produced, not the path it took". The refund agent shows where that advice stops. Calling check_refund_policy before issue_refund is the policy itself, so for side-effecting tools, check the order in code. The guide itself recommends "choosing deterministic graders where possible"; applying that to call order is our extension. Code checks are cheap and deterministic, and they would have caught version 14 on the first run. Use model-based graders for what code cannot judge, such as tone or whether the explanation to the customer was accurate. Calibrate them against human judgement, because they cost more than code and are not deterministic.

Pin the graders too. Microsoft's Agent Framework guidance for Foundry evaluations puts it plainly: "Pin datasets, model deployments, evaluator versions, and rubric versions when results must be comparable across runs."

A gate in pytest

On Google Cloud, the Agent Development Kit (ADK) runs eval cases from pytest, as its evaluation guide shows, so the gate is an ordinary CI test:

# tests/test_release_gate.py  (google-adk 2.13.0; needs pytest-asyncio)
import pytest
from google.adk.evaluation.agent_evaluator import AgentEvaluator

@pytest.mark.asyncio
async def test_refund_agent_regression_suite():
    # Every *.test.json case under tests/regression came from a real failure.
    # Thresholds sit beside them in test_config.json, for example:
    # {"criteria": {"tool_trajectory_avg_score": 1.0,
    #               "response_match_score": 0.8}}
    await AgentEvaluator.evaluate(
        agent_module="refund_agent",
        eval_dataset_file_path_or_dir="tests/regression",
        num_runs=5,  # several trials per case; the default is 2
    )

The evaluator raises an assertion error when any criterion misses its threshold, which fails the build. In ADK 2.13.0 the score is averaged over every run, so a trajectory threshold of 1.0 means every trial must call the expected tools in the expected order: pass^k in practice. That suits a short, side-effecting flow like refunds.

The same gate exists on the other platforms. Google Cloud's row is Gemini Enterprise Agent Platform, which Google's Agent Platform overview describes as an evolution of Vertex AI:

On cost, Microsoft's own tip for its GitHub Action is: "To minimize costs, don't run evaluation on every commit." Run the gate on changes to the agent's manifest, not on every edit to unrelated code.

Canary the new version against the old one

Google's SRE workbook chapter on canarying releases defines canarying as "a partial and time-limited deployment of a change in a service and its evaluation." It also gives two rules that carry straight over to agents: compare canary signals with control signals, and "also use absolute measures, such as defined SLOs", because both groups can drift together. It suggests selecting "the top few metrics to use in canary evaluations (perhaps no more than a dozen)."

For the refund agent, send version 14 a small share of sessions, keep version 13 as control, and compare on:

• Tool mix per run. Which tools were called, how often and in what order. This signal is deterministic, cheap and available from traces in minutes. Version 14's missing policy checks would have shown up here first. The GenAI metrics conventions (Development) define gen_ai.invoke_agent.tool_calls for this count.
• Graded quality from sampled online evaluation, such as policy adherence and task success.
• Cost per completed task, not just tokens per call, since a new version can use fewer tokens per call and make more calls.
• Escalation rate to people, in both directions. A sudden drop can be as alarming as a rise.
• The absolute SLOs described below.

Quality scores need volume, which is where small canaries struggle. Take another simplified model: 2,000 sessions a day, a 10% canary and 10% of sessions graded, which gives 20 graded canary sessions a day. If 90% of them pass, the 95% confidence interval (a Wilson score interval) runs from roughly 70% to 97%. After ten days, with 200 graded sessions, it narrows to roughly 85% to 93%. Lean on deterministic signals early.

Trace with the OpenTelemetry GenAI conventions

When the canary flags something, the trace is how you find out why. The OpenTelemetry GenAI conventions, which were still at Development status in late October 2026, give agent traces a shared shape: an invoke_agent span for the run, inference spans for model calls (named after the operation, for example chat), execute_tool spans for tools, and an optional plan span. Attributes such as gen_ai.agent.version and gen_ai.conversation.id tie runs to versions and sessions. An evaluation result can be recorded as a gen_ai.evaluation.result event, defined in the GenAI events conventions, parented to the span it judges, so the quality score lives on the trace it scores.

Open the diagram full size:

Three things to know before you depend on these conventions:

• Their status is Development. When we last looked, on 29 October 2026, the open-telemetry/semantic-conventions-genai repository still marked its documents that way and had no tagged release. The GenAI pages in the main OpenTelemetry semantic conventions now carry a moved notice pointing to that repository. Pin a commit, and expect to migrate attribute names when they change. Microsoft's own agent tracing documentation carries the same warning.
• Content capture is opt-in by design. The GenAI client span conventions say capturing prompts, outputs, tool arguments and tool results is "gated by an explicit user opt-in". Without tool arguments you cannot list the refunds a bad version issued; with them, your traces hold customer data that needs access control and retention rules.
• Platform support is real but uneven. Google's agent observability documentation says its traces "rely heavily on" these conventions. Microsoft Foundry uses them and stores traces in Application Insights. AgentCore emits OpenTelemetry-compatible telemetry into CloudWatch, per its observability guide. The OpenAI Agents SDK, per its tracing documentation, traces runs by default, includes model and tool inputs and outputs by default (trace_include_sensitive_data), and offers no tracing to organisations under Zero Data Retention.

Keep every trace that errored, breached a cost limit or failed a grader, and sample the rest. This is tail sampling, which OpenTelemetry describes as deciding "by considering all or most of the spans within the trace". Failures are rare and valuable, while successful runs are plentiful.

SLOs and alerts that include quality

The SRE workbook's chapter on implementing SLOs recommends expressing a service level indicator (SLI) as "the number of good events divided by the total number of events." The work for an agent is defining "good". For the refund agent, a good session is one that:

• completed the task or escalated correctly,
• passed the sampled policy-adherence grader,
• stayed within its cost limit, and
• met its latency target.

Because grading is sampled, the quality part of the SLI is an estimate. The platforms run this grading for you. Google's Online Monitors score live traces on a loop that typically runs every 10 minutes, with a sampling percentage and a cap on samples per run to control cost, and they export scores to Cloud Monitoring. AgentCore's console lets you sample between 0.01% and 100% of sessions, with a default of 10%. Google names the target plainly: quality drift, "an observable decrease in agent performance over time."

The error budget then does what it does for any service. In the words of the SRE book's Embracing Risk chapter, "If SLO violations occur frequently enough to expend the error budget, releases are temporarily halted." For an agent, that means no prompt, model or tool changes except fixes until quality recovers.

Alert on:

• quality SLO burn rate, per version (see the SRE workbook on alerting on SLOs);
• a shift in tool mix or tool calls per run;
• cost per task above its limit;
• the rate of guardrail blocks; and
• the age of the human approval queue, if the agent has one (the autonomy tiers note covers designing that step).

Incident response: contain first, then roll back

When the alert fires, the first move for an agent is containment, not diagnosis. It is the first priority in the SRE book's chapter on managing incidents: "Stop the bleeding, restore service, and preserve the evidence for root-causing". Design the containment states before you need them; the three below are our suggestion, not a standard.

Open the diagram full size:

A runbook for the refund agent:

1. Contain. Switch to Restricted: turn off issue_refund and route refund decisions to people. This is a configuration flag the on-call engineer can flip, not a code change.
2. Roll back to the last good manifest, version 13, and confirm on fresh traces that the tool mix has returned to normal.
3. Compensate. A rollback restores behaviour, not the world. Query the execute_tool issue_refund spans for version 14 to list every affected refund. This step only works if you captured tool arguments or keep a separate audit log. This is the compensating transaction pattern.
4. Turn the trace into a test. Add the failing session to the regression suite, so no future version can repeat it unnoticed.
5. Write a blameless postmortem. The standard from the SRE book's chapter on postmortem culture: focus on contributing causes "without indicting any individual or team for bad or inappropriate behavior."

The SRE book's postmortem triggers already include "On-call engineer intervention (release rollback, rerouting of traffic, etc.)" and "Data loss of any kind". Agents add three more: an action taken outside policy, sensitive content found in telemetry, and a breach of a cost limit.

On-call for agents is the same rotation with different levers. The engineer paged needs the containment flag, the manifest history, audited access to traces, and the authority to pause the agent without waiting for a model expert.

Drift: when the agent changes without a deploy

Version 14 was a change the team made. Many agent regressions arrive without one:

• Model retirement. A pinned snapshot has an end date someone else set. Treat the migration as a new version through the full gate.
• User behaviour. New products, new seasons and new phrasing all shift the inputs. Anthropic's guide expects production monitoring to "detect distribution drift and unanticipated real-world failures."
• Tool backends. An order API or Model Context Protocol (MCP) server changes a field, and the agent quietly reasons over different data.
• Retrieval content. Someone edits the refund policy document the agent retrieves.

Two defences cover most of it. Run the regression suite on a schedule against the production version even when nothing has shipped, so external changes surface as failing cases. Microsoft's Foundry observability overview calls this scheduled evaluation "to detect system drift". And keep online grading running, because the suite only knows the failures you have already seen.

Honest limits

• Online grades are estimates. They are sampled, often model-judged and paid for per call. Anthropic recommends "automated evals for fast iteration, production monitoring for ground truth, and periodic human review for calibration".
• pass^k assumes independent trials. A provider incident or a shared cache can make failures arrive together, which the simple arithmetic understates.
• Rollback does not undo actions. Every write tool needs a compensation plan and the data to execute it.
• Traces with content are sensitive data. Microsoft's guidance applies everywhere: "Treat trace data as production telemetry and apply the same access controls and retention policies you use for logs and metrics."
• Evals cover only what you wrote down. New failure modes appear first in production, which is why the loop ends by feeding production failures back into CI.
• Small canaries lack statistical power for quality scores. Deterministic signals carry the early decision.
• The conventions will move. They were still marked Development in late October 2026, which means attribute names can change. Budget for a migration when you pin a commit.

Where these practices sit in AELSHA™ ASTRA

AELSHA™ ASTRA, our delivery framework, has six lifecycle phases, each ending at a quality gate, and five signal pillars. This is our mapping onto them, not an industry standard.

Takeaways

• An agent can be up, fast and wrong at once. Add quality, tool mix, cost per completed task and escalations to the four golden signals.
• The release unit is the whole agent. Pin the model snapshot, instructions, tools, retrieval, limits and graders, and stamp the version on every trace.
• Gate with repeated trials, canary against the previous version, and keep SLOs as absolute guards.
• Contain, roll back, compensate, then learn. Every incident trace becomes a regression case.

What's next

Start with the two cheapest steps: write the manifest for the agent you already run, and turn your last 20 real failures into regression cases. Most of the loop builds on those two.

One question to take back to your team: if your agent shipped its own version 14 tomorrow, which signal would page someone first? If the answer is "finance", tell us what you run today, and we will suggest the first signal to add.

Further reading

• Demystifying evals for AI agents, Anthropic: The best single guide to capability versus regression suites, pass^k and grading outcomes rather than paths.
• Canarying Releases, Google SRE Workbook: The canary discipline this note borrows, including comparing against control and keeping absolute SLOs.
• Implementing SLOs, Google SRE Workbook: How to define a good-event SLI and an error budget policy that people actually follow.
• Semantic conventions for GenAI agent and framework spans, OpenTelemetry: The span names and attributes, gen_ai.agent.version among them (on the client span), that let any tool split traces by agent version.
• How Nehemvix observes itself: traces and signals, AELSHA™ NEHEMVIX: Operating one agent after release, with OpenTelemetry traces that never hold code, prompts or keys.

The OpenTelemetry GenAI conventions and the vendors' evaluation features change often, so check the linked specifications and documentation before you build on them.