Standardizing Incident Severity for Agent Failures: A Practical Framework for GaaS Teams

Table of Contents

• Why Traditional Severity Scales Mislead You
• The Two Axes That Actually Matter
• A Reference Severity Scale for Agent Failures
• Mapping Failure Modes to Severity
• The Reversibility Multiplier
• Who Declares Severity, and When
• Wiring Severity Into Your Reliability Stack
• Common Mistakes When Rolling This Out
• Insights Most People Overlook
• References

Why Traditional Severity Scales Mislead You

Walk into any GaaS company and ask how they grade incidents, and you'll usually hear some version of the Google SRE-style scale: SEV-1 is a full outage, SEV-2 is major degradation, SEV-3 is a minor problem, and so on down to housekeeping. It's a fine scale. It has served web infrastructure for two decades. The problem is that it grades on availability and performance, and those are no longer where agents do their real damage.

Consider what a classic monitoring stack sees during the worst kind of agent failure. The service is up. The API returns 200s. P99 latency is healthy. Token usage is normal. Every dashboard is green. Meanwhile, a procurement agent has spent the last three hours approving duplicate purchase orders because a tool-call response changed shape and the agent quietly started misreading it. By traditional severity logic, nothing happened. By any sane business measure, you have a SEV-1.

This is the gap. Traditional severity asks "is the system working?" Agent severity has to ask "did the system do the right thing?" Those are different questions, and the second one is much harder to instrument, which is exactly why so many teams default to the easy first question and miss the failures that hurt. The broader issue of agents that look fine while producing garbage is covered in the cluster under the silent failure problem, but for incident grading the takeaway is concrete: a severity scale that can't distinguish "unavailable" from "wrong" will systematically under-grade your most expensive incidents.

There's a second mismatch. Traditional incidents tend to be binary and obvious, the database is down or it isn't. Agent incidents are often probabilistic and partial. The agent gets it right 96% of the time and wrong 4%, and the 4% is concentrated in a particular edge case nobody noticed. A severity scale designed for "the pager went off because everything broke" struggles to express "a measurable, ongoing quality regression that affects a slice of traffic." You need a model that handles both the cliff and the slow leak.

The Two Axes That Actually Matter

Forget, for a moment, the single-number SEV scale. The cleanest way to think about agent incident severity is along two independent axes, and the severity number falls out of where an incident lands on both.

Axis one: blast radius. How much was affected? This is the familiar dimension, number of users, number of accounts, dollar value of transactions, percentage of traffic. It maps reasonably well onto traditional thinking. A bug affecting one internal test tenant is small; a bug affecting every enterprise customer's nightly batch run is large.

Axis two: action consequence. What did the agent actually do as a result of the failure? This is the agent-specific axis, and it's the one most teams omit. Did the agent merely produce a wrong answer that a human then reviewed and discarded? Or did it autonomously send an email, move money, modify a database record, file a ticket, or trigger a downstream workflow? The same underlying bug can be a shrug or a catastrophe depending entirely on whether the agent had the authority to act on its mistake.

The reason these two axes have to be independent is that they don't correlate. A low-blast-radius, high-consequence incident, one agent, one customer, but it wired funds to the wrong account, can easily be your worst incident of the quarter. A high-blast-radius, low-consequence incident, every agent gave slightly worse summaries for an afternoon, might be a SEV-3 you fix on Monday. If you collapse both into a single "how many users" number, you lose the dimension that actually predicts business harm.

Anthropic's own guidance on building agents stresses giving agents the minimum authority needed and adding human checkpoints for consequential actions, precisely because the action-consequence axis is where autonomy turns risk into reality. You can read the reasoning in their engineering write-up on building effective agents. The severity model below treats that axis as a first-class input, not an afterthought.

A Reference Severity Scale for Agent Failures

Here is a five-level scale you can adapt. The defining move is that severity is driven first by action consequence, then modulated by blast radius, not the other way around.

SEV-1, Irreversible harmful action at scale. The agent took consequential, hard-to-reverse actions (money moved, data destroyed, external communications sent, contracts triggered) across more than a trivial number of cases. This is an all-hands incident regardless of whether any system is "down." Example: a billing agent issued incorrect refunds to hundreds of customers overnight.

SEV-2, Harmful action, contained, or wrong outputs feeding a critical workflow. Either the agent acted wrongly but the blast radius is small or partially reversible, or the agent produced wrong outputs that are flowing unreviewed into a workflow customers depend on. Example: the agent's classifications are routing a meaningful share of support tickets to the wrong queue, but nothing irreversible has happened yet.

SEV-3, Degraded quality, human in the loop. The agent is measurably worse than baseline, but a human reviews its work before anything consequential happens, so the bad output is being caught. Example: hallucination rate on a vertical doubled, but every output goes through human approval. Painful, costs reviewer time, not an emergency.

