Reliable AI Agents Need SLOs, Not Just a Success Rate

“The agent completed the task” is a useful event. It is not a reliability strategy.

An agent can produce the expected text while using the wrong data. It can call the right tool but leave a partial write behind. It can succeed in a benchmark and fail after a timeout, a duplicate webhook, a changed schema, or an ambiguous user request.

Reliability is not one property of a model. It is a set of guarantees around a workflow.

That is why production agents need service-level objectives. An SLO makes reliability specific enough to measure: which tasks should succeed, under what conditions, with what latency, safety, recovery, and evidence requirements?

An agent should have a smaller job than its name suggests. “Handle support” or “manage deployments” is too broad to evaluate. A useful workflow has:

• a clear input;
• a bounded set of tools;
• a defined authorization context;
• an acceptable output or state change;
• a way to verify the result;
• a recovery path when the next step is uncertain.

For example, “inspect a failed deployment and prepare a diagnosis for an engineer” is safer than “fix production.” The first workflow can read logs, compare recent changes, summarize evidence, and stop for approval. The second contains an unbounded set of potentially destructive actions.

The boundary is not a limitation on the model. It is what makes the system testable.

Suppose an agent succeeds on 95 out of 100 tasks. That sounds promising until we ask what happened to the other five.

Were they harmless refusals? Did they silently invent an answer? Did they retry a payment twice? Did they complete the task but take ten minutes? Did they expose information the caller was not allowed to see?

The same success rate can describe very different systems. At minimum, reliability should be split into dimensions:

The target numbers are product decisions. A research assistant and a refund-processing agent should not have the same objectives. What matters is that the objectives are explicit and tied to the consequences of failure.

An SLO should describe the workflow a user depends on, not an internal model score.

For a deployment-diagnosis agent, a useful promise might look like this:

During a normal operating period, at least the agreed share of eligible diagnosis requests produce a cited, reviewable summary within the defined time budget. Requests that lack enough evidence are marked unresolved and escalated rather than presented as confirmed causes.

This statement has more information than “95% accuracy.” It defines eligibility, output quality, latency, evidence, and the behavior when the system cannot know.

A simple internal representation could be:

type WorkflowObjective = {
  workflow: "deployment-diagnosis"
  success: "reviewable-summary-with-evidence"
  maxDurationMs: number
  allowedTools: string[]
  escalationState: "unresolved"
  evidenceRequired: boolean
}

The agent can reason flexibly inside these constraints. The runtime should enforce the parts that must not be left to a model response.

Most agent failures are not solved by asking the model to “try harder.” They are handled by ordinary software:

• timeouts prevent one dependency from occupying the entire workflow;
• retries use bounded backoff and only apply to operations safe to repeat;
• idempotency keys prevent duplicate writes;
• checkpoints preserve durable progress between steps;
• circuit breakers stop repeated calls to a failing dependency;
• approval gates pause actions with irreversible consequences;
• compensation or rollback returns a partial operation to a known state.

The model should be able to observe these states. It should not be allowed to redefine them.

Tool schemas are an important reliability boundary. A tool should state which inputs are required, which resources are in scope, whether the operation is read-only, and what errors are possible. A generic execute_sql or send_request tool gives the model too much authority and gives the evaluator too little structure.

The safest agent often has a narrow model surface and a deterministic core. The model chooses among well-defined operations; the runtime validates and executes them.

An agent can reach the right final answer through an unsafe path. Evaluation should therefore inspect the trajectory:

1. Did it identify the correct task and scope?
2. Did it choose an allowed tool?
3. Did it pass the right arguments?
4. Did it verify the returned data?
5. Did it notice uncertainty or conflicting evidence?
6. Did it stop, retry, or escalate appropriately?
7. Did it leave a trace that another person can review?

Create a small evaluation set from realistic workflows rather than only synthetic questions. Include empty results, permission failures, stale data, malformed tool responses, timeouts, duplicate events, and tasks that should be refused.

Each evaluation should record why it failed, not only whether it failed. “Wrong answer” is too broad to improve. “Correct tool, stale scope,” “unsafe retry,” and “unsupported certainty” lead to different engineering actions.

Logs and traces are not a post-incident luxury for agents. They are how the team knows whether the workflow met its objective.

A useful trace can connect:

• the request and authorization scope;
• the model and prompt version;
• tool calls and validated arguments;
• returned evidence and intermediate state;
• retries, timeouts, and policy decisions;
• the final result and human approval;
• cost and duration.

Sensitive input should be redacted before it reaches long-lived storage. The trace should preserve enough structure to explain the run without becoming a copy of every private document the agent touched.

The resulting dashboard should answer operational questions:

• Which workflow is missing its objective?
• Is the problem correctness, latency, policy, or dependency health?
• Are failures clustered around one tool or one type of input?
• How often does the agent return unresolved instead of guessing?
• How long does recovery take?

These are more actionable than a global “agent quality” number.

Every objective has a cost. Higher verification, more retries, and longer context can improve correctness while increasing latency and spend. The answer is not to hide the trade-off inside one score.

Set budgets deliberately:

• maximum model and tool steps;
• maximum wall-clock duration;
• maximum retry count;
• maximum token or API cost;
• maximum permission scope;
• maximum time a human reviewer should wait for context.

When a budget is exhausted, the workflow should end in a known state: a safe refusal, an unresolved result, a queued continuation, or a human hand-off. “Keep trying” is not a recovery policy.

An agent is only as reliable as the workflow around it. A strong model cannot compensate for unclear authorization, untyped tools, missing idempotency, weak evaluation data, or an interface that presents an unresolved answer as fact.

Start with one workflow. Define its user promise, failure states, and evidence. Add SLOs that reflect the consequences of being wrong. Then instrument the path well enough to learn which boundary needs better engineering.

The goal is not an agent that never fails. The goal is a system that fails visibly, safely, and recoverably—and improves because the team can see why.

Further reading: Google’s SRE workbook guidance on implementing SLOs and Span’s agent trace security overview.