Recovery Patterns: How To Stop, Quarantine, And Forensically Replay A Misbehaving Agent

TL;DR

A misbehaving agent is not an emergency to improvise around. It is a runbook to execute. The runbook has six steps, in order: stop, quarantine, snapshot, forensically replay, root-cause, restore. Each step has a specific operational meaning, a specific deliverable, and a specific failure mode if skipped. Done in order, the runbook converts an incident into a piece of permanent organizational knowledge that prevents the next instance. Done out of order, or with steps skipped, it converts an incident into a recurring failure pattern with no useful artifacts. This piece walks the runbook step by step, with the discipline at each stage and the artifact each stage must produce, and ends with a complete reference runbook you can adapt to your runtime.

The Failure Mode That Forces A Runbook

A recommendation agent serving an e-commerce site begins producing recommendations that are wildly off-target. The recommendations are not just bad; they are systematically promoting a particular set of products that the agent has no obvious reason to favor. The pattern is detected by an analyst who notices that conversion rates have spiked oddly on a small set of SKUs while average order value has dropped. The analyst pings the on-call engineer. The engineer logs in, finds the agent, and immediately decides to do three things at once: figure out what is happening, stop the bad behavior, and roll back to the previous deploy.

The engineer SSHs into the agent's runtime container, opens a shell, and starts running diagnostic commands. They check the agent's recent log entries, query its memory store, look at the system prompt, examine the most recent skill manifests. While they are doing this, the agent continues to receive traffic and continues to produce the bad recommendations. They cannot decide whether to suspend the agent because they are afraid that suspending it will lose evidence about what is happening. They cannot decide whether to roll back because the previous deploy is now eight days old and they do not know if the bad behavior was present then. They eventually do roll back, the bad behavior stops, and the team moves on.

A week later, an audit reveals that approximately twelve thousand customers received recommendations from the bad version of the agent. The team has no clear answer to several important questions. What exactly was the agent doing? They have logs of the recommendations it produced but no record of the reasoning behind those recommendations. What caused the bad behavior? They have a hypothesis (a corrupted ranking model) but no proof. Could the same thing happen again? They do not know, because they cannot replay the failed agent's behavior in a controlled environment. Are any other agents affected by the same root cause? They cannot tell, because the diagnostic work was ad hoc and the artifacts produced are now scattered across the engineer's terminal history and a few Slack screenshots.

The deeper problem is that the engineer treated the incident as a problem to solve in real time, rather than as a process to execute. They mixed diagnosis with mitigation, with stopping, with rollback, all happening simultaneously, with no defined order, no defined deliverables, no defined acceptance criteria for moving from one step to the next. The result is that the immediate symptom got resolved (the bad recommendations stopped) but the underlying questions did not get answered, and the team is now operating an agent ecosystem that they have proven they cannot diagnose under pressure. The next incident will follow the same pattern unless the team builds a runbook that imposes discipline on a situation that, by its nature, encourages improvisation.

Step One: Stop

Stop means immediately suspending the agent's ability to take consequential actions, with no other goals competing for attention. This is the first step because every additional second the agent operates is additional damage, additional confusion in the eventual investigation, and additional pressure on every subsequent step. Stop has one job: end the bad behavior. Diagnosis comes later. Rollback comes later. Stop is now.

The specific operation depends on the runtime architecture. In a sandbox-based runtime, stop is a suspend signal sent to the sandbox, which freezes the agent's process and refuses any further inputs. In a queue-based runtime, stop drains the agent's input queue and refuses to enqueue further work. In a serverless runtime, stop is a deployment-side action that disables the function or routes invocations to a noop responder. In every case, stop is a single operation with a clear acceptance criterion: after stop, the agent is not producing any new output that affects external state.

The key discipline at this stage is that stop does not destroy state. The agent's memory, its in-flight working set, its recent inputs and outputs, its current resource allocation, all of these are preserved in whatever form they were in at the moment of stop. This is critical for the forensic work that follows. If stop also clears state, the next steps lose their primary inputs and the investigation becomes much harder. The runtime must support a stop primitive that suspends without erasing, and operators must use that primitive rather than any harsher alternative like "kill the process and restart" that throws away the very evidence the investigation needs.