SEV-4, Availability or latency degradation only. The classic incident: the agent is slow, rate-limited, or partially unavailable, but when it does respond, it responds correctly. Important to note this is below a wrong-action incident in this model, which inverts traditional priority on purpose.

SEV-5, Cosmetic or internal-only. Logging gaps, a flaky eval in CI, an internal tool tenant affected. Fix it in the normal queue.

The inversion is the whole point. In a traditional scale, "service unavailable" is your top severity. Here, an available agent doing the wrong thing outranks an unavailable agent doing nothing, because an agent that's down is honest about being down, while an agent that's confidently wrong is actively causing harm. A down agent fails closed. A wrong agent fails open, and open is worse.

Mapping Failure Modes to Severity

A scale is only useful if your on-call engineer can place a real incident on it at 2 a.m. without a philosophy debate. The fastest way to make that possible is a pre-agreed mapping from known agent failure modes to default severities. Build yours; here's a starting set.

• Tool-call failure that the agent silently absorbs (calls a tool, gets an error or malformed response, proceeds anyway with a fabricated value): default SEV-2, escalate to SEV-1 if the fabricated value drove a consequential action. This connects directly to the cluster work on debugging tool-call failures in agent chains.
• Hallucinated facts in customer-facing output: SEV-3 if human-reviewed, SEV-2 if delivered unreviewed, SEV-1 if the hallucination triggered an action (e.g., agent invented a policy and then issued a refund under it).
• Wrong action taken correctly, the agent flawlessly executed a task the user never wanted: default SEV-2, because the machinery worked perfectly and that makes it harder to detect. This subtle failure mode gets its own treatment in the cluster.
• Drift / slow quality regression: usually starts as SEV-3 because it's gradual and reviewable, but should be promoted if it crosses into unreviewed consequential paths.
• Guardrail bypass / prompt injection success: SEV-2 minimum even with no observed harm, because a breached guardrail is a loaded weapon; SEV-1 if the injection caused an action.
• Pure latency / availability: SEV-4 unless it cascades (e.g., timeouts cause the agent to skip a verification step, which then becomes an action-consequence problem).

Write these defaults down somewhere your responders can find them mid-incident. The goal is not to remove judgment but to remove argument. The on-call person should be able to say "tool-call silent absorption that moved money, that's our SEV-1 default" and start the response, not convene a meeting to decide.

The Reversibility Multiplier

If you add one concept to your severity model beyond the two axes, make it reversibility, because it's the variable that most cleanly separates "expensive lesson" from "company-ending incident."

Reversibility asks: once we detect this, how hard is it to undo what the agent did? Reading data is perfectly reversible, you can always discard a bad answer. Writing to an internal record is usually reversible with a rollback. Sending an external email is not reversible; you can apologize, but the email is out. Moving money is reversible-with-effort. Deleting production data may be irreversible if backups are stale.

Practically, treat reversibility as a multiplier on the action-consequence axis. The same wrong action lands a full severity level higher when it's irreversible. This is why mature GaaS teams obsess over making agent actions staged and reversible by design, dry-run modes, soft deletes, holding external sends in a queue for a beat, requiring confirmation for anything that crosses an irreversibility threshold. A reversible architecture doesn't just reduce harm; it literally lowers the severity of your incidents before they happen, which is the cheapest reliability investment you can make.

There's a strategic angle here that ties to GaaS economics. When you price per-outcome rather than per-task, an irreversible wrong action isn't just an engineering incident, it's a direct hit to the outcome you're being paid to deliver. The reversibility multiplier is, in effect, a way of pricing operational risk into your severity model the same way your contracts price it into your fees. Industry analysts tracking the shift to outcome-based AI pricing, including coverage from a16z on the economics of agentic software, note that getting the wrong outcome is worse than getting no outcome, which is exactly the inversion this severity scale encodes.

Who Declares Severity, and When

A severity scale nobody is authorized to invoke is decoration. Decide three things explicitly.

Who can declare. Any on-call engineer should be able to declare up to SEV-2 unilaterally. SEV-1 declaration should also be unilateral, it is always better to over-declare and stand down than to debate while harm accumulates. The cultural rule worth stealing from strong SRE orgs is "no blame for declaring," documented well in the Google SRE incident management guidance. If declaring an incident feels risky to your engineers, they'll wait, and waiting is the enemy.

When the clock starts. For agents, severity should be declarable on signal, not just on confirmed harm. If your eval-in-production monitor shows hallucination rate spiking, that's grounds to declare, even before you've confirmed a single customer was hurt. Waiting for confirmed harm with autonomous agents means waiting while the agent keeps acting. Declare on the leading indicator, downgrade later if it turns out benign.

