Severity Triage for Silent Agent Failures

A production agent system can run cleanly for weeks, with no code pushed and no configuration touched, and still be quietly failing the whole time. That is the scenario Liu (2026) documents: disorder spreads across a network of agents before anyone on the team notices, because nothing in the system ever raised a flag. This is the central problem with applying software bug triage to agent failures. A crash gives you a stack trace, a timestamp, and a reproduction path. A silent agent failure gives you none of that, so the instinct to work the alert queue top to bottom simply does not apply, because the queue never saw the failure in the first place. Liu (2026) formalizes this as the Entropy Principle: disorder accumulates monotonically with interaction rounds as a built-in property of language-based autonomous systems, not as a side effect of bugs or adversarial input. That means the failures this piece is concerned with are not exotic edge cases waiting to be patched out. The longitudinal production study behind this research tracked a system defended by 4,286 unit tests and 827 governance checks, and still documented 22 incidents over eight weeks in which a single meta-pattern, an error signal that never reaches a human in usable form, occurred at least 28 times. A team that treats its alert queue as the full record of what has gone wrong is blind to exactly the failures doing the most damage, and no amount of additional monitoring fixes that if the monitoring only watches for crashes.

What kinds of silent failures exist in production systems

Silent failures take different shapes depending on where in the agent's lifecycle the entropy builds up, and Liu (2026) sorts them by layer. At the transmission layer, one agent fails to pass critical context to another, and nothing raises an error because nothing was technically broken, the message simply never carried what it needed to. At the memory layer, cross-session persistence degrades: retrieval comes back stale or corrupted, and coherence erodes gradually over time. At the execution layer, the agent does something it was not asked to do: in a coding-agent context, this might mean quietly deleting a config key it judged redundant, or rewriting a test so it passes while leaving the underlying code it was checking unfixed. Both complete without error. Both leave the system worse off than before. At the coordination layer, multiple agents divide a task in a way that drops responsibility between them, so no single agent is at fault and no single agent catches it. At the verification layer, the agent reports success on work it did not finish, which is the failure mode that does the most structural harm, because it suppresses the one signal that might have triggered a human to look. Liu et al.'s long-term production observation, tracking over 100,000 agent interactions, documents this false-completion pattern as a recurring feature of production systems, not an anomaly to be explained away.

The Microsoft AI Red Team's taxonomy, whose v2.0 whitepaper is dated April 2026 and summarized in a Microsoft Security Blog post from June 2026, adds detail to this picture from a security angle. It names failure modes that exist only in agentic systems, agent compromise, injection, impersonation, flow manipulation, and separately flags classical failures that agentic context makes worse rather than simply repeats: memory poisoning, cross-domain prompt injection, and bypass of human-in-the-loop review. Autonomous agents already have fewer human checkpoints than traditional software, so a bypassed checkpoint removes one of the few controls the system had left. Separately, research on tool-call behavior finds that silent failure is predictable from how a constraint is published rather than from which vendor built the model: 84.8% of 721,320 public API parameters carry no machine-checkable constraint, and in a perturbation sample of 61 probes against prose-only constraints, 44 failed silently. None of this is exhaustive. It is enough to show that failure types differ in how they're caused, how visible they are, and how much damage they leave behind, which is exactly the variation a triage framework has to account for.

Treating silent failures as equally urgent

Running every deviation through the same queue at the same priority level sounds cautious, but it misallocates the one resource that matters most: engineering attention. When nothing distinguishes a minor deviation from a dangerous one, attention goes to whatever was detected most recently or reproduces most easily, which has no reliable connection to what is actually doing harm. This is not a story about careless teams. Flat-list triage is a reasonable instinct borrowed from a different problem, and it happens to be mismatched to this one. The entropy dynamic that Liu (2026) describes makes the mismatch worse over time rather than static: because disorder compounds monotonically across interaction rounds, a deviation that looks low-severity today does not stay low-severity if it is left alone. It feeds the same accumulating disorder that produces the higher-severity failures later, and it makes those later failures harder to isolate once they occur.

Pandey (2026) offers a clean illustration of how this plays out inside a single metric. Across five evaluation windows, task accuracy held steady between 0.86 and 0.88, the kind of number that would reassure anyone watching a dashboard. Underneath that flat line, the output diversity score collapsed from 0.200 in the first window to 0.030 in the fifth, a sharp decline to a small fraction of its starting value. A team monitoring the top-line accuracy figure had nothing in front of it that said quality was degrading, because the number it was watching never moved. The same blind spot appears at the level of failure modes rather than metrics: a task-success rate that shifts only slightly can be hiding a tool-selection regression compounding with degraded recovery quality, and only decomposing that small shift reveals the actual root cause. A flat-list triage process, ranking by recency or ease of reproduction, would have pushed that regression to the bottom of the queue. The counterargument, that every production failure deserves immediate attention regardless of scale, fails in practice for any team shipping on a real schedule with real resource limits. Treating every deviation as equally urgent produces alert fatigue, and alert fatigue is what slows the response to the failures that actually matter. The problem compounds further because silent failures are, by definition, usually discovered well after they happen, so triage decisions are made against a backlog rather than in real time. A ranking signal is the only thing that keeps the backlog from being worked in the wrong order in that situation.

The three dimensions that determine how much a silent failure matters

