An error budget for an AI agent is the failure you are willing to accept before you have to act, and it is the cleanest way to make agent reliability a decision instead of an argument. Set a service-level objective, say 99 percent of runs succeed over thirty days, and the error budget is everything left over: the 1 percent of runs allowed to fail in that window. While failures stay inside the budget, the agent is meeting its target and the team keeps improving it. When the budget is gone, the rule is to stop adding risk and fix what is breaking. No debate, just the number.
This framework comes from site reliability engineering, where Google formalized the chain of SLI, SLO, SLA, and error budget (the canonical treatment is the freely available Google SRE book chapter on service-level objectives). Agents inherit the framework, but with a twist: an agent can be perfectly available and still fail at its job, because availability and correctness are not the same thing for software that produces work rather than just serving responses. Getting the indicators right is most of the battle.
SLI, SLO, SLA, error budget
Four terms do the work, and they nest inside each other. Keeping them straight is the difference between a reliability program and a wall of numbers nobody acts on.
- SLI, the indicator. A direct measurement of how the agent is doing, expressed as a ratio of good events to total events. "The fraction of runs that finished with a valid result" is an SLI.
- SLO, the objective. The internal target for that indicator over a window. "99 percent of runs succeed over thirty days" is an SLO. It is the line you hold yourself to.
- SLA, the agreement. The external promise to a customer, with consequences attached if you miss it. The SLA is what you contract for, and it sits looser than the SLO on purpose.
- Error budget, the slack. One hundred percent minus the SLO. It is the quantity of failure the objective permits, and spending it is allowed right up until it runs out.
The insight that makes the chain useful is that 100 percent is the wrong target. Chasing a perfect success rate costs enormous effort for diminishing returns and leaves no room to ship anything new. The error budget reframes failure as a resource you spend deliberately, on faster iteration, rather than a flaw to eliminate at any price.
What an agent SLI should measure
The most common mistake is to import a web-service SLI, request availability, and call it done. An agent that returns a 200 response but hands back a wrong invoice, an empty report, or a half-finished task has failed at the only thing that matters, and the availability SLI shows green the whole time.
The right primary SLI for an agent is task success: the share of runs that produce a correct and complete result inside an acceptable time. That single ratio captures what users actually care about. The challenge is defining "correct and complete," which is why this SLI leans on the same checks that power reliability testing: validation rules, output schemas, and spot-checks that turn a fuzzy "did it work" into a countable good-or-bad event.
Measuring task success means instrumenting the end of every run with a verdict. Some verdicts are automatic, the output parsed and validated against a schema. Some need a sampled human review for tasks where correctness is a judgment call. Either way, the SLI is only as honest as the verdict behind it, which is why agent SLOs and monitoring and observability are the same project: you cannot hold an objective you do not measure.
Choosing an SLO that fits the job
The objective should come from the cost of failure, not from a reflex to make the number as high as possible. Different tasks deserve different targets, and forcing one strict objective across all of them wastes effort where it is not needed and underprotects where it is.
A useful way to set the level is to ask what one failure costs. An agent that moves money, files a compliance report, or sends a contract has a high cost per failure and earns a strict objective with a small error budget, because the consequences justify the engineering. An agent that drafts a first version of a blog post, summarizes a thread, or proposes options has a low cost per failure: a wrong result is a quick redo, so a looser objective is fine and the larger error budget buys faster iteration.
The trap is treating a high SLO as a virtue in itself. Every additional nine of reliability, from 99 percent to 99.9 and beyond, costs disproportionately more to achieve and to hold. Spending that effort on an agent whose failures are cheap is effort stolen from agents whose failures are expensive. Set each objective where the task's stakes put it, and let the cheap-failure agents run fast.
How an error budget changes decisions
The error budget earns its keep by converting reliability from an opinion into a policy. Without it, "are we stable enough to ship this change?" is a judgment call that the loudest voice tends to win. With it, the answer is mechanical: is there budget left or not?
When the budget is healthy, the team is free to take risks, deploy new tool integrations, change the agent's prompt, expand its scope, because the objective is being met and there is slack to absorb a misstep. When the budget is nearly spent, caution rises automatically. And when it is gone, the policy is explicit: stop shipping features and spend the next window paying down reliability until the budget recovers.
This is also how the budget aligns two groups that usually pull in opposite directions. The people who want to ship and the people who want stability stop negotiating case by case, because the budget already encodes the trade-off. A burning budget points effort straight at the failure modes draining it, which often means tightening the weakest dependency, adding a guardrail, or improving recovery, the same work covered in incident response when a single bad failure spends a large slice of budget at once.
Agent SLIs beyond uptime
Task success is the headline, but a mature agent SLO usually tracks a small set of indicators together, because different failures hide in different metrics.
- Latency to a usable result. An agent that is correct but slow can still miss its purpose. Measure the time from request to a result the user can act on, and set a threshold past which a correct answer no longer counts as a success.
- Correctness or validation pass rate. For high-stakes tasks, separate "the run finished" from "the result was right." A run can complete and still be wrong, and only a correctness indicator catches that.
- Availability of the agent itself. The classic uptime SLI still belongs in the set as a floor. If the agent cannot be reached, nothing else matters. It is necessary but not sufficient, which is the whole point. The relationship between availability and the broader target is unpacked in agent uptime and reliability.
The art is keeping the set small. Three or four indicators that map to real user pain beat a dashboard of twenty that nobody can hold in their head. Each SLI you adopt is a promise to measure it honestly and act when it slips, so adopt only the ones whose failure you would genuinely respond to.
Why the SLA should be looser than the SLO
The external agreement and the internal objective are different numbers on purpose, and getting the gap right protects you from your own promises.
The SLO is the line your team holds internally. The SLA is the line you commit to a customer, with penalties if you cross it. If the two were equal, the moment you missed your internal target you would also be in breach of contract, with no buffer to react. Setting the SLA looser than the SLO, promising 99 percent externally while targeting 99.5 internally, means your own alarms fire first. The internal objective trips, the team responds, and the contractual line stays uncrossed. That gap is your margin for error, and it is why comparing platforms on their published numbers, as in this agent platform SLA comparison, is only the start: the published SLA tells you the floor, not how much headroom the provider keeps behind it.
One caution specific to agents: be careful what you put in an SLA you cannot measure cleanly. Promising "99 percent task correctness" sounds strong, but if correctness is partly subjective, the agreement invites disputes. Many teams keep correctness as an internal SLO and write the external SLA around the things they can measure unambiguously, availability and response time, while holding themselves to the stricter quality target privately.
How Gravity handles reliability targets
Gravity is an AI agent platform, and the reliability machinery described here, indicators, objectives, error budgets, recovery, is operated by the platform rather than handed to each user as homework. The agents are expert-built, and they run inside a runtime that measures task-level success, paces work to stay inside dependency limits, and recovers from the common failure modes automatically.
The pricing model reinforces the reliability story. You pay per use, $1 equals 1,000 credits, and you are billed only when an agent runs, so a failed run does not quietly compound into cost the way an always-on system can. Consumption maps to work delivered, which keeps the incentive on completing tasks correctly rather than merely staying up.
For the user, that means you describe what you need in plain words and an expert-built agent returns the finished result in about 60 seconds, while the SLO-setting, budget-tracking, and stabilization work stays inside the platform. To go deeper on the surrounding concepts, what is an AI agent sets the foundation and the glossary defines the terms used above.
FAQ
What is an error budget for an AI agent?
An error budget is the amount of failure you allow before action is required, calculated as 100 percent minus your service-level objective. If your objective is that 99 percent of agent runs succeed, the error budget is the remaining 1 percent. As long as failures stay inside that 1 percent over the measurement window, the agent is meeting its target and the team can keep shipping changes. When the budget is spent, the rule is to stop adding risk and stabilize.
What is the difference between an SLI, an SLO, and an SLA?
An SLI is the indicator you measure, such as the percentage of agent runs that finish with a correct result. An SLO is the internal target you set for that indicator, such as 99 percent over thirty days. An SLA is the external promise you make to a customer, usually set looser than the SLO so the internal target trips first and gives you room to react before a contractual line is crossed.
What should an AI agent's SLI measure?
Uptime alone is not enough for an agent because an available agent can still return wrong or incomplete work. The most useful agent SLI is task success: the share of runs that produce a correct, complete result inside an acceptable time. Pair it with a latency indicator, time to a usable result, and where stakes are high, a correctness or validation pass rate so quality is measured, not just availability.
How do you choose an SLO for an agent?
Set the objective from the cost of failure, not from a wish for perfection. A high-stakes financial or compliance task warrants a strict objective and a small error budget. A low-stakes drafting or summarizing task can run looser, leaving more budget to ship improvements quickly. Aiming for an unnecessarily high objective wastes engineering effort on reliability the task does not need and slows down everything else.
What happens when the error budget runs out?
A spent error budget is a signal to change behavior, not just a number that turned red. The standard response is to freeze risky changes and redirect effort to reliability: fix the failure modes burning the budget, add tests or guardrails, and harden the weakest dependency. Once failures fall back inside the objective and the budget recovers over the next window, normal change resumes. The budget turns reliability from an argument into a rule.