Tool Execution Pause-and-Resume Prompt Template

This playbook is for agent developers and platform engineers building long-running workflows where mid-execution human intervention is required. Use this prompt when an agent must pause before a high-risk tool call, serialize its full execution state, present a structured decision to a human operator, and resume cleanly after approval, modification, or rejection. The ideal user is someone integrating an AI agent into a production system where a single automated action—such as a database migration, a financial transfer, or a configuration push—could cause an outage or compliance violation if executed incorrectly. The required context includes the agent's accumulated reasoning trace, the specific tool and arguments it intends to invoke, and the operator's identity and authorization scope.

This is not for simple confirmation dialogs. A chat interface asking 'Are you sure?' before sending an email does not need a serialized checkpoint. This prompt is for multi-step agent runs that span minutes or hours and cannot be safely restarted from scratch. If your workflow is stateless, idempotent, or can be trivially replayed from the initial user request, a full checkpoint mechanism introduces unnecessary complexity. Similarly, if the human decision is always a binary approve/reject with no modification of the pending action, a simpler approval gate prompt will suffice. The checkpoint pattern becomes essential when the operator might need to alter the tool's arguments, inject new context, or when the agent's state has accumulated side effects from prior steps that must be preserved.

Before implementing this prompt, verify that your agent runtime supports true state serialization and resumption. The prompt produces a machine-readable checkpoint payload that includes pending actions, accumulated context, timeout handling, and stale-state detection. Your application layer must be able to persist this payload, present it to a human reviewer through a UI or notification system, accept a structured response, and feed it back into the agent's execution loop. Without this surrounding harness, the prompt alone cannot deliver a reliable pause-and-resume workflow. Validate your implementation by testing timeout scenarios, concurrent modification attempts, and cases where the operator rejects the action and requests a different path. The resume path must be auditable and reliable, with every decision logged for compliance review.

This prompt template implements a pause-and-resume mechanism for long-running agent tool workflows that require mid-execution human intervention. It instructs the model to serialize its current state—including completed steps, pending decisions, tool call history, and active context—into a structured checkpoint that a human operator can review, modify, or approve before the agent resumes execution. The template is designed for production systems where autonomous tool use must be interruptible, auditable, and resumable without losing context or repeating completed work.

textCopy
You are an agent executing a multi-step tool workflow that supports pause-and-resume checkpoints. Your current execution has been paused for human review. Below is your serialized state and the instructions for resuming.

## CHECKPOINT STATE
- **Workflow ID:** [WORKFLOW_ID]
- **Checkpoint Timestamp:** [CHECKPOINT_TIMESTAMP]
- **Checkpoint Reason:** [PAUSE_REASON]
- **Completed Steps:** [COMPLETED_STEPS]
- **Current Step:** [CURRENT_STEP]
- **Pending Decisions:** [PENDING_DECISIONS]
- **Tool Call History:** [TOOL_CALL_HISTORY]
- **Accumulated Context:** [ACCUMULATED_CONTEXT]
- **Active Constraints:** [ACTIVE_CONSTRAINTS]
- **Human Decision Required:** [DECISION_REQUIRED]
- **Decision Options:** [DECISION_OPTIONS]
- **Timeout Threshold:** [TIMEOUT_THRESHOLD]
- **Staleness Indicator:** [STALENESS_INDICATOR]

## RESUME INSTRUCTIONS
1. Read the checkpoint state above. Do not re-execute any completed steps listed in [COMPLETED_STEPS].
2. If [STALENESS_INDICATOR] is true, request fresh context before proceeding and flag any assumptions that may have expired.
3. Apply the human decision from [DECISION_REQUIRED] by selecting the approved option from [DECISION_OPTIONS].
4. Resume execution from [CURRENT_STEP], incorporating the human decision and any updated constraints.
5. If the checkpoint is older than [TIMEOUT_THRESHOLD], validate that all prior tool outputs and context are still valid before proceeding.
6. Continue the workflow using the available tools: [TOOLS].
7. If you encounter new conditions that require human judgment, produce a new checkpoint with updated state rather than proceeding autonomously.

## OUTPUT FORMAT
Produce a JSON object with the following schema:
{
  "acknowledgment": "string confirming checkpoint loaded and human decision applied",
  "staleness_check": {
    "is_stale": boolean,
    "stale_fields": ["list of fields that may be invalid"],
    "remediation": "string describing how staleness will be addressed"
  },
  "resume_action": "string describing the next step to execute",
  "tool_call": {
    "name": "string or null if no immediate tool call",
    "arguments": {}
  },
  "new_escalation_needed": boolean,
  "escalation_reason": "string or null"
}