Stop is also fast. The runbook acceptance criterion is that stop completes within seconds of the decision to invoke it. A stop that takes minutes is a stop that allows minutes more of bad behavior, which often means the actual damage is done in the gap between detecting and stopping. The runtime must expose a stop endpoint that responds in single-digit seconds, with the operational discipline that on-call engineers know exactly how to invoke it without having to look up documentation. "Stop" should be a verb that any responder can execute without thinking.

The failure mode if stop is skipped or delayed is straightforward: the bad behavior continues, the investigation gets more complicated because more contaminated data is being produced, and the eventual blast radius is larger. The failure mode if stop is over-broad (e.g., stopping unrelated agents "just in case") is also straightforward: unrelated systems go down, the incident expands beyond its actual scope, and the response loses focus. Stop is precise: only the misbehaving agent, only its consequential actions, only with state preserved for what comes next.

Step Two: Quarantine

Quarantine is a different operation from stop. Stop ends the agent's ability to take action. Quarantine isolates the agent's environment from the rest of the system so that even if the agent somehow continues to operate (a process that did not fully terminate, a buffered request that was already in flight), it cannot affect anything outside its quarantine boundary. Quarantine is the perimeter you build around the agent before you start the forensic work, so that the forensic work itself cannot accidentally leak the bad state into surrounding systems.

The quarantine boundary has several axes. Network: the agent's container is moved into an isolated network segment with no outbound connectivity to production services. Storage: the agent's memory store is snapshotted (more on this in the next step) and the live store is detached so that any continued writes do not corrupt the canonical record. Identity: the agent's credentials are rotated or revoked, so that anything still holding a reference to those credentials cannot use them. Inputs: the input queue is redirected to a holding area where messages are preserved for analysis but not delivered to the quarantined agent.

The quarantine perimeter must be enforceable at the infrastructure level, not just at the application level. An agent that has been compromised may have residual capability that the application layer does not control: a process that ignores graceful-stop signals, a side-channel data leak that bypasses the official I/O, a scheduled task that fires after the application thinks it has stopped. The infrastructure-level quarantine (firewall rules, IAM revocations, storage detachments) does not depend on the agent's cooperation; it imposes the perimeter from outside.

Quarantine is also a posture about future inputs. While the agent is being investigated, the system continues to receive requests that would have gone to the agent. These requests need somewhere to go: a holding area for later replay, a fallback responder that handles the basic cases without the agent's full capability, a transparent error response that informs the upstream caller that service is degraded. The choice depends on the workload, but the choice should be made before the incident, codified in the runbook, and not improvised under pressure. Improvising the request-handling fallback during an incident is one of the surest ways to introduce a second incident on top of the first.

The failure mode if quarantine is skipped is that subsequent forensic work risks leaking bad state. An investigator running a query against the agent's memory store might trigger a hidden side effect; a debugging session might expose credentials that should have been rotated; a replay might inadvertently send live requests against production infrastructure. Quarantine creates the safe environment in which subsequent work cannot make things worse, and skipping it means subsequent work might.

Step Three: Snapshot

Snapshot is the operation of capturing the agent's complete state at the moment of incident, in a form that can be analyzed off-line and replayed in a controlled environment. The snapshot is the primary deliverable of the early phase of the runbook; everything that follows depends on having a faithful, complete, immutable snapshot of what the agent was at the moment things went wrong.

The snapshot covers several layers. Process state: the agent's runtime process, including its memory image if the runtime supports memory snapshots, or at minimum its current configuration, environment variables, and active connections. Application state: the agent's working memory, its conversation context, its in-flight tool calls, its pending decisions. Persistent state: the agent's full memory store as of the snapshot moment, captured to a separate read-only store. Configuration state: the system prompt, tool schemas, skill manifests, pact, and runtime config that were active at the time. Recent history: the audit side-channel entries for the relevant time window (which are already preserved by the side-channel architecture, but should be explicitly bookmarked for the investigation).

The snapshot must be complete enough to support replay in a sandbox. Replay means re-running the agent's recent inputs against the snapshotted state and observing whether the same outputs are produced. If the snapshot is missing any input to the agent's behavior, the replay will diverge from production, and the investigation will be reasoning about a different agent than the one that misbehaved. Completeness is therefore the success criterion for the snapshot, and the runtime must expose a snapshot primitive that captures everything the agent had access to: code, configuration, memory, prompts, schemas, recent inputs.

