An agent does not have one failure mode: it has four
By Equipo Quantum Developers
Summarize:
An alert that says “the agent failed” is not an operational diagnosis. If a team responds the same way when model behavior changes, a credential expires, an incomplete file arrives, or nobody services an approval, it will waste time and may amplify the incident. Agent continuity must separate four failure modes—model, tool, data, and operator—because each requires a different containment action and recovery proof.
The distinction is not vocabulary. It determines who takes command, what is frozen, which evidence is preserved, and what may resume. The NIST AI Risk Management Framework Core calls for mapping risk across every component, including third-party software and data, and for differentiated human oversight responsibilities. A generic agent runbook erases those boundaries.
Triage begins with a causal question
Before restarting anything, the responder should decide which statement best explains the symptom:
| Class | Triage question | First safety boundary |
|---|---|---|
| Model | Did output stop meeting its contract while inputs and tools remained healthy? | Stop irreversible decisions |
| Tool | Did a read or write against an external system fail? | Block retries with duplicate effects |
| Data | Is input missing, stale, malformed, or outside its allowed scope? | Quarantine the affected batch |
| Operator | Is a human decision, handoff, or service capacity unavailable? | Escalate and freeze high-impact deadlines |
Certainty may not be immediate. An incident can begin as unclassified, but it needs a class before recovery is authorized. Restarting from intuition is hazardous: an intermittent tool can repeat a payment, corrupt data can reproduce the same decision, and a degraded model can keep returning fluent answers.
Playbook 1: model failure
Signals. Schema violations rise, the distribution of decision reasons changes, outputs contradict known constraints, or a control evaluation no longer passes. Total provider unavailability belongs here too, even if it presents as a technical outage.
Containment. Remove the model from material actions, preserve deterministic functions, and fall back to human recommendation or a previously approved version. Do not change prompt, model, and policy at once; that would destroy causal attribution.
Evidence. Retain model version, configuration, policy, sanitized input, output, failed validators, and correlation to prior runs. Evidence should reproduce the evaluation without copying unnecessary sensitive data.
Recovery. Run the known evaluation set, then observe the candidate in shadow mode on representative input. The exit criterion is not “it answers again.” It is “it meets the behavior contract and decision boundaries again.” AI product or engineering owns recovery, with risk and business authorization when the action boundary changes.
Playbook 2: tool failure
Signals. Timeout, rejected authentication, exhausted quota, unexpected response schema, missing confirmation, or disagreement between what the agent requested and what the remote system recorded.
Containment. Open the circuit for risky writes, downgrade to read-only if useful, and queue recoverable requests. Determine whether an action is idempotent before retrying. “No response received” does not mean “nothing happened.”
Evidence. Keep request ID, tool and version, permitted parameters, response, observed remote state, idempotency key, and attempt history. Agent conversation must never be the only record of a write.
Recovery. Verify credentials and contract, perform a no-effect or safe-environment test, reconcile uncertain requests against the system of record, and only then release the queue. Integration and source-system owners lead; the agent owner confirms that degraded behavior did not alter decision meaning.
Playbook 3: data failure
Signals. A source is outside its freshness window, required fields are empty, duplicates appear, a schema changes, identity does not reconcile, or volume is inconsistent with the expected cohort.
Containment. Freeze the affected partition rather than the entire service when isolation is possible. Mark derived conclusions as unknown and block dependent actions. Replacing missing input with zero or a prior value without explicit policy turns a visible failure into a false decision.
Evidence. Record source, schema version, observation time, quality controls, lineage, affected business objects, and transformations. Recovery evidence must show which prior decisions require recalculation.
Recovery. Correct or re-import, validate again, and replay only affected objects. Then reconcile earlier and new outcomes. The data owner decides when the source is trustworthy; the business-process owner decides whether accumulated actions remain timely.
Playbook 4: operator failure
Signals. An approval queue has no owner, a handoff is missing, a rejection has no reason, a decision exceeds delegated authority, or personnel cannot interpret the evidence shown.
Containment. Reassign through the escalation matrix, stop irreversible actions, and preserve available options. Never convert a capacity gap into automatic approval; that removes the control precisely when it is needed.
Evidence. Preserve assignment, authority scope, acknowledgment, decision, rationale, handoff, and communications. Google SRE’s incident-management guidance emphasizes separated roles, a live state document, and explicit handoffs. That discipline applies just as well to a decision queue as to a technical outage.
Recovery. Confirm a capable owner, transfer context, test the handoff, and process first the cases whose expiry would change the outcome. Business operations leads while platform operations ensures permissions and evidence follow the reassignment.
One shared incident envelope
All four playbooks should share a minimum record: business object, impact, failure class, detection time, last safe action, frozen changes, current owner, linked evidence, recovery decision, and final verification. A common envelope creates one operational view without pretending every repair is the same.
In Quantum Automation Center, the envelope can be represented through execution status, timelines, artifacts, logs, and approvals linked to the same object. The AI agent documentation helps distinguish agent action from control-plane safeguards. The platform does not replace a playbook; it makes execution and exit authorization visible.
Practice continuity before the incident
The AWS guidance on Operational Readiness Reviews recommends reviewing architecture, process, event management, and release quality before launch, then feeding incident lessons back into the review. For an agent, choose one scenario from each class and ask the team to find evidence, contain, and recover without inventing privileges.
The exercise need not simulate a catastrophe. Temporarily remove a test tool, submit an incompatible schema, block an approval, or run a known evaluation against a candidate version. The useful discovery is whether responders know what not to restart.
The counterargument: four playbooks can become overhead
A small team can end up maintaining long documents nobody opens. Separation loses value when every playbook repeats contacts, severity, and communications. Keep the design modular instead: one common envelope plus four decision cards covering signals, containment, evidence, ownership, and exit. If a card changes no action, remove it.
When not to use the complete split
An assistant with no tools, persistent memory, or power to modify systems can use a simpler runbook focused on availability and response quality. Do not use these playbooks to conceal that the source process lacks continuity either: an agent reading an unavailable ERP cannot manufacture the ERP recovery plan.
The final test is concrete. Given an alert, the team must be able to name the likely class, stop damage consistent with that class, and demonstrate why resumption is safe. If the only response is “restart the agent,” operational continuity is not yet in place.
Sources
Article topics
