AI Agent Exception Taxonomy: Naming The Cases That Should Not Continue

Agents need names for the moments when the normal path should not continue. A missing source is different from a conflicting source. A tool timeout is different from a permission denial. A stale record is different from an irreversible action. A vague user request is different from a request that crosses an authority boundary. If the workflow treats all of those moments as generic failure, the agent will either stop too often, improvise too much, or hand the human a problem that has lost its shape.

An exception taxonomy is the shared vocabulary for those non-normal cases. It tells the agent, the reviewer, and the surrounding system what kind of problem has appeared and what kind of response is appropriate. The response may be retry, clarify, gather more evidence, escalate, narrow scope, request approval, checkpoint, or stop. The taxonomy does not solve every exception. It keeps exceptions from becoming a fog.

AI Agent Runbooks describe the normal operating rhythm. AI Agent Escalation Paths explain how uncertainty reaches the right person. The taxonomy sits between them. It helps the runbook say when the normal path no longer applies and helps escalation carry a clear reason rather than a vague complaint.

Exceptions Should Be Named By Cause And Consequence

The first design mistake is naming exceptions only by symptom. “Failed” is a symptom. “Blocked” is a symptom. “Cannot continue” is a symptom. Those labels may be true, but they do not tell the next actor what to do. A better label ties the cause to the consequence.

A source conflict means two or more sources disagree and the agent cannot determine which one governs. The consequence is not to pick the most convenient source. It is to preserve the conflict, prefer known authority rules when available, and escalate if authority remains unclear. A missing required field means the task lacks information needed for a safe action. The consequence may be a clarifying question or a prepared draft with the missing field marked. A permission boundary means the next useful step requires authority the agent does not have. The consequence is an approval request or stop, not a workaround.

This naming discipline supports AI Agent Output Verification . A verifier can inspect whether the agent responded to the exception correctly. Without a named exception, the final answer may only say that the agent did its best.

Start With A Small Routing Table

Define categories against a particular workflow, including the evidence that triggers each label and the next safe action. The following is a starting point, not a universal policy:

More than one label can apply. Record the relevant labels, then apply the most restrictive applicable rule to the affected action: a temporary error does not make an unauthorized action retryable. If the cause is uncertain, record what was observed and mark the cause as suspected. A timeout is evidence of a timeout, not proof that a service failed before changing state. Safe, independent work may continue if the runbook permits it; the blocked step should remain paused.

Labels alone do not enforce these rules. Put permission checks, retry limits, and approval gates in the surrounding application or tool layer as well as in the agent’s instructions.

For each category, write down the observable trigger, the affected action, its owner, and the evidence that permits a transition out of the pause. Keep severity separate from the label: a source conflict in a draft may need editorial review, while one affecting an imminent payment may need an urgent operational response. Assign severity and response deadlines using the workflow’s own risk rules. If the deadline expires, follow the fallback route; do not interpret silence as approval.

Clarification Is Not The Same As Escalation

Many agent workflows blur clarification and escalation. They both involve asking a person. They are not the same. Clarification asks the requester to supply missing task information, choose a preference, or resolve an ambiguity they are qualified to resolve. Escalation sends the issue to someone with authority, ownership, or risk responsibility beyond the requester.

If a user asks an agent to summarize a folder but does not name the date range, clarification may be right. If a user asks the agent to bypass an approval gate, escalation may be right. If a customer message conflicts with policy, the requester may not be the right person to decide. If a tool denies access to a restricted record, the agent should not ask the requester to paste the record into chat unless the data boundary allows it.

AI Agent Clarifying Questions focuses on asking before the run goes sideways. An exception taxonomy helps decide when a question is enough and when the issue needs a different lane. This distinction reduces both friction and risk. People are not interrupted for questions the agent could answer from context, and requesters are not asked to approve things they cannot safely approve.

Retry Exceptions Need Evidence

Some exceptions deserve retry. A transient tool timeout, a temporary rate limit, a flaky test setup, or an unavailable page may clear. Other exceptions become worse when retried. A duplicate send, a repeated charge, a second form submission, or a tool call with unclear side effects can create harm. The taxonomy should separate retryable from non-retryable conditions.

Retry labels should include what is known about side effects. A read timeout before any action is different from a timeout after submitting a state-changing request. In the second case, the next step may be confirmation of target state, not repetition. AI Agent Retries and Idempotency provides the deeper mechanics: idempotency keys, action IDs, dry runs, and stable status checks. The taxonomy gives the agent the language to choose those mechanics.

For a retry that is known to be safe, set a maximum number of attempts and an overall time budget, use backoff, and honor a service’s retry guidance when provided. When those limits are reached, checkpoint and route the case rather than looping indefinitely. HTTP’s semantics specification cautions against automatically retrying a non-idempotent request unless the client knows it is safe or can establish that the original was not applied. An idempotency key is useful only under the particular service’s documented rules, including its scope and retention period.

Consider an agent submitting an approved account change. The request times out, and the service has not returned a receipt. Record the action ID and the timeout as observed facts; mark the outcome unknown. Query the service using the action ID. If the service confirms the change, record the receipt and continue with verification. If it confirms the request was never applied, retry only if the approval, target state, and retry policy still permit it. If the status is unavailable or inconclusive, pause for investigation. A second worker finding the same task should also check the existing action record and ownership before acting. Amazon EC2’s idempotency documentation illustrates why a timed-out mutating request may already have had an effect.