The snapshot is also tagged with provenance: which agent it represents, which incident it relates to, which version of the runtime captured it, when it was taken, who initiated it. This provenance becomes part of the eventual investigation record, and it allows snapshots from different incidents to be compared, contrasted, and aggregated for trend analysis. A library of historical snapshots is itself a valuable asset; it captures the actual history of how agents have failed in the past, in a form that future incidents can be compared against.

Snapshot is the step where the time pressure of an incident has to be deliberately resisted. Investigators frequently want to skip snapshot and go straight to diagnosis, because diagnosis feels productive and snapshot feels like overhead. The discipline of the runbook is that snapshot comes first because diagnosis without a snapshot is irreversible: any query, any test, any change to the agent or its state during diagnosis can alter the very thing being investigated. With a snapshot, all of that is reversible: the analysis happens against a frozen artifact, and any number of investigators can analyze the same snapshot in parallel without contaminating each other's work.

Step Four: Forensically Replay

Forensic replay is the heart of the diagnostic work. It is the operation of re-executing the agent's recent inputs against the snapshotted state, in a sandboxed copy of the runtime, and observing what the agent does. The replay reproduces the incident in a controlled environment where investigators can pause, inspect, modify, and re-run, none of which they could do against the live system. The replay is what converts the incident from a one-time event into a reproducible behavior that can be understood and engineered against.

The replay setup uses the snapshot as its starting state. A sandbox runtime is provisioned with the same image as the production runtime, but in network isolation and with no production credentials. The agent's snapshot is loaded into the sandbox: the memory store, the configuration, the prompts, the schemas. The agent's recent input log (from the audit side-channel) is loaded as the replay sequence. The investigator then replays the inputs in order, observing the agent's outputs and internal state at each step.

The replay is also instrumented for inspection. Every memory retrieval is captured: which entries were retrieved, in what order, with what relevance scores. Every tool call is captured: which tool, with which parameters, with what response. Every model invocation is captured: which prompt was assembled, which tokens were consumed, which output was produced. The instrumentation is much more verbose than production instrumentation, because it is being recorded for human investigation rather than for routine logging. The verbosity is acceptable in the sandbox because there is no production cost.

The key value of replay is comparison. The investigator runs the replay and observes the agent's behavior. They then make a hypothesis about what caused the behavior (a stale memory entry, a corrupted skill manifest, a prompt injection in user input), modify the snapshot to remove or alter the hypothesized cause, and re-run the replay. If the bad behavior disappears in the modified replay, the hypothesis is supported. If the bad behavior persists, the hypothesis is wrong. This is the core experimental loop of agent forensics, and it requires snapshots because hypothesis-modify-replay is unsafe against any live system.

The replay also produces artifacts that become part of the investigation record. The annotated trace of what the agent did, the comparison runs that tested hypotheses, the eventual root cause demonstration: all of these are produced as documents that can be reviewed, shared, and added to the team's library of incident knowledge. A replay with no artifacts is a replay that did not happen, in the sense that no future investigator will be able to learn from it. The discipline of producing artifacts is what converts a one-time investigation into permanent organizational learning.

Step Five: Root-Cause

Root-cause is the analytical step that follows replay. Replay produces evidence; root-cause produces understanding. The understanding has to be specific enough to be actionable: "the recommendation engine produced bad output" is not a root cause, it is a restatement of the symptom; "the recommendation engine retrieved a memory entry that contained a stale ranking model from a previous training run, and the entry was not invalidated when the new model deployed because the cache invalidation logic depended on a flag that was not propagated" is a root cause, because it identifies a specific defect that can be fixed.

Root causes have categories. The categorization is useful because it tells you which other systems might have similar exposure. Categories include: skill descriptor injection (a tool's documentation was modified maliciously and induced unexpected behavior); memory contamination (a memory entry contained incorrect or malicious data that the agent treated as authoritative); prompt regression (a system prompt change introduced an unintended behavioral shift); model drift (the underlying model produced different outputs for the same inputs after a version change); pact ambiguity (the agent's pact did not specify a behavior clearly enough and the agent's interpretation diverged from intent); adversarial input (a user input was crafted to exploit a weakness in the agent's logic); infrastructure failure (a dependency behaved differently than expected); operational error (a deployment or configuration change introduced the issue).