## CONSTRAINTS
- Do not execute any tool call that was not explicitly approved in the human decision.
- If the checkpoint is stale, do not proceed with tool calls that depend on potentially invalid data.
- Preserve the full [TOOL_CALL_HISTORY] for audit trail continuity.
- If [RISK_LEVEL] is "high" or "critical," request re-confirmation before any irreversible action.

To adapt this template, replace each square-bracket placeholder with values from your workflow engine's state store. The [COMPLETED_STEPS] and [TOOL_CALL_HISTORY] fields should contain structured records—ideally JSON arrays—so the model can parse what has already occurred without ambiguity. The [STALENESS_INDICATOR] should be a computed boolean based on elapsed time since checkpoint creation and whether any upstream data sources have changed. For high-risk workflows, set [RISK_LEVEL] to "high" or "critical" to enforce re-confirmation gates. Wire the [DECISION_OPTIONS] as a constrained set of valid choices to prevent the model from inventing unauthorized paths. Test this template with stale checkpoints, missing decision fields, and edge cases where the human decision contradicts prior tool outputs to verify the model correctly escalates rather than silently proceeding.

The pause-and-resume prompt template is not a standalone artifact—it is a state machine checkpoint that must be integrated into an agent's execution loop. When the agent encounters a tool that requires human approval, the orchestration layer serializes the current execution state, pending decisions, tool call stack, and accumulated context into a structured payload. This payload becomes the input to the pause prompt, which produces a human-readable summary, a decision request, and a resume token. The orchestration layer then persists this checkpoint to a durable store (database, queue, or workflow engine) and suspends the agent's execution thread until a human response arrives or a timeout fires.

The implementation requires several components working together. State serialization must capture the full agent context: the original task, completed tool calls with their outputs, the pending tool call that triggered the pause, any intermediate reasoning, and a monotonic checkpoint ID. Use a schema that includes checkpoint_id, timestamp, agent_id, session_id, task_description, completed_steps[], pending_action{}, context_snapshot{}, and resume_instructions. Validation should verify that the serialized state is internally consistent—the pending action must reference a real tool in the agent's registry, completed steps must be in order, and the resume token must be cryptographically tied to the checkpoint to prevent tampering or replay. Storage should use a transactional write: persist the checkpoint and enqueue the approval request atomically to avoid orphaned states. For high-risk domains, append an immutable audit log entry recording that execution was paused and why.

Resume logic is the most failure-prone part of the harness. When a human decision arrives, the orchestration layer must load the checkpoint, validate that it has not expired (stale-state detection), apply the human's decision to the pending action, and rehydrate the agent's context. The resume prompt should receive the original checkpoint plus the human's response, and it should produce a continuation plan—either executing the approved action, applying modifications, or aborting with a rollback summary. Timeout handling requires a separate path: if no human response arrives within the configured SLA, the orchestration layer must invoke a timeout handler that can either auto-abort, escalate to a fallback reviewer, or execute a safe default. Log every timeout event with the checkpoint ID for operations visibility. Retry and idempotency are critical—the resume operation must be idempotent so that duplicate human responses or replay attempts do not execute the same action twice. Use the checkpoint ID as an idempotency key and check execution status before applying the decision.

Model choice affects reliability. For the pause prompt (generating the human-facing summary), prefer a model with strong instruction-following and structured output capabilities—the summary must be clear enough for a human operator to make an informed decision without reading the full agent trace. For the resume prompt (rehydrating context and continuing execution), use the same model family and version that the agent uses for its primary reasoning loop to avoid context interpretation drift. Tool integration requires that the orchestration layer can intercept tool calls before execution, check against a policy engine (which actions require approval), and inject the pause flow without the agent needing to know about it. This separation keeps the agent's reasoning prompt clean and makes the approval gate an infrastructure concern. Observability demands structured logging at every transition: checkpoint created, approval requested, human responded, timeout fired, resume succeeded, resume failed. Each log entry must carry the checkpoint ID, agent ID, and a correlation ID for tracing across systems.

Before shipping, test the full lifecycle: normal pause-and-resume, human rejection, human modification of the proposed action, timeout with auto-abort, timeout with escalation, duplicate human responses, resume after agent infrastructure restart, and resume with a stale checkpoint that references a tool version that has since changed. The most common production failures are stale state (checkpoint references resources that no longer exist), incomplete serialization (missing context causes the agent to lose track of what it was doing), and resume-token mismatch (the human response references a different checkpoint than the one loaded). Build evals that measure whether the resumed agent produces the same quality of output as an uninterrupted execution, and whether the human-facing summary contains enough information for operators to make decisions without opening a support ticket.