Quota and rate-limit exceptions also need care. AI Agent Quota-Aware Execution explains graceful stops under limits. The taxonomy should distinguish “wait and retry later” from “budget exhausted, checkpoint now” and from “shared quota pressure, yield to higher-priority work.” Those conditions feel similar in the moment but imply different behavior.

Stale State Is Its Own Exception

Agent work often spans time. A record can change after the agent reads it. A source can be updated after the draft is prepared. An approval can expire. A branch can move. A queue item can be claimed by another worker. If the workflow has no stale-state exception, the agent may proceed on assumptions that were true earlier and false now.

A stale-state exception says that the target no longer matches the inspected state. The right response may be revalidation, conflict handling, or a fresh approval. It should not be treated as an ordinary failure or silently ignored. This is especially important when agents use checkpoints. A resumed run must know what evidence needs rechecking before action.

AI Agent Checkpoints and AI Agent Concurrency both depend on stale-state awareness. A checkpoint preserves work, but it also freezes assumptions. A lock prevents some collisions only while its ownership is valid, and it cannot prevent every external change. An expired worker may still be running; the system must reject its stale writes where the underlying service supports that control. The taxonomy gives resumed work a way to say, “the old path may no longer be valid.”

Policy Conflicts Need Reviewable Records

Some exceptions involve conflict between instructions, sources, or policies. A task request may conflict with durable policy. A retrieved document may conflict with a newer source. A page may contain hostile instructions. A customer may request an action outside the support policy. An old memory may conflict with current evidence.

These cases should not be collapsed into generic uncertainty. The taxonomy should name the kind of conflict and require the agent to preserve both sides in the handoff. Which source said what? Which source appears higher in the hierarchy? What did the agent treat as evidence rather than instruction? What decision remains for a reviewer?

AI Agent Instruction Hierarchies gives the rules for keeping goals, policies, evidence, and untrusted content in order. The exception taxonomy gives the workflow a reporting surface when those layers fight. A reviewer should not have to infer that a conflict existed from a cautious-sounding paragraph.

Suspected prompt injection deserves its own route because the suspicious text can arrive in a document or tool result the agent was legitimately asked to read. Preserve a restricted reference or minimal excerpt for review, rather than spreading sensitive content through a general queue. OWASP’s prompt-injection guidance recommends treating external content as untrusted and enforcing permissions and tool-argument validation outside the model; labeling text alone is not a security boundary.

Make The Handoff Actionable

A useful exception record is short enough to read and specific enough to resume. Include the task and target, category and observed trigger, time and relevant source or action ID, current state, any action already attempted, the known or unknown outcome, and the blocked next step. Name the owner or queue, the decision requested, and the conditions for resuming. Use authorized references and omit credentials and unnecessary personal data. If there is a response deadline, define a fallback owner; a missed deadline does not itself authorize continuation.

For example: “Paused account update: target identity ambiguous. Records A and B match the name; the supplied order number matches A and the address matches B. No update attempted. Please provide a second identifier or select the intended record through the approved process.” If a later change requires approval, identifying the record does not by itself approve that change. See AI Agent Review Queues for ownership and fallback routing.

Test the taxonomy with representative cases before relying on it. Include a transient read failure, a permission denial, a timeout after a state-changing request, a changed target after approval, and an instruction embedded in retrieved content. Check that each case reaches the intended queue, that unsafe tool calls are blocked, and that the handoff accurately distinguishes observed facts from unknowns. Test a case with two labels as well: the stricter rule should still govern. Review misrouted cases and repeated unknowns with the workflow owner, then update the triggers and runbook.

Unknown Exceptions Should Not Become A Junk Drawer

No taxonomy can cover every case. There should be a label for unclassified exceptions, but it should be treated as temporary. If “unknown” becomes common, the taxonomy is not doing its job. Repeated unknowns should be reviewed and either given a name, routed into an existing category, or used to improve the runbook.

This connects to AI Agent Operating Metrics . Exception categories produce signals. A rise in missing-source exceptions may point to broken retrieval. A rise in permission-boundary exceptions may point to poor task routing. A rise in stale-state exceptions may point to concurrency problems. A rise in unclassified exceptions may point to a workflow moving beyond its original design.

Measure exceptions against a defined unit, such as the number of affected tasks per 100 started tasks over a week, rather than reading raw counts alone. Track the age of open cases, unclassified cases, and cases returned from a queue as misrouted. Count a task with multiple labels consistently, and separate a new case from repeated attempts on the same case. A change in volume, traffic mix, or labeling practice can move the rate without indicating a real change in reliability; inspect examples before changing policy.

The taxonomy should remain small enough to use. It is better to have a dozen well-understood categories than a sprawling menu no one applies consistently. The names should appear in runbooks, handoffs, traces, and review queues. They should be ordinary language, not private jargon that only the system designer understands.

The Point Is Predictable Stopping

An exception taxonomy is not an attempt to make agents timid. It is a way to make stopping, retrying, and escalating predictable. When the normal path is safe, the agent can move. When a known exception appears, it can respond according to the category. When an unknown exception appears, it can preserve the evidence and stop without pretending to have solved the case.

That predictability helps humans too. A reviewer who sees “source conflict” knows to inspect authority. A requester who sees “missing required field” knows what to provide. An operator who sees “stale target state” knows the run needs revalidation. An incident reviewer who sees “permission boundary crossed” knows the problem is not just a bad answer.

Good delegated work depends on this kind of naming. Agents do not need a dramatic story for every exception. They need a stable vocabulary that keeps the problem legible. Once the case has a name, the next action becomes easier to choose and easier to review.