Each category has a different remediation pattern. Skill descriptor injection is remediated by tightening the skill manifest verification. Memory contamination is remediated by invalidating affected entries and tightening the ingestion checks. Prompt regression is remediated by reverting the prompt change and adding a regression test. Model drift is remediated by pinning model versions and adding eval coverage. Pact ambiguity is remediated by tightening the pact wording. Adversarial input is remediated by adding input validation and red-teaming. Infrastructure failure is remediated by adding monitoring and fallbacks. Operational error is remediated by adding deployment safety checks.

The root-cause output is a written document, signed by the investigators, attached to the incident record. The document states the symptom, the snapshot reference, the replay evidence, the hypothesis tested, the supported hypothesis, the category, and the recommended remediation. The document is short (typically one to two pages) but precise. Vagueness in the root cause document is a leading indicator of a future recurrence, because vague root causes do not produce specific fixes, and the underlying defect remains in the system waiting to surface again.

Step Six: Restore

Restore is the operation of returning the agent to service, or retiring it, based on what the root-cause investigation discovered. It is the last step in the runbook and the first step in the next phase of the agent's life. Restore has three variants: clean restore (the issue was a transient external factor and the agent itself is fine), patched restore (the agent had a fixable defect and is returned to service after the patch), and retirement (the agent has a deeper issue that requires either a major redesign or removal from production).

Clean restore is the simplest: the quarantine perimeter is removed, the agent is reactivated from the snapshot or from a recent clean state, and the input queue is allowed to drain again. The audit log records the incident, the investigation, and the determination that the agent itself was sound. The agent's pact compliance score may be temporarily affected, but only insofar as the system noticed the symptom; if the symptom is later confirmed external, the score impact can be reversed with appropriate audit annotation.

Patched restore involves more work. The defect identified in root-cause is fixed in the agent's source. The fix is built through the normal provenance pipeline (so that the new image has full attestation chain). The new image is deployed to a sandbox first and the original incident inputs are replayed against it; the bad behavior must not reproduce. The agent is then deployed to production, with the quarantine lifted, and is monitored at elevated sensitivity for the first observation window to catch any related issues. The patch and the verification are recorded in the incident record.

Retirement is the choice when the agent's defect is structural. Some agents need to be removed from production because the underlying design is wrong, or because the customer trust has been damaged beyond what a patch can repair, or because the workload would be better served by a different agent altogether. Retirement is itself a process: the agent is stopped, all in-flight work is migrated to alternative agents or queued for human handling, the agent's identity is marked retired in the trust oracle, and the agent's audit log is preserved permanently for any future inquiry. Retirement is not failure; it is the appropriate outcome for some incidents, and the runbook should treat it as a clean option rather than as something to avoid.

The failure mode at restore is restoration without the prior steps. An agent that is restarted without a snapshot, a replay, and a root cause is an agent that will likely fail again, because the underlying defect was not identified or fixed. Restore is the temptation to skip the rest of the runbook, because restoring service feels like the goal. The discipline is that restore is the last step, not the first, and that restoring without the prior work means the team is choosing to operate an agent they do not understand.

Reader Artifact: The Agent Recovery Runbook

The runbook below is the canonical structure for executing the six-step recovery. It is written as a sequenced procedure with explicit acceptance criteria and artifact deliverables at each step.

INCIDENT: <description>
DETECTED BY: <source>
DETECTED AT: <timestamp>
DECLARED BY: <responder>

STEP 1: STOP
  Action: Invoke runtime.suspendAgent(agentId)
  Acceptance: Agent process suspended within 10 seconds
  Acceptance: External state mutations from this agent halted
  Artifact: stop_event_id (in audit side-channel)

STEP 2: QUARANTINE
  Action: Apply quarantine policy (network isolation, credential rotation, queue redirect)
  Acceptance: Agent has no outbound network access to production
  Acceptance: Agent's credentials are revoked or rotated
  Acceptance: Pending input queue redirected to holding area
  Artifact: quarantine_perimeter_id