The kill switch question. Every severity declaration above SEV-3 should explicitly answer: do we pause the agent? For autonomous systems, "stop the agent from taking further actions" is often the single highest-leverage response action, and it needs to be a one-command operation that on-call can execute without approval chains. If pausing your agent requires a deploy, fix that before your next incident, not during it.

Wiring Severity Into Your Reliability Stack

Severity is not an island. It only creates value when it connects to the systems around it.

Upstream, your observability and eval tooling should be capable of suggesting a severity. If your traces capture which actions an agent took and your evals score output quality, a monitor can reasonably propose "this looks like a SEV-2: quality dropped and outputs are flowing to an unreviewed path." Human confirms, but the system does the first pass. This is where end-to-end tracing of agent runs earns its keep, you can't grade action-consequence if you can't see what actions were taken.

Downstream, severity should drive post-mortems and your reliability metrics. SEV-1 and SEV-2 incidents warrant blameless post-mortems as a matter of policy. And the running count of incidents by severity becomes one of the most honest reliability signals you have, far more honest than a marketing "99% accurate" claim. Some GaaS vendors are starting to publish incident history the way status-page culture normalized for uptime; expect the reliability-conscious enterprise buyer to start asking for it before they sign.

Sideways, severity feeds your escalation and human-review design. The severity of incidents you keep seeing tells you where your autonomy dial is set too aggressively. If a particular action class keeps generating SEV-2s, that's a signal to move it behind a human checkpoint, the severity log is, in effect, a map of where you over-trusted the agent.

Common Mistakes When Rolling This Out

The most common failure is copying the scale without inverting the priority. Teams adopt a five-level SEV model, label availability as SEV-1 out of habit, and then act surprised when a confidently-wrong agent runs for a day without anyone treating it as urgent. If you take nothing else from this piece: an available agent doing the wrong thing should outrank an unavailable one.

The second is grading on intent instead of impact. "But the agent was supposed to do that, the prompt was just ambiguous" is not a severity downgrade. The customer experienced the impact regardless of whose fault the prompt was. Grade what happened, assign root cause later.

The third is letting severity inflate or deflate over time without recalibration. After a few quiet months, teams start grading everything down to avoid the ceremony of a real incident. After a scary one, they grade everything up. Review your last quarter of incidents periodically and ask whether the severities you assigned still look right in hindsight. Consistency is what makes the metric trustworthy.

The fourth, specific to agents: forgetting that the model underneath can change without your code changing. A provider ships a new model version, and an agent that was a steady SEV-free performer starts producing a new failure mode. Your severity process needs to treat "the model changed" as a legitimate incident trigger, not dismiss it because "we didn't deploy anything."

Insights Most People Overlook

An available agent is more dangerous than an unavailable one. This is the single most counterintuitive thing about agent reliability and it deserves repeating as its own insight. Traditional ops trains you to treat "down" as the worst case. With autonomous agents, "down" is the honest failure, it fails closed and stops acting. The agent that stays up while quietly doing harm fails open. Any severity scale that doesn't encode this will mis-prioritize at exactly the wrong moments.

Severity should be declarable before harm is confirmed. Because agents act continuously, the cost of waiting for proof is measured in additional wrong actions. Borrow from medicine's triage logic, not from software's "repro it first" instinct. Declare on the leading indicator, investigate in parallel, downgrade if benign. The asymmetry, a false alarm costs an hour, a delayed declaration costs a day of bad actions, strongly favors declaring early.

Your incident-severity log is a covert autonomy audit. Nobody plans it this way, but the distribution of where your serious incidents cluster is the most honest map you have of where you gave the agent too much rope. If 70% of your SEV-2s come from one action class, the data is telling you that action class belongs behind a human checkpoint. Few teams mine their severity history this way, and it's nearly free intelligence.

Reversibility is a design lever, not just a descriptor. Most teams treat reversibility as a fact about an incident, "well, that one was irreversible, unlucky." It's actually a knob you control at architecture time. Staging actions, soft deletes, and hold-and-release queues for external effects don't just reduce harm; they mechanically lower the maximum severity your system can produce. You can cap your worst-case incident severity through design, before any incident occurs.

A shared severity vocabulary is half the value, independent of the scale itself. The specific numbers matter less than the fact that everyone, engineering, support, the customer-facing team, the exec who gets paged, means the same thing by "SEV-2." A mediocre scale used consistently beats a brilliant scale nobody agrees on. Optimize for being unambiguous and memorable over being theoretically perfect.

References

• Building Effective Agents, Anthropic Engineering
• The Economic Case for Generative AI and Foundation Models, a16z
• Managing Incidents, Google SRE Book