Blog · · 12 min read

AI agent reliability metrics: build SLOs that control releases

AI agent reliability metrics: build SLOs that control releases

An AI agent reliability dashboard can stay green while people repair the agent's work. A run may complete on time but update the wrong record. It may look successful until a reviewer corrects it two days later. Low traffic and selective exclusions make the numbers easier to misread. A trustworthy system needs a versioned outcome ledger, visible numerator and denominator counts, separate safety stops, and an error-budget policy that changes rollout behavior. This guide gives product platform and reliability engineers a concrete event contract, operating rules, and tests for that system.

Reliability needs a product contract

Use six parts for the contract:

  1. Define which product task the agent is responsible for.
  2. Decide which accepted tasks are eligible for measurement.
  3. Record run and outcome events without overwriting history.
  4. Classify each run as good, bad, excluded, unknown, or pending under a versioned rule.
  5. Calculate service level indicators for each workflow and risk cohort, then attach targets and windows.
  6. Connect safety events and error-budget state to release, rollback, recovery, and autonomy decisions.

Google's SRE guidance defines an SLI as a quantitative measure of service behavior. An SLO gives that measure a target or target range. The same guidance starts with user concerns rather than the metrics that happen to be easy to collect. The Google SRE chapter on service level objectives provides the general model. An agent adds another requirement: the product must define what a good task outcome means.

Put that definition in product-owned code and data. A model may propose an action, but it cannot grade its own release, exclude an awkward run, or decide whether its output counts as correct.

Why agent dashboards can lie

A response is not an outcome

A successful HTTP response proves that an endpoint answered. It does not prove that the agent chose the right queue, changed the intended record, or finished within policy. Google Cloud's production-agent KPI guidance treats outcome quality, goal achievement, latency, cost per successful outcome, intervention, safety, and stability as separate concerns. One request-success counter cannot represent them all.

Measure a unit that a product owner would recognize. A model turn is rarely useful. "Route this support ticket to the correct queue" is useful. "Extract this invoice into a validated record" also works. The task begins when the product accepts the work. It ends when the product can verify the terminal result.

A denominator can improve without the agent improving

Imagine 1,000 support runs and 970 recorded successes. The apparent success rate is 97 percent, but the ratio has no meaning until the team answers several questions:

  • Are cancelled runs eligible?
  • What happens to requests blocked by policy before execution?
  • Does a timeout count as bad, unknown, or absent?
  • Can a query remove test tenants after the fact?
  • Does a customer correction replace an earlier success?
  • Where do runs with missing labels go?

A query that drops unresolved runs can raise the success rate with no change in behavior. A new evaluator can move the graph while the agent stays the same. Centralize eligibility and acceptance logic, version both, keep unresolved outcomes visible, and show the counts behind every ratio.

Quality labels arrive after the run

A server error is usually known immediately. Quality may depend on a read-back, an evaluator job, human review, downstream reconciliation, or customer feedback. If the dashboard treats a provisional completion as final, it will be optimistic. If a late label overwrites the first result, investigators lose the sequence that explains the change.

Store two events instead. The first records the provisional terminal state. The later event records the applicable acceptance rule, the new label, and its reason. Aggregation may use the latest valid label, but the run keeps its original timestamp, release ID, task class, and evaluator version.

Sparse traffic makes percentages jump

One failure in ten eligible runs produces a 90 percent success rate. Nine good runs before it looked perfect. Google's SLO alerting guidance explains why low-traffic services make error-budget alerts sensitive to single requests. It discusses user impact, synthetic traffic, grouping related services, product changes, and realistic thresholds as alternatives to blindly applying high-volume alert rules.

Always show the sample count, window, and unresolved outcomes. A high-impact workflow may need review after every bad run. A lower-risk workflow can use a longer decision window. Teams can also rely on release evaluations until production provides enough evidence for a stable trend.

Build the AI agent reliability metrics event contract

1. Register the task class

Give each measured workflow a stable registry entry with these fields:

  • task_class identifies the product job.
  • risk_tier captures the consequence of a bad outcome.
  • eligibility_rule_version identifies the code that puts accepted work into the SLI.
  • acceptance_rule_version identifies deterministic checks and evaluator policy.
  • label_deadline says when unresolved work becomes unknown or bad.
  • slo_policy_version selects targets, windows, sample rules, and operational actions.
  • owner names the team that maintains labels, alerts, and recovery.

An exclusion should be independent of the result. Test traffic, a cancellation before execution, or a pre-acceptance policy block may qualify. "We could not score the output" does not. That run is unknown, and the policy must say what unknown work does to a release decision.