STEP 3: SNAPSHOT
  Action: Invoke runtime.snapshotAgent(agentId, incidentId)
  Acceptance: Process state captured
  Acceptance: Memory store captured to read-only snapshot store
  Acceptance: Configuration, prompts, schemas, skill manifests captured
  Acceptance: Recent input log bookmarked from audit side-channel
  Artifact: snapshot_id

STEP 4: FORENSICALLY REPLAY
  Action: Provision sandbox runtime, load snapshot, replay recent inputs
  Acceptance: Replay reproduces the original symptom in sandbox
  Acceptance: Hypothesis-modify-replay loop produces a defect demonstration
  Artifact: replay_trace, hypothesis_tests, defect_demo

STEP 5: ROOT-CAUSE
  Action: Author root cause document with category and remediation plan
  Acceptance: Document identifies a specific defect, not a symptom
  Acceptance: Category is one of the named categories
  Acceptance: Remediation plan is concrete and actionable
  Artifact: root_cause_doc

STEP 6: RESTORE
  Action: Choose clean / patched / retirement variant based on root-cause
  Sub-action (patched): Build fix through provenance pipeline, replay against sandbox
  Sub-action (patched): Deploy to production with elevated monitoring
  Sub-action (retirement): Migrate workload, mark identity retired in oracle, preserve audit
  Acceptance: Replay against fixed agent does not reproduce symptom
  Acceptance: Production deploy passes provenance verification
  Artifact: restore_outcome, post_incident_review_doc

INCIDENT CLOSED:
  Summary: <symptom + root cause + remediation>
  Audit chain: <list of audit entries linked to this incident>
  Snapshot: <snapshot_id>
  Affected agents: <other agents with potential same exposure>
  Followups: <related work items, monitoring additions, eval additions>

The runbook is short by design. Each step is a discrete operation with an acceptance criterion that the responder can check. Each step produces a named artifact that becomes part of the incident record. The runbook fits on a single page so that it can be followed under pressure, with no need to scroll, no need to look anything up, and no ambiguity about what comes next. The simplicity of the runbook is what makes it executable in the conditions where you actually need it.

Counter-Argument: This Is Too Heavyweight For Most Incidents

The counter-argument is that most agent incidents are minor: a blip in output quality, a temporary degradation, a single bad recommendation. Running a six-step formal runbook for every minor blip is operational overkill and will quickly exhaust the team. The pragmatic response is to handle most incidents informally and reserve the runbook for genuinely serious events.

This is partially right and largely wrong. The pragmatic right is that not every observed issue rises to the level of a formal incident. A single noisy output is not an incident; it is a data point. A short performance dip is not an incident; it is a signal worth watching. The threshold for declaring an incident should be calibrated to the workload: high for low-stakes recommendation agents, low for financial-state-changing agents. Below the threshold, the responder uses lighter-weight tools and informal investigation.

The largely wrong part is the framing that the formal runbook is overkill. The formal runbook exists for the case where it matters, and the case where it matters is rarely predictable in advance. An agent that has a minor blip today might be in the early stages of a major compromise; the difference between minor and major is often only visible in retrospect. The runbook is the discipline that makes the retrospective view possible, because it produces snapshots, replays, and root-cause documents that survive the incident. A team that handles every incident informally is a team that has no library of past incidents to learn from, and that team's response to the eventual major incident will be to improvise from scratch, which is exactly the failure mode the runbook prevents.

The practical rule is that the runbook should be cheap enough to invoke that the threshold for invoking it can be low. If the runbook takes a day to execute, the team will reserve it for catastrophes. If the runbook takes an hour, the team will use it for any moderately interesting incident. The investments that lower the runbook's cost (snapshot primitives that are fast and reliable, sandbox provisioning that is automated, replay tooling that is well-documented) pay back disproportionately, because they shift more incidents into the regime where the runbook is the natural response. Aim for the regime where invoking the runbook is the default.

The Post-Incident Review Is Where The Runbook Pays Off

The runbook ends with restore, but the value of the runbook is realized in what happens afterward. The post-incident review is the structured analysis that converts the artifacts produced during the incident (snapshots, replays, root-cause documents) into permanent organizational learning. A team that runs the runbook but skips the post-incident review captures the immediate value but loses the compounding value, and the next incident benefits much less than it should from the previous one.

The post-incident review is a structured meeting, scheduled within 48 hours of restore, with explicit attendees and a defined agenda. The attendees include the incident commander, the responders who executed the runbook, the engineers responsible for the affected agent, and a representative from the broader operations team who can carry learnings to other agents. The agenda walks through the runbook execution step by step: what the responder observed, what they decided, what artifact they produced, what they would do differently. The discussion is forensic, not blameful: the goal is to understand the response, not to evaluate the responders.

The meeting produces a post-incident review document, which is more than a summary of what happened. It includes the timeline (when each step started, when it completed, what the gap was if any), the artifacts produced (with references), the root cause (carried forward from the runbook), the broader impact (which other agents share related dependencies and might be affected), and the followup actions (specific tickets with owners and due dates). The followups are the most consequential part: they are what convert the incident's lessons into changes to the system. A review with no followups is a review that learned nothing.

The followups have categories. Code changes that fix the root cause directly are obvious. Test additions that catch the root cause if it recurs are essential. Monitoring additions that surface the early signal of the same class of issue are valuable. Runbook improvements that capture process gaps observed during the incident are important. Pact updates that tighten the agent's declared scope are sometimes warranted. Each followup gets an owner, a due date, and a verification criterion: how will we know this followup actually happened.

The followup tracking is the operational discipline that makes the runbook actually compound. A team that produces followups and lets them sit in a backlog learns nothing structural from incidents; a team that closes followups within their due dates is a team whose system literally improves with every incident. The closure rate of followups is a leading indicator of operational maturity, and tracking it explicitly (followups created per quarter, followups closed per quarter, mean time to closure) is one of the highest-leverage metrics an operations team can adopt. Over time, the rate at which the team's runbook executions produce closed followups is the rate at which the agent ecosystem matures, and that rate is observable.

Recovery As A Design Constraint For New Agents

The runbook described in this piece presumes a runtime that supports stop, snapshot, quarantine, and replay as first-class primitives. Many runtimes do not. Many agents are deployed in environments where the operator has only blunt tools available: kill the process, restart the container, deploy a different version. In these environments, the runbook is not just operationally awkward; large parts of it are simply unavailable. The right response is to treat recovery as a design constraint for new agents, with the runtime selection driven partly by the recovery capabilities the runtime provides.

The relevant recovery capabilities are: a stop primitive that suspends without killing, returning the agent to a state from which it can be resumed or analyzed. A snapshot primitive that captures the full state in a portable form. A quarantine primitive that isolates the agent's network and credential surface without requiring a redeploy. A replay environment that can execute a snapshotted agent against recorded inputs in a sandbox. An audit side-channel that retains all action history independent of the agent. Without these primitives, the runbook degrades from a structured procedure to a best-effort improvisation, and the team's ability to learn from incidents degrades correspondingly.

When evaluating an agent runtime for adoption, the recovery capability checklist should be a primary criterion. A runtime that excels at performance and developer experience but cannot snapshot a misbehaving agent is a runtime that will be operationally fragile under any meaningful incident pressure. The cost of switching runtimes after an incident has revealed the gap is usually much higher than the cost of selecting an appropriate runtime up front. The same logic applies to agent frameworks, deployment models, and monitoring stacks: recovery primitives should be a first-class consideration in every selection decision, not an afterthought.

This design constraint also flows back into agent architecture. Agents should be designed in ways that support snapshotting: stateful behavior should be externalized into explicit memory stores rather than embedded in process state, in-flight operations should be checkpointed to durable storage, side effects should be wrapped in idempotent operations that can be safely retried after a snapshot-restore. These design properties make snapshots smaller and more useful, and they make replay more faithful, and they make recovery more reliable. They are not free design choices; they impose structure on the agent that the developer might otherwise have skipped. The justification is that the structure pays back when something goes wrong, which it eventually will.

The broader principle is that recovery is not an operational concern bolted on after the agent ships; it is an architectural concern that shapes the agent from the start. Teams that internalize this build agents that are inherently recoverable; teams that do not build agents that fail in unrecoverable ways at the worst possible moments. The choice between the two is made at design time, often without explicit consideration, and the consequences are felt at incident time, often without an obvious path to remediation. Choose deliberately, and the runbook becomes a tool you actually get to use.

What Armalo Does

The Armalo runtime exposes stop, snapshot, and quarantine as first-class primitives that any operator can invoke through the dashboard or the API. Stop suspends the agent process within seconds, preserving state for subsequent forensic work. Snapshot captures the full agent state (process, memory, configuration, audit window) into a read-only artifact tagged with an incident identifier. Quarantine applies infrastructure-level isolation through the egress policy engine and credential service. Sandbox replay environments can be provisioned automatically from any snapshot, with the sandbox runtime configured to match the production runtime exactly. The audit side-channel preserves all incident-related events in the chained, signed log that the agent has no write authority over. Root-cause documents are stored as part of the incident record and linked back to the agent's pact compliance history, so that recurring root causes become visible as patterns. Restore variants (clean, patched, retired) are explicit in the runtime's lifecycle API, with each variant producing the appropriate downstream effects in the trust oracle and the agent registry.

FAQ

Q: Who decides when to declare an incident? A: Anyone with operational responsibility can declare. The threshold for declaration should be lower than the threshold for full root-cause investigation, because declaration triggers stop and snapshot, which are cheap and reversible. The investigation depth scales with the severity assessment after snapshot.

Q: What if multiple agents are affected at once? A: The runbook is per-agent. Multi-agent incidents run multiple instances of the runbook in parallel, with a coordinating incident commander tracking all of them. Common root causes (like a shared dependency change) are identified by comparing the per-agent root-cause documents.

Q: How do you handle incidents that span agent boundaries, where the bad behavior involves multiple agents in coordination? A: Each agent gets its own runbook execution, with the audit chains joined by shared decision identifiers and transaction identifiers. The cross-agent investigation walks the joined chains to reconstruct the coordinated behavior, but each individual agent's snapshot, replay, and root-cause are still per-agent.

Q: What if the snapshot is too large to be practical? A: Snapshot can be incremental: the immutable parts (image, configuration, pact) are referenced by hash rather than copied, and only the mutable parts (memory store deltas, recent inputs) are captured fully. The result is much smaller than a naive full snapshot, with no loss of replay fidelity.

Q: Can replay produce false confidence by reproducing a bug that has already been fixed in production? A: Yes, if the snapshot does not capture the production state accurately. The discipline is that snapshots must be taken at incident time, not reconstructed later, and replay must use the snapshot as source of truth. Replays from reconstructed state are not real replays; they are simulations of what we think the state was.

Q: How do you handle agents whose state cannot be fully snapshotted (live external connections, in-flight network requests)? A: Connections are part of the snapshot manifest but not the snapshot data itself. Replays in sandbox use mock or recorded versions of those connections, with the recording captured at incident time as part of the snapshot. The fidelity is bounded but usually sufficient for diagnostic purposes; perfect fidelity for live external dependencies is rarely achievable in any sandbox.

Q: What if root-cause is genuinely unknown? A: The root-cause document records that as the finding, with the evidence considered and the hypotheses ruled out. Unknown root causes are honest outcomes that warrant elevated monitoring and additional eval coverage rather than a forced false root cause. Restore in this case typically means patched restore with conservative settings or, more often, retirement until the root cause is understood.

Q: How do you prevent the runbook from being skipped under pressure? A: By making it cheap to execute and by treating runbook adherence as a measurable property of the operations team. Incident records track which steps were executed, in what order, with what artifacts. Audits of incident handling identify skipped steps and feed back into team training. Over time, runbook adherence becomes muscle memory rather than discipline.

Bottom Line

Misbehaving agents are not problems to improvise around. They are processes to execute, in order, with discipline. Stop ends the immediate damage. Quarantine bounds the perimeter. Snapshot preserves the evidence. Forensic replay reproduces the incident in a controlled environment. Root-cause produces understanding. Restore returns the agent to service or retires it cleanly. The runbook is short on purpose, so it can be executed under pressure. The artifacts it produces are durable on purpose, so the incident becomes organizational knowledge rather than a war story. Build the runbook before you need it. Practice it on minor incidents so that the major incidents do not catch you improvising. The agents you operate are too consequential to be left to ad hoc response, and the cost of building the runbook discipline is small compared to the cost of operating without it.