Guided multi-step workflow
Recover and Requalify an Interrupted AI Agent Runtime
Reconcile interrupted durable state and side effects, conditionally recertify tool access and fallback behavior, then calibrate escalation controls before resuming an AI agent runtime.
# Recover and Requalify an Interrupted AI Agent Runtime Workflow ID: AMO-W-000022 Workflow URL: https://amo.ng/workflows/recover-requalify-interrupted-ai-agent-runtime ## Outcome A controlled recovery package containing a state and side-effect ledger, resume or compensation decision, applicable permission and fallback dispositions, recalibrated escalation rules, verification evidence, and accountable restart conditions. ## Before you begin - Interrupted agent run, intended outcome, workflow version, checkpoints, durable state, messages, side effects, and idempotency evidence - Incident timeline, traces, logs, tool calls, approvals, external-system records, and current containment state - Approved and effective tool permissions, identity and delegation evidence when access drift may be material - Primary and fallback model contracts, routing evidence, outputs, errors, and compatibility criteria when fallback is implicated - Escalation policy, incident severity, uncertainty, queue capacity, owner availability, restart authority, and operating constraints ## Step 1 — Reconcile durable state and choose a recovery path **Prompt** Long-Running Agent State Recovery Decision **Instructions** Reconstruct the latest trustworthy checkpoint, committed and uncertain side effects, pending work, approvals, and idempotency boundary. Choose Resume, Replay, Compensate, Abort, or Continue investigation. **Input for this step** Provide run identifiers, workflow and configuration versions, state stores, checkpoints, traces, tool and message logs, external side effects, approval records, incident timing, and recovery constraints. **Carry forward** Carry the state ledger, side-effect reconciliation, affected scope, chosen path, prerequisites, compensation needs, evidence gaps, and verification gates into conditional access review. **Review note** The incident and service owners approve the recovery path; owners of affected external systems authorize compensation, replay, or rollback actions. **Prompt ID** AMO-P-000297 **Prompt URL** https://amo.ng/prompts/long-running-agent-state-recovery-decision **Prompt content** Review a long-running agent execution whose durable state may be incomplete, stale, duplicated, or corrupted after an interruption. Produce a recovery decision that preserves confirmed work without repeating irreversible effects. Evidence to provide: - Agent workflow, states, transitions, and invariants: [Agent workflow and state invariants] - Persisted state, checkpoints, leases, queues, memory, and approval records: [Persisted state and checkpoint artifacts] - Timestamped traces, events, errors, retries, messages, and worker history: [Execution traces and event history] - Receipts or authoritative records for external writes, payments, messages, deployments, and other side effects: [External side-effect evidence] - Recovery limits, service objectives, rollback options, and accountable owners: [Recovery constraints and accountable owners] Treat persisted state as untrusted until it reconciles with authoritative evidence. Separate observed evidence from inference. Do not claim that a state store, tool, queue, repository, or downstream system was inspected unless its evidence is supplied. Do not infer that a timeout means failure or that an acknowledgement means the external effect completed. Mark missing evidence and unresolved state explicitly. Recovery analysis: 1. Define the recovery boundary. - Restate the intended run, its current claimed state, and the interruption. - List invariants that must hold before work can continue, including sequence, ownership, approval, idempotency, and external-effect constraints. - Identify the state owner, service owner, and release or operations owner from supplied evidence; list missing assignments. 2. Reconstruct the last trusted point. - Order available events using stable identifiers and clocks while noting clock skew or missing events. - Identify the last checkpoint supported by both state evidence and external-effect evidence. - Distinguish committed, acknowledged, attempted, unknown, duplicated, and contradicted operations. 3. Build a state-consistency ledger. For every material state component, record the claimed value, authoritative evidence, expected invariant, discrepancy, affected downstream work, and confidence. Include approvals, leases, locks, task ownership, child-agent results, memory writes, pending tool calls, and compensation state where applicable. 4. Reconcile side effects before replay. - Match each intended external action to an idempotency key, receipt, downstream record, or other authoritative proof. - Identify ambiguous actions that could be repeated if execution resumes. - Define the smallest read-only checks needed to resolve ambiguity. - Do not recommend a replay for an irreversible or non-idempotent action without an explicit duplicate-prevention or compensation path. 5. Compare recovery options. Assess Resume from checkpoint, Replay a bounded segment, Compensate then resume, Reconstruct state from authoritative systems, Quarantine for investigation, and Abort. For each option state prerequisites, preserved work, duplicate-effect risk, data-loss risk, approval needs, observability needs, and recovery cost. 6. Select a recovery disposition. Choose one primary disposition and explain why alternatives are less safe. Define the exact state boundary, allowed next action, prohibited actions, owner, approval requirement, and stop conditions. If evidence is insufficient, choose Quarantine rather than presenting a speculative recovery as safe. 7. Define verification. Specify checks for state invariants, external effects, task ownership, duplicate suppression, downstream consistency, monitoring, and a bounded canary or dry-run where the system supports it. Label every proposed check as not yet executed unless results were supplied. Required deliverable: # Agent State Recovery Decision ## Recovery Scope and Last Trusted Point - Execution under review: - Interruption: - Last trusted checkpoint: - Evidence limitations: ## State-Consistency Ledger | State component | Claimed state | Authoritative evidence | Required invariant | Discrepancy | Downstream exposure | Confidence | |---|---|---|---|---|---|---| ## Side-Effect Reconciliation | Intended action | Stable key | Evidence status | Actual effect | Replay risk | Read-only check needed | Owner | |---|---|---|---|---|---|---| ## Recovery Options | Option | Preconditions | Preserved work | Data-loss risk | Duplicate-effect risk | Approval | Viability | |---|---|---|---|---|---|---| ## Recovery Disposition - Decision: Resume / Replay bounded segment / Compensate then resume / Reconstruct / Quarantine / Abort - Exact recovery boundary: - Allowed next action: - Prohibited actions: - Accountable owner: - Required approval: - Stop conditions: ## Verification Record | Check | Evidence required | Expected result | Owner | Status | |---|---|---|---|---| Completion requires a defensible last trusted point, reconciliation of every consequential side effect, an owner-approved recovery boundary, and observable checks that would detect duplicate work or further corruption. Unresolved state must remain visible in the disposition. ## Step 2 — Recertify effective tool access when applicable **Prompt** Tool Permission Drift Investigation **Instructions** Run this step when tool permission drift could have caused, amplified, or outlived the interruption. Otherwise record Not applicable with evidence. Reconcile approved and effective access across identities, tools, environments, and time. **Input for this step** Use the state findings with approved access, runtime policy, role and group data, credential or token metadata, tool schemas, audit logs, changes, exceptions, and current containment evidence. **Carry forward** Carry the permission-drift register, excess or missing access, affected actions, containment and recertification needs, owners, and regression gates into fallback review. **Review note** Security, identity, tool, and service owners authorize access changes and recertification; absence of logs is not evidence that drift did not occur. **Prompt ID** AMO-P-000298 **Prompt URL** https://amo.ng/prompts/tool-permission-drift-investigation **Prompt content** Investigate suspected permission drift across an AI agent or automation toolchain. Compare what was approved with what identities, tokens, connectors, roles, and tools could actually do at each material point in time. Inputs: - Approved roles, scopes, tools, actions, resources, environments, and expiration conditions: [Approved permission baseline] - Effective grants, token scopes, policy evaluations, connector capabilities, and resource permissions: [Current effective permission evidence] - Agent identities, service accounts, role assumptions, delegated grants, and ownership: [Identity role and delegation records] - Configuration, deployment, policy, connector, group, and credential changes: [Change and deployment history] - Timestamped tool calls, denied requests, access logs, and material side effects: [Tool usage and access logs] - Containment limits, operational dependencies, recertification cadence, and accountable owners: [Containment constraints and owners] Use supplied evidence only. Do not claim live access to identity providers, cloud consoles, MCP servers, tools, or logs. Treat capability descriptions and configured scopes as claims until corroborated by authoritative effective-access evidence. Distinguish the ability to invoke a tool from the ability to affect a particular resource. Mark inherited, conditional, time-bound, and environment-specific access separately. Investigation method: 1. Define the expected boundary. - Translate the approval baseline into testable subject-action-resource-environment conditions. - Identify the accountable tool owner, identity owner, security reviewer, and service owner from supplied evidence. - Record missing approvals, owners, expiry dates, or purpose limitations. 2. Build an effective-access timeline. - Map identities, credentials, groups, roles, connectors, and downstream policies at each relevant change point. - Explain how effective access was derived, including inheritance, wildcard scopes, role chaining, default permissions, cached tokens, and stale sessions. - Separate observed grants from inferred reachability. 3. Create a permission-drift register. Classify each difference as Intended approved change, Unapproved expansion, Stale retained access, Incorrect reduction, Ambiguous baseline, Compensating control dependency, or Evidence gap. Record when it began, likely cause, affected resources, exercised use, and exposure window. 4. Determine actual use and consequence. - Link effective permissions to observed tool calls without assuming unused access caused an incident. - Identify sensitive read, write, delete, execute, impersonate, delegation, and secret-access capabilities. - Distinguish latent exposure from confirmed use and confirmed side effect. 5. Recommend the smallest safe containment. Prioritize expiring or reducing the specific grant, token, role, or connector path responsible for the drift. Account for availability dependencies and emergency access. Do not recommend broad credential revocation when a narrower verified control would contain the exposure. 6. Define restoration and recertification. Specify the intended least-privilege state, evidence required to restore any removed capability, owner approvals, token/session invalidation checks, negative permission tests, and recurring drift detection. If the approved baseline, effective-access evidence, or change history is missing or contradictory, request the blocking evidence once and do not close the investigation. Continue only with bounded analysis, label unresolved permissions Unknown, and state how each missing item limits containment or recertification. Required deliverable: # Tool Permission Drift Investigation ## Approved Boundary | Subject or role | Allowed action | Resource | Environment | Purpose/condition | Expiry | Approval evidence | |---|---|---|---|---|---|---| ## Effective-Access Timeline | Time/change | Identity/credential | Effective capability | Derivation evidence | Confidence | Exposure window | |---|---|---|---|---|---| ## Drift Register | Drift | Classification | Baseline | Effective state | Cause evidence | Exercised? | Risk | Owner | |---|---|---|---|---|---|---|---| ## Containment Decision | Priority | Smallest safe action | Capability affected | Dependency risk | Authorization | Verification | |---|---|---|---|---|---| ## Recertification Plan - Target permission state: - Required negative tests: - Token/session invalidation checks: - Owners and approvals: - Monitoring and review cadence: - Unresolved evidence: The investigation is complete only when every material effective permission is reconciled to an approved purpose or listed as unresolved, excess access has a bounded containment owner, and recertification can prove both required access and denied unauthorized access. ## Step 3 — Requalify model fallback when applicable **Prompt** Model Fallback Failure Analysis **Instructions** Run this step when fallback selection or contract incompatibility contributed to the incident or could affect recovery. Otherwise record Not applicable and why. Compare route contracts, capabilities, outputs, safety behavior, latency, failure semantics, and recovery conditions. **Input for this step** Provide routing policy, primary and fallback model versions and contracts, request and response traces, tool or schema requirements, errors, evaluation evidence, constraints, and prior findings. **Carry forward** Carry the fallback failure mechanism, compatibility matrix, restricted or disabled routes, corrective tests, re-enable gate, and unresolved evidence into escalation calibration. **Review note** Model, product, security, and release owners approve fallback restrictions and any re-enablement decision. **Prompt ID** AMO-P-000299 **Prompt URL** https://amo.ng/prompts/model-fallback-failure-analysis **Prompt content** Analyze a production failure in which traffic was routed from a primary model or configuration to a fallback and the fallback did not preserve the required service contract. Evidence to provide: - Routing rules, triggers, priorities, circuit breakers, and fallback chain: [Routing and fallback policy] - Required and observed capabilities, context limits, schemas, tool behavior, safety controls, and response contracts: [Primary and fallback model contracts] - Timestamped routing decisions, requests, responses, errors, retries, and downstream effects: [Incident traces and outputs] - Relevant offline evaluations, canary results, service metrics, user feedback, and accepted thresholds: [Evaluation and operational evidence] - Data residency, privacy, security, policy, tool-access, and contractual constraints: [Data tool and compliance constraints] - Repair, restriction, disablement, and communication options with accountable owners: [Recovery options and owners] Do not assume that a fallback is a drop-in substitute because it accepts the same request shape. Separate routing evidence, model behavior, integration behavior, and downstream handling. Do not claim a live reproduction or test unless results are supplied. Label missing route decisions, hidden provider behavior, and unobserved failures as unknown. Analysis: 1. Restate the service contract. Define the minimum quality, safety, structured-output, tool-use, latency, availability, data-boundary, and observability requirements that every fallback route must preserve. Distinguish mandatory invariants from degradable features. 2. Reconstruct the fallback path. Identify the trigger, routing decision, model/config selected, request transformation, context truncation, tool or schema adaptation, response validation, retries, and final downstream action. Mark the first point where evidence diverges from expected behavior. 3. Classify incompatibilities. Examine capability gaps, prompt/config differences, unsupported tools, schema drift, context loss, safety-policy differences, modality gaps, tokenizer or stop behavior, latency budget exhaustion, data-location conflicts, and error-normalization problems. Distinguish confirmed causes from plausible contributors. 4. Assess blast radius. Determine affected traffic slices, time window, user groups, task types, regions, and downstream systems using supplied evidence. Identify silent failures, incorrect success signals, unsafe outputs, repeated side effects, and records needing revalidation. 5. Evaluate controls. Review pre-route eligibility, health checks, compatibility tests, response validation, confidence or abstention rules, circuit breaking, observability, and disablement controls. Explain which control should have detected or contained the failure and why it did not. 6. Compare dispositions. Assess Repair and re-enable, Restrict fallback to compatible slices, Add an intermediate degraded mode, Route to manual handling, or Disable fallback. For each, specify evidence prerequisites, residual risk, user impact, and rollback. 7. Define proof before re-enable. Create task- and slice-specific compatibility tests, negative tests, schema/tool checks, canary gates, monitoring thresholds, and an owner decision. Avoid claiming equivalence beyond tested slices. Treat this as model-routing incident analysis and fallback-design evidence for release readiness, not as permission to alter routing. The service owner and release owner must approve any re-enablement or production change. Require regression-testing acceptance evidence that names each fallback contract check, its expected observation, the actual observation when supplied, and any unreconciled reliability gap. Proposed repairs and tests remain not executed unless their results are provided. Required deliverable: # Model Fallback Failure Analysis ## Service Contract | Requirement | Mandatory/degradable | Primary behavior | Required fallback behavior | Evidence | |---|---|---|---|---| ## Fallback Reconstruction | Sequence | Routing or transformation event | Expected | Observed | Evidence | Confidence | |---:|---|---|---|---|---| ## First Divergence and Cause Tree - First evidenced divergence: - Confirmed causes: - Contributing conditions: - Unresolved hypotheses: ## Compatibility and Control Gaps | Gap | Affected slice | Consequence | Existing control | Control failure | Remediation | |---|---|---|---|---|---| ## Blast Radius | Slice/window | Exposure evidence | Failure mode | Downstream action | Revalidation needed | |---|---|---|---|---| ## Fallback Disposition - Decision: Re-enable / Restrict / Degraded mode / Manual route / Disable - Allowed scope: - Preconditions: - Accountable service and release owners: - Rollback trigger: - Residual uncertainty: ## Re-Enablement Gate | Test or control | Slice | Acceptance threshold | Evidence owner | Status | |---|---|---|---|---| Completion requires a trace-supported first divergence, bounded blast radius, an explicit fallback disposition, and compatibility evidence for every slice proposed for re-enablement. ## Step 4 — Calibrate escalation and restart conditions **Prompt** Agent Escalation Threshold Calibration **Instructions** Tune escalation triggers using incident severity, uncertainty, false-positive and false-negative evidence, queue capacity, response delay, and owner authority. Reconcile the thresholds with the recovery, access, and fallback findings. **Input for this step** Provide current escalation rules, incident and near-miss data, severity and uncertainty definitions, queues and response times, owner schedules, containment options, and all prior outputs. **Carry forward** Produce the final recovery and requalification package with restart or containment decision, thresholds, routing, owners, verification, monitoring window, rollback, and re-review triggers. **Review note** The service and incident owners approve operating thresholds; the release owner authorizes restart after security and model owners close applicable gates. **Prompt ID** AMO-P-000316 **Prompt URL** https://amo.ng/prompts/agent-escalation-threshold-calibration **Prompt content** Calibrate escalation thresholds for an AI agent using evidence about severity, uncertainty, control failures, reviewer capacity, delay, and actual outcomes. Distinguish thresholds that pause work from those that route routine review or trigger urgent containment. Provide: - Agent tasks, user groups, decisions/actions, risk classes, protected outcomes, and unacceptable failures: [Agent decisions and risk classes] - Rules, scores, confidence/uncertainty signals, triggers, routes, priorities, context package, and fallback behavior: [Current escalation logic and routes] - Incidents, near misses, reviewer decisions, overrides, missed escalations, unnecessary escalations, user requests, and downstream outcomes: [Incident feedback and outcome evidence] - Score distributions, calibration, labels, disagreement, slices, drift, missingness, and historical threshold changes: [Score uncertainty and threshold evidence] - Arrival volume, service targets, reviewer skill, coverage hours, queue age, abandonment, and surge capacity: [Queue capacity and service constraints] - Non-delegable approvals, service owner, product owner, review owner, security/privacy reviewer, and emergency authority: [Authority boundaries and accountable owners] Do not invent score distributions, error rates, or queue behavior. Distinguish observed outcome evidence from inference. Do not optimize for fewer escalations without pricing missed harm, or for maximum sensitivity without considering delay and reviewer overload. Separate uncertain model scores from independently observed risk triggers. Preserve user-requested escalation and mandatory policy triggers even if statistical tuning suggests otherwise. Calibration: 1. Define escalation classes. Specify Continue, Clarify, Abstain, Routine review, Priority review, Immediate pause/containment, and Emergency response as applicable. State purpose, owner, service target, and allowed agent behavior while waiting. 2. Build the outcome ledger. Reconcile current trigger decisions with reviewer outcomes, incidents, corrections, and downstream consequences. Identify true positive, false positive, true negative, false negative, and not-assessable cases only where labels support them. 3. Audit signals. Review definition, calibration, stability, missing values, manipulability, protected slices, and independence. Identify hard rules that must override probabilistic thresholds. 4. Model threshold trade-offs. Compare candidate thresholds using supplied confusion, severity, workload, and delay evidence. Show how volume and queueing change, and identify where performance is not estimable. 5. Protect critical slices and events. Define zero- or low-tolerance triggers for irreversible action, sensitive data, safety, legal/compliance, identity/authorization, user distress, or explicit review requests where applicable. Assign qualified routes. 6. Test operational feasibility. Check reviewer capacity, skills, hours, context quality, queue priority, fallback, and outage behavior. A threshold is not deployable if the designated route cannot meet the required response. 7. Recommend thresholds and rollout. Specify thresholds, hard triggers, hysteresis or cooldown if needed, context package, staged rollout, shadow comparison, monitoring, drift and queue alerts, stop conditions, and recalibration cadence. Use ChatGPT to analyze the supplied incidents, thresholds, and reviewer-capacity evidence; do not claim simulation, deployment, or threshold validation occurred unless results are supplied. Keep proposed threshold changes distinct from approved configuration, and identify the accountable operations owner and release owner for authorization. Required deliverable: # Agent Escalation Threshold Calibration ## Escalation Classes and Authority | Class | Trigger purpose | Agent behavior while pending | Route/owner | Service target | Mandatory rule | |---|---|---|---|---|---| ## Outcome and Error Ledger | Slice/trigger | Escalations | Confirmed needed | Unnecessary | Missed | Consequence | Evidence quality | |---|---:|---:|---:|---:|---|---| ## Signal Fitness | Signal | Meaning | Calibration/stability | Missing/manipulation risk | Fit for threshold? | |---|---|---|---|---| ## Candidate Thresholds | Slice/class | Threshold/rule | Expected miss/over-route effect | Queue impact | Risk | Evidence limit | |---|---|---|---|---|---| ## Recommended Policy | Slice/event | Continue threshold | Review threshold | Pause/containment trigger | Route | Owner | |---|---|---|---|---|---| ## Rollout and Recalibration - Shadow/canary plan: - Queue and incident stop conditions: - Protected hard rules: - Drift/recalibration triggers: - Evidence still needed: Completion requires outcome-linked thresholds, feasible review routes, preserved mandatory authority boundaries, and monitoring that detects both missed harm and overload. ## Completion criteria The workflow is complete when: - Durable state, committed side effects, pending work, approvals, and uncertainty are reconciled for the interrupted run. - The path is explicitly Resume, Replay, Compensate, Abort, or Continue investigation with prerequisites and idempotency controls. - Permission and fallback reviews are completed when applicable or marked Not applicable with evidence. - Escalation triggers account for severity, uncertainty, response delay, queue capacity, and decision authority. - Restart or continued containment has observable verification, stop, rollback, and owner conditions; no recovery action is claimed without evidence. # Recover and Requalify an Interrupted AI Agent Runtime Workflow ID: AMO-W-000022 Workflow URL: https://amo.ng/workflows/recover-requalify-interrupted-ai-agent-runtime Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: A controlled recovery package containing a state and side-effect ledger, resume or compensation decision, applicable permission and fallback dispositions, recalibrated escalation rules, verification evidence, and accountable restart conditions. Required inputs: - Interrupted agent run, intended outcome, workflow version, checkpoints, durable state, messages, side effects, and idempotency evidence - Incident timeline, traces, logs, tool calls, approvals, external-system records, and current containment state - Approved and effective tool permissions, identity and delegation evidence when access drift may be material - Primary and fallback model contracts, routing evidence, outputs, errors, and compatibility criteria when fallback is implicated - Escalation policy, incident severity, uncertainty, queue capacity, owner availability, restart authority, and operating constraints ## Step 1 — Reconcile durable state and choose a recovery path **Instructions** Reconstruct the latest trustworthy checkpoint, committed and uncertain side effects, pending work, approvals, and idempotency boundary. Choose Resume, Replay, Compensate, Abort, or Continue investigation. **Input for this step** Provide run identifiers, workflow and configuration versions, state stores, checkpoints, traces, tool and message logs, external side effects, approval records, incident timing, and recovery constraints. **Carry forward** Carry the state ledger, side-effect reconciliation, affected scope, chosen path, prerequisites, compensation needs, evidence gaps, and verification gates into conditional access review. **Review note** The incident and service owners approve the recovery path; owners of affected external systems authorize compensation, replay, or rollback actions. **Prompt** Long-Running Agent State Recovery Decision **Prompt ID** AMO-P-000297 **Prompt URL** https://amo.ng/prompts/long-running-agent-state-recovery-decision ## Step 2 — Recertify effective tool access when applicable **Instructions** Run this step when tool permission drift could have caused, amplified, or outlived the interruption. Otherwise record Not applicable with evidence. Reconcile approved and effective access across identities, tools, environments, and time. **Input for this step** Use the state findings with approved access, runtime policy, role and group data, credential or token metadata, tool schemas, audit logs, changes, exceptions, and current containment evidence. **Carry forward** Carry the permission-drift register, excess or missing access, affected actions, containment and recertification needs, owners, and regression gates into fallback review. **Review note** Security, identity, tool, and service owners authorize access changes and recertification; absence of logs is not evidence that drift did not occur. **Prompt** Tool Permission Drift Investigation **Prompt ID** AMO-P-000298 **Prompt URL** https://amo.ng/prompts/tool-permission-drift-investigation ## Step 3 — Requalify model fallback when applicable **Instructions** Run this step when fallback selection or contract incompatibility contributed to the incident or could affect recovery. Otherwise record Not applicable and why. Compare route contracts, capabilities, outputs, safety behavior, latency, failure semantics, and recovery conditions. **Input for this step** Provide routing policy, primary and fallback model versions and contracts, request and response traces, tool or schema requirements, errors, evaluation evidence, constraints, and prior findings. **Carry forward** Carry the fallback failure mechanism, compatibility matrix, restricted or disabled routes, corrective tests, re-enable gate, and unresolved evidence into escalation calibration. **Review note** Model, product, security, and release owners approve fallback restrictions and any re-enablement decision. **Prompt** Model Fallback Failure Analysis **Prompt ID** AMO-P-000299 **Prompt URL** https://amo.ng/prompts/model-fallback-failure-analysis ## Step 4 — Calibrate escalation and restart conditions **Instructions** Tune escalation triggers using incident severity, uncertainty, false-positive and false-negative evidence, queue capacity, response delay, and owner authority. Reconcile the thresholds with the recovery, access, and fallback findings. **Input for this step** Provide current escalation rules, incident and near-miss data, severity and uncertainty definitions, queues and response times, owner schedules, containment options, and all prior outputs. **Carry forward** Produce the final recovery and requalification package with restart or containment decision, thresholds, routing, owners, verification, monitoring window, rollback, and re-review triggers. **Review note** The service and incident owners approve operating thresholds; the release owner authorizes restart after security and model owners close applicable gates. **Prompt** Agent Escalation Threshold Calibration **Prompt ID** AMO-P-000316 **Prompt URL** https://amo.ng/prompts/agent-escalation-threshold-calibration Completion criteria: The workflow is complete when: - Durable state, committed side effects, pending work, approvals, and uncertainty are reconciled for the interrupted run. - The path is explicitly Resume, Replay, Compensate, Abort, or Continue investigation with prerequisites and idempotency controls. - Permission and fallback reviews are completed when applicable or marked Not applicable with evidence. - Escalation triggers account for severity, uncertainty, response delay, queue capacity, and decision authority. - Restart or continued containment has observable verification, stop, rollback, and owner conditions; no recovery action is claimed without evidence.Copy Workflow copies all steps and their linked Prompt instructions. Use with AI copies a shorter guide with links to the source Prompts. Both actions only copy text. Run this Workflow in Workplace opens the guided Workflow Runner for supported steps.
Outcome
A controlled recovery package containing a state and side-effect ledger, resume or compensation decision, applicable permission and fallback dispositions, recalibrated escalation rules, verification evidence, and accountable restart conditions.
Before you begin
Gather the required inputs before starting. Keep missing information visible and follow each step’s review guidance before continuing.
- Interrupted agent run, intended outcome, workflow version, checkpoints, durable state, messages, side effects, and idempotency evidence
- Incident timeline, traces, logs, tool calls, approvals, external-system records, and current containment state
- Approved and effective tool permissions, identity and delegation evidence when access drift may be material
- Primary and fallback model contracts, routing evidence, outputs, errors, and compatibility criteria when fallback is implicated
- Escalation policy, incident severity, uncertainty, queue capacity, owner availability, restart authority, and operating constraints
Ordered sequence
Workflow steps
Complete the steps in order. Review each result before carrying approved information into the next step. Some steps can run in Workplace; manual or external steps remain clearly identified.
-
Step 1 Reconcile durable state and choose a recovery path
Reconstruct the latest trustworthy checkpoint, committed and uncertain side effects, pending work, approvals, and idempotency boundary. Choose Resume, Replay, Compensate, Abort, or Continue investigation.
Prompt: Long-Running Agent State Recovery DecisionInput for this step
Provide run identifiers, workflow and configuration versions, state stores, checkpoints, traces, tool and message logs, external side effects, approval records, incident timing, and recovery constraints.
Carry forward
Carry the state ledger, side-effect reconciliation, affected scope, chosen path, prerequisites, compensation needs, evidence gaps, and verification gates into conditional access review.
Review note
The incident and service owners approve the recovery path; owners of affected external systems authorize compensation, replay, or rollback actions.
-
Step 2 Recertify effective tool access when applicable
Run this step when tool permission drift could have caused, amplified, or outlived the interruption. Otherwise record Not applicable with evidence. Reconcile approved and effective access across identities, tools, environments, and time.
Prompt: Tool Permission Drift InvestigationInput for this step
Use the state findings with approved access, runtime policy, role and group data, credential or token metadata, tool schemas, audit logs, changes, exceptions, and current containment evidence.
Carry forward
Carry the permission-drift register, excess or missing access, affected actions, containment and recertification needs, owners, and regression gates into fallback review.
Review note
Security, identity, tool, and service owners authorize access changes and recertification; absence of logs is not evidence that drift did not occur.
-
Step 3 Requalify model fallback when applicable
Run this step when fallback selection or contract incompatibility contributed to the incident or could affect recovery. Otherwise record Not applicable and why. Compare route contracts, capabilities, outputs, safety behavior, latency, failure semantics, and recovery conditions.
Prompt: Model Fallback Failure AnalysisInput for this step
Provide routing policy, primary and fallback model versions and contracts, request and response traces, tool or schema requirements, errors, evaluation evidence, constraints, and prior findings.
Carry forward
Carry the fallback failure mechanism, compatibility matrix, restricted or disabled routes, corrective tests, re-enable gate, and unresolved evidence into escalation calibration.
Review note
Model, product, security, and release owners approve fallback restrictions and any re-enablement decision.
-
Step 4 Calibrate escalation and restart conditions
Tune escalation triggers using incident severity, uncertainty, false-positive and false-negative evidence, queue capacity, response delay, and owner authority. Reconcile the thresholds with the recovery, access, and fallback findings.
Prompt: Agent Escalation Threshold CalibrationInput for this step
Provide current escalation rules, incident and near-miss data, severity and uncertainty definitions, queues and response times, owner schedules, containment options, and all prior outputs.
Carry forward
Produce the final recovery and requalification package with restart or containment decision, thresholds, routing, owners, verification, monitoring window, rollback, and re-review triggers.
Review note
The service and incident owners approve operating thresholds; the release owner authorizes restart after security and model owners close applicable gates.
Completion criteria
The workflow is complete when:
- Durable state, committed side effects, pending work, approvals, and uncertainty are reconciled for the interrupted run.
- The path is explicitly Resume, Replay, Compensate, Abort, or Continue investigation with prerequisites and idempotency controls.
- Permission and fallback reviews are completed when applicable or marked Not applicable with evidence.
- Escalation triggers account for severity, uncertainty, response delay, queue capacity, and decision authority.
- Restart or continued containment has observable verification, stop, rollback, and owner conditions; no recovery action is claimed without evidence.
Was this useful?
Related Workflows
Browse WorkflowsImplement CRM Lead Routing with n8n in Staging
Reconcile current lead-routing and SLA evidence, design the n8n flow, configure CRM-side controls in sandbox, implement the n8n orchestration in staging, and verify retry/recovery safety.
Design a Governed AI Support Triage Pilot
Assess support knowledge, design bounded AI-assisted triage and human escalation, establish sensitive-data and quality controls, and define evidence-based pilot entry, exit, and expansion decisions.
Investigate an AI Agent Security Incident
Reconstruct an AI agent incident, trace delegated authority and sensitive context, conditionally investigate memory or RAG authorization, and prepare evidence-based containment and recovery gates.