Error budget (agent systems)

Three inputs fix that count: the completion-rate target, the task volume it applies to, and the window the count is read over. Take a 99.5 percent target against 100,000 tasks a month, the same figures the calculator below uses. Subtract the target from 100 and divide by 100 for the allowed failure rate: 100 minus 99.5 is 0.5, so 0.005. Multiply by the 100,000 monthly tasks and the answer is 500 failed tasks, the whole budget. The window has a shape as well as a length: a calendar month resets the count on the first of the next one, while a rolling 30-day window refills one day at a time. The same 500 behaves differently by shape, so a budget with no stated window is incomplete.

This entry rests on two pieces of our research. Agent reliability as a discipline maps reliability into separate properties; completion is one of them, and this budget turns completion into a number a team can spend rather than only observe. Our playbook for budgeting against compounding failure in production supplies this entry’s habits: naming failure classes and compounding the math step by step.

Why a count, not one percentage

Two standard texts state the error budget two different ways. Google’s SRE book states it as a rate: a 99.999 percent target is the same statement as a failure rate of 0.001 percent for the quarter, and a component eating 0.0002 percent of a quarter’s queries has spent about a fifth of the budget. The SRE workbook states the same idea as a count: the budget is 100 percent minus the target, applied to actual task volume, the 500-task arithmetic above. A count is what a team can spend: assigned, subtracted from, checked off class by class; a rate cannot be.

A team names its failure classes: a tool error, a step timeout, a wrong final answer, a coordination failure, a safety violation. Each gets a share of the 500. Shares of 40, 25, 15, 10, and 10 percent give 200, 125, 75, 50, and 50 failed tasks, summing back to 500. Those figures are the calculator’s own presets, shown as an example, not a recommendation; a team sets its own shares. Naming the classes is contested: MAST sorts multi-agent failures into 14 modes across three categories from over 1,600 annotated traces, and no taxonomy, from MAST or from any vendor, has become the standard. That is why each team draws its own lines, and why collapsing them into one system-wide percentage destroys the only decision the number supports: which part to fix first.

Read against the whole task volume, a class’s share is itself a rate: 200 of the 500 failures in one class is 200 out of the 100,000-task volume, an allowed rate of 0.2 percent of all tasks, not the 40 percent it looks like as a share of the budget. A failed task counts once, in the class of whatever ended it: a tool call that errored and then timed out is one failure, filed once, regardless of what happened along the way. One exception outranks that rule, covered next.

The calculator that turns a target and a task volume into a budget split by class is where this arithmetic runs.

The classes that get nothing

Some classes take no share at all: a hard invariant is a rule the system may never break, however small the count would otherwise be. vdf.ai, an agent-platform vendor, states this rule in its own published SLOs, read on 2026-08-22: no budget for prohibited data transfer, an unapproved model, an unauthorized tool action, or an omitted, legally mandated human decision. A hard invariant’s share is zero, so one occurrence is itself a breach.

The calculator enforces the zero: a class marked a hard invariant has its share set to zero, and the points it would have held sit unassigned until the team moves them. The total never shrinks. Mark the safety violation above, at 10 percent, a hard invariant: the rest sum to 90 with 10 points unassigned, and the calculator refuses the split until they are reassigned. Move all ten onto the first class and the four remaining shares read 50, 25, 15, and 10 percent, worth 250, 125, 75, and 50 tasks, back to 500.

Recovering well does not change that status. A run that hits the invariant and still returns a smaller, correctly labeled answer instead of the full one has degraded gracefully at the response level, but the breach is recorded either way.

What an error budget is not

An error-budget policy is a separate document from the budget itself: what the team does once the count is spent, up to freezing changes for the rest of the window.

The burn rate reads how fast that number is being spent, checked over shorter intervals inside the window; a comfortable total can still alarm if one interval’s pace would exhaust it early.

An SLA is external and contractual, carrying a penalty, usually financial, when missed; an error budget is internal and spent on purpose, and running out changes what the team does next rather than what it owes someone else. The internal target is normally set tighter than the contractual one, so the two numbers are usually different.

The timeout budget this site already defines is the closest, easiest-to-confuse neighbor: both are budgets in the same failure-containment family, but a timeout budget counts seconds inside one run while this error budget counts failed tasks across many runs over a window.

Error propagation sits one level further down, inside a single failed task: one agent’s mistake compounding into the next one’s trusted input. This budget counts only whether the task failed; propagation depth and containment rate answer how the failure spread on the way there.

Some teams call this same quantity a failure budget instead; both point at the same count, and this entry keeps error budget as its headword. With a target, a volume and a window fixed, running the split against a team’s own classes is what the calculator above is for.