Attach the rule versions when the product accepts the run. A new deployment can use new rules for new work. It must not silently change yesterday's denominator.

2. Append lifecycle and label events

Use an append-only event stream or an audit table with equivalent behavior. One event can look like this:

{
  "event_id": "evt_01",
  "run_id": "run_01",
  "task_class": "support_ticket_triage",
  "risk_tier": "medium",
  "release_id": "agent-release-42",
  "event_type": "outcome_labeled",
  "occurred_at": "2026-08-03T10:04:12Z",
  "eligibility_rule_version": "triage-eligibility-v3",
  "acceptance_rule_version": "triage-acceptance-v7",
  "outcome": "bad",
  "reason_code": "wrong_queue",
  "label_source": "deterministic_readback",
  "supersedes_event_id": "evt_00",
  "latency_ms": 18420,
  "cost_minor_units": 27,
  "intervention": "unplanned",
  "safety_event": null
}

Do not copy full prompts, credentials, or unrestricted tool payloads into this event. Store a trace reference and keep diagnostic data behind its normal access controls. The OpenTelemetry GenAI agent span conventions define standard agent and operation spans. Link the outcome ledger to those spans with stable run and trace identifiers instead of duplicating sensitive content.

3. Make outcome states explicit

Every accepted run moves through a small state machine:

  • pending means required evidence is still due and the deadline has not passed.
  • good means the run met its versioned acceptance rule.
  • bad means the run ended in a state the rule defines as unacceptable.
  • excluded means an outcome-independent exclusion applied.
  • unknown means the deadline passed without enough evidence to prove good or bad.

For a high-risk workflow, let unknown consume budget unless the policy explicitly says otherwise. A broken evaluator or missing telemetry must not improve the success rate. A lower-risk workflow may report unknowns separately, but an excessive unknown rate should still block traffic expansion.

Correct a label by appending a new event that supersedes the old one. The aggregate selects the latest valid label for each run. The event chain remains available for audit and incident review.

4. Publish counts beside ratios

Keep the first metric set small and interpretable:

  • Correct completion divides good eligible runs by resolved eligible runs.
  • Unknown rate divides unknown runs by runs past their label deadline.
  • Unplanned intervention rate measures runs that needed rescue outside the designed approval path.
  • Verified tool outcome rate compares confirmed effects with attempted effects.
  • End-to-end latency runs from acceptance to verified outcome and uses percentiles per task class.
  • Cost per successful outcome divides total run cost by good outcomes.

Every graph should expose good, bad, unknown, pending, and excluded counts. It should also identify the acceptance-rule version and release cohort. Without those details, a team cannot tell whether a behavior change or a measurement change moved the metric.

Model latency, tool timeouts, retries, and evaluator disagreement help explain an SLI change. Keep them as diagnostics. They should not replace the product outcome merely because collection is convenient.

Turn SLOs into release controls

Set targets for one task and risk class

Write each SLO as a complete statement. For example:

Over a rolling 28-day window, at least 97 percent of eligible support_ticket_triage runs must receive a good label under acceptance rule v7 within 24 hours. Unknown outcomes must remain below 0.5 percent, and any cross-tenant disclosure triggers immediate containment regardless of aggregate performance.

That threshold is an example, not a benchmark. Establish a baseline on representative production or shadow traffic. Then use the failure consequence and product expectation to choose a target. The Google SRE SLO chapter advises teams not to copy current performance without thought or demand an impossible 100 percent. The target should settle real priority disputes without forcing constant exceptions.

Keep hard safety stops outside the budget

Some events require containment even when the monthly numbers are healthy. Examples include an unapproved destructive action, cross-tenant disclosure, or confirmed policy bypass. Give those conditions a separate response:

  • Stop new autonomous runs for the affected task class.
  • Narrow or revoke the relevant tool permission.
  • Preserve evidence and reconcile side effects with unknown outcomes.
  • Send affected work to a safe fallback or human queue.
  • Require an explicit recovery approval before restoring autonomy.

Correctness, latency, intervention, and cost misses can use an error budget. A hard safety condition overrides that budget.

Decide what each budget state does

Google's example error-budget policy ties budget exhaustion to release controls, reliability work, and postmortems. An agent policy can use similar states:

  • healthy permits normal releases at the current traffic allocation.
  • watch increases outcome sampling and blocks further autonomy expansion.
  • freeze stops nonessential prompt, model, tool, and policy releases for the workflow.
  • rollback sends traffic to the last known release, suggestion-only mode, or a human path.
  • recover requires failure-case validation, a canary, and stable production evidence before scope returns.