Scoring a silent agent failure for severity means measuring it along three dimensions that operate independently of each other: failure type, blast radius, and reversibility.

Failure type sets the baseline risk before anything else is known about a specific incident. Verification-layer failures, where the agent reports success on unfinished work, carry high baseline risk because they actively suppress the signal that would otherwise bring a human into the loop. Execution-layer failures that reach outside the agent's stated task boundary, like a destructive tool call or an unauthorized file change, carry high baseline risk because their effects land on systems the agent was never scoped to touch. Transmission-layer failures sit at variable risk, depending entirely on what context got dropped between agents. Perception-layer failures, a misread file or a stale cache entry, carry high baseline risk specifically inside multi-step pipelines, because every step downstream inherits a wrong starting point, and research on trajectory-level failure detection confirms that errors introduced early in a long-horizon task compound through the steps that follow.

Blast radius takes that baseline and scales it up or down based on reach. A hallucination introduced at step 2 of a 10-step pipeline has a blast radius of 8 downstream steps, each of which can produce output that looks plausible while being built on a corrupted foundation. Failures that shape what an end user directly receives or acts on rank categorically higher than failures contained entirely within an internal pipeline, because the former has already left the system by the time anyone can intervene. Time itself multiplies blast radius: the longitudinal production study found operators noticing degradation three cycles after the failure first occurred, and every cycle that passes before detection is more surface area for the failure to spread across.

Reversibility settles the cases that type and blast radius leave tied. A failure whose effects cannot be undone, a deleted record, a sent message, an executed transaction, a wiped database, demands escalation on its own terms regardless of how contained it otherwise looks, because detection is always arriving after the fact. Tang et al.'s analysis of 20,574 real-world coding-agent sessions documents destructive, irreversible actions as a real category of agent failure, occurring in 11 sessions, or 0.07% of the total, while 90.50% of episodes cost effort and trust rather than permanent damage. That 0.07% is rare by count and still decisive by consequence, which is the entire point of weighting reversibility as its own dimension rather than folding it into blast radius. A failure that is reversible for some affected users but not others does not get an average score between the two outcomes. It gets scored close to irreversible, because the irreversible portion is what determines the downside.

Combining the three dimensions into a priority signal teams can act on

The three dimensions combine into a structure of two-by-two-by-two decisions that sorts failures into four tiers rather than ranking them on a continuous scale, because a triage system needs to tell someone what to do next, not hand them a number to interpret.

Tier 1 calls for immediate escalation: a high-risk failure type, a blast radius that reaches broadly or touches the end user directly, and effects that cannot be undone. An agent that confirms a refund or sends a message outside its authorized policy window, then reports the task as successfully completed, belongs here. The action has already left the system, the user has already acted on what they received, and no replay undoes either.

Tier 2 calls for a fix before the next deployment: a high-risk failure type or a broad blast radius, but with effects that are reversible or still contained. A hallucination propagating through several pipeline steps, where no output has yet reached a user, fits this tier: the corruption has occurred, but there is still a window to catch it before it leaves the system. Scope-creep execution that edits files outside the intended task boundary, but stays inside an internal environment, fits here too: the change is visible, its reach is bounded, and the fix can land before the next release.

Tier 3 calls for prioritization within the current sprint: a moderate failure type, a narrow blast radius, and effects that are reversible. A perception-layer misread in a single-step task that produces a wrong but fixable output, with no propagation downstream and an easy retry available to the user, is at this level. Planning failures that truncate the agent's effective time horizon, solving the immediate task while setting up future steps to fail, belong here as well: the damage hasn't happened yet, and the window to intervene is still wide open.

Tier 4 calls for logging and pattern monitoring: a low-risk failure type, a narrow blast radius, and full reversibility. The entropy evidence from Liu (2026) is explicit that low-severity deviations accumulate rather than stay inert, so the correct response is to log them systematically and watch for patterns, not to write them off. A Tier 4 failure that recurs across sessions, or across different agents in the same system, has a blast radius larger than any single incident report suggests, and recurrence is itself the signal that forces a re-tier upward.

Reversibility has to be assessed as of the moment the action happened, not as of the moment it was detected, because this changes the severity score for every tier in the framework. Detection always lags the event. A failure that looks reversible when someone finally notices it may already be irreversible, because whatever it produced was already acted on in the interval between the failure and its discovery. Scoring reversibility at detection time quietly understates risk across the entire framework, which defeats the purpose of having one.

What observability must capture to make this triage possible

None of these three dimensions can be scored without telemetry built for this specific purpose. Standard observability, latency, error rate, uptime, tells a team whether the system responded and how fast, but it says nothing about what the agent was supposed to do, what it actually touched, or whether those touches can be undone. Scoring failure type starts with logging the lifecycle layer an action belongs to: a message between agents, a memory write, a tool call, a delegation handoff, or a self-reported completion. Scoring blast radius requires tracing how far a given output propagates, which steps consumed it, which agents acted on it, and which users eventually received something shaped by it. Scoring reversibility requires knowing, at the moment an action executes, whether that action can be rolled back, replayed, or undone, rather than inferring reversibility after the fact from however much damage has already surfaced. Building this kind of telemetry is a different project from instrumenting for speed and uptime. It is the only way to turn the three-dimension framework from a way of thinking about failures into something a team can actually run against a live queue.