Assign an owner and notification route. List which emergency changes can ship during a freeze. Otherwise security fixes, evaluator repairs, and data corrections will trigger the same argument during every incident.

Page on burn, not on every miss

When traffic is sufficient, calculate how fast the workflow is consuming allowed bad outcomes. The Google SRE alerting chapter recommends multiple windows and burn rates to balance detection speed, precision, recall, and reset time. A short window catches a severe regression. A longer one catches sustained decline.

Hard safety events still get per-event alerts. Budgeted reliability misses use burn alerts. For sparse workflows, do not page on an unstable ratio before the minimum evidence rule is met. Keep the bad event visible, send high-impact cases to review, and use a longer window for trend decisions.

Example: ticket triage with delayed labels

A support agent classifies a ticket and writes its queue. The product can immediately verify that the queue exists, authorization passed, and the write committed. It cannot always know that the queue was correct, so the run ends as pending.

A specialist who accepts the ticket without rerouting it supplies a later good label. A reroute within 24 hours supplies bad with reason wrong_queue. If neither event arrives by the deadline, the run becomes unknown. The release view reports these states by agent release and ticket category.

Suppose release 42 handles 400 eligible tickets: 372 good, 16 bad, 8 unknown, and 4 pending. The dashboard should not discard unresolved work and report a flattering percentage. It should show resolved success, unknown rate, pending count, and the label deadline. The SLO evaluator then applies its minimum-evidence rule to the rollout decision.

If both burn windows cross their thresholds, traffic expansion freezes. New tickets in the failing category go to suggestion-only mode. Engineers use traces linked from wrong_queue labels, add confirmed failures to the regression suite, and canary a replacement release. The workflow regains autonomy only after its recovery rule passes.

Handle measurement failures

An evaluator outage is an incident in the reliability system. Pending work should accumulate and eventually become unknown. Success rate must not rise. Alert on label backlog age and on runs approaching their deadline.

A changed rubric gets a new acceptance-rule version. Back-test it against a stable labeled set before using it for release decisions. If historical comparison matters, publish a separate restated series with a clear label. Do not combine two rubrics in one unlabeled trend.

Missing cost or latency data should mark that diagnostic SLI incomplete. It should not alter the outcome label. A correctly completed task may still have unknown cost, and the dashboard needs to show that distinction.

An unverified external side effect remains unknown until reconciliation. A clean worker exit does not prove success. Retrying an irreversible action just to obtain a tidy metric can make the incident worse.

Test the control loop

Run these checks before the SLO can block or promote a release:

  1. Feed one event for every outcome state and verify the numerator and denominator.
  2. Append a late label and verify that aggregates change without deleting the old event.
  3. Change the acceptance-rule version and prove prior runs retain their version.
  4. Break the evaluator and confirm that pending and unknown counts rise instead of success.
  5. Send test traffic and verify a recorded, versioned exclusion.
  6. Simulate sparse traffic and prove one failure follows case-review policy without a noisy ratio page.
  7. Inject a hard safety event and prove autonomy stops with a healthy budget.
  8. Burn both alert windows and verify that the expected page, freeze, or rollback fires once.
  9. Restore a canary and require offline failure-case checks plus newly labeled production outcomes.
  10. Reconcile the ledger against product terminal states and investigate each missing run.

Enforce one more invariant: every accepted task has exactly one current eligibility decision and no more than one current outcome label. Any correction must be represented by a superseding event. Run that reconciliation on a schedule.

Common mistakes

Average latency hides slow retries, approval waits, and tool calls. Use percentiles for each task class.

Planned approval and unplanned rescue are different events. The first is a control. The second means the promised autonomy failed.

Dashboard queries should not invent their own exclusions. They should consume the centralized eligibility and acceptance decisions.

A low-volume SLO needs raw counts and a sparse-evidence policy. Paging on every percentage change creates noise without helping the affected user.

An error budget does not excuse a severe safety event. Keep those stop conditions separate.

A green graph immediately after rollback is not enough to restore autonomy. Require a verified fix, a bounded canary, and enough new labels to pass the recovery rule.

Start with one workflow

Choose one agent workflow that changes product state or creates recurring cleanup. Write its eligibility rule, five outcome states, label deadline, and one hard safety stop. Emit the event shape for ten real or shadow runs, then reconcile the events with the product's terminal state.

Set the first SLO only after those counts agree. AI agent reliability metrics earn their place in production when a bad result changes what the agent is allowed to do.

References

Be first in line.

Join the waitlist and we'll email you the moment it's ready. No sales call.

Try the demo →
or talk to us