Sequential Confirmation Gate Prompt Between Tool Calls

This prompt is for product teams building multi-step agent workflows that must pause and request human approval before executing a high-risk tool call. The job-to-be-done is not to decide if a tool should be called, but to produce a machine-readable gate definition that your application harness can enforce. The ideal user is an AI engineer or product developer integrating an LLM into an orchestration layer that already has tool execution, logging, and user notification capabilities. You need this prompt when your agent is about to send a payment, publish content, modify a production database, or execute any side effect that your organization's policy requires a human to sign off on. The prompt's output is a structured gate object—not the execution of the tool itself—which your system reads to render a confirmation UI, start a timeout timer, and route the human's decision back to the agent's execution loop.

Use this prompt only when you have a real execution harness that can act on its output. The harness must be able to: (1) intercept a tool call before execution, (2) render the gate's presentation fields to a human reviewer, (3) enforce the timeout_seconds and default_action policies, and (4) resume or abort the agent workflow based on the reviewer's response. This prompt does not replace your authorization logic, audit logging, or role-based access control (RBAC). It is a behavioral contract for the model to declare what needs confirmation and how the confirmation flow should behave. If your system lacks a review queue, notification channel, or the ability to pause a stateful agent run, this prompt will produce a definition you cannot enforce, creating a false sense of safety. Do not use this prompt for low-risk read operations, internal logging calls, or any tool where a wrong execution would be merely inconvenient rather than harmful.

Before implementing this prompt, ensure you have defined which tools in your registry require confirmation gates. The prompt works best when paired with a tool schema that includes a risk_level or requires_approval metadata field, so the model can reason about gating without guessing your policy. After integrating this prompt, test it against edge cases: a tool call that arrives right at a timeout boundary, a reviewer who rejects with a reason, a reviewer who never responds, and a tool call that depends on the output of a previously gated call. The next section provides the prompt template you will adapt to your specific tool schemas, risk policies, and review UI constraints.

This prompt template defines a confirmation gate that sits between two tool calls in a sequential workflow. It instructs the model to pause execution after a specified tool completes, present a structured summary of the action taken and the proposed next step to a human reviewer, and wait for an explicit approval or rejection signal before proceeding. The template is designed to be wired into an orchestration layer that can actually enforce the pause—the prompt defines the gate logic, but your application must implement the blocking mechanism.

codeCopy
SYSTEM: You are an execution gate controller in a multi-step tool workflow. Your job is to enforce human approval checkpoints between tool calls. You do not execute tools yourself. You receive the result of a completed tool call and the proposed next tool call, and you must produce a gate decision.

## GATE RULES
- If [RISK_LEVEL] is "low" and the proposed next tool is read-only, you may output PROCEED without confirmation.
- If [RISK_LEVEL] is "medium" or higher, or the proposed next tool performs a write/mutation/side-effect, you MUST output CONFIRMATION_REQUIRED.
- If the previous tool call failed, timed out, or returned an error, output ABORT with the failure reason.
- If the proposed next tool is outside the allowed tool list in [ALLOWED_TOOLS], output ABORT with a policy violation reason.

## INPUT
Previous Tool: [PREVIOUS_TOOL_NAME]
Previous Tool Result: [PREVIOUS_TOOL_RESULT]
Proposed Next Tool: [NEXT_TOOL_NAME]
Proposed Next Tool Arguments: [NEXT_TOOL_ARGUMENTS]
Risk Level: [RISK_LEVEL]
Allowed Tools: [ALLOWED_TOOLS]
Timeout Seconds: [TIMEOUT_SECONDS]
Default Policy on Timeout: [DEFAULT_POLICY]

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
{
  "decision": "PROCEED" | "CONFIRMATION_REQUIRED" | "ABORT",
  "reason": "string explaining the decision",
  "confirmation_prompt": "string to show the human reviewer, only if decision is CONFIRMATION_REQUIRED. Summarize what happened and what will happen next in plain language.",
  "timeout_action": "PROCEED" | "ABORT",
  "timeout_seconds": [TIMEOUT_SECONDS]
}

## CONSTRAINTS
- Never invent tool results or assume success if the previous result indicates failure.
- If [PREVIOUS_TOOL_RESULT] is empty or malformed, treat it as a failure.
- The confirmation_prompt must include: (1) what the previous tool did, (2) what the next tool will do, (3) the specific arguments that will be passed, (4) the consequence of proceeding.
- Do not include technical implementation details in the confirmation_prompt; write for a non-technical reviewer.

To adapt this template, replace each square-bracket placeholder with values from your orchestration layer. [PREVIOUS_TOOL_RESULT] should be the raw output of the completed tool call, not a summary. [RISK_LEVEL] should be set by your application based on the tool's side-effect classification and the sensitivity of the data involved. [DEFAULT_POLICY] determines what happens if the human reviewer does not respond within [TIMEOUT_SECONDS]—set this to "ABORT" for high-risk workflows and "PROCEED" only when the cost of delay exceeds the cost of an incorrect action. Before deploying, test this prompt with at least three scenarios: a low-risk read-after-read sequence that should auto-proceed, a write operation that should trigger confirmation, and a previous-tool-failure that should abort.

The sequential confirmation gate prompt is not a standalone component; it is a decision point inserted between tool calls in a multi-step agent execution loop. The application must call this prompt after a tool completes but before the next tool is invoked, passing the completed tool's output, the planned next tool, and the user's original intent. The prompt returns a structured gate decision: proceed, pause_for_confirmation, or abort. The application must respect this decision—proceeding without confirmation when the gate says pause defeats the purpose of the safety checkpoint.

To implement, wrap the prompt in a gate function that the agent executor calls after each tool call in a sequential chain. The function should accept: the original user request, the completed tool's name and output, the next planned tool's name and proposed arguments, and a risk level derived from the tool's side-effect classification. The prompt template's [PREVIOUS_TOOL_OUTPUT], [NEXT_TOOL_NAME], [NEXT_TOOL_ARGUMENTS], and [RISK_LEVEL] placeholders map directly to these inputs. The function must parse the model's JSON response and enforce the decision: on proceed, continue execution; on pause_for_confirmation, surface the confirmation_message and information_presented fields to the user and wait for explicit approval; on abort, stop the chain and return the abort_reason to the user. Implement a timeout for the confirmation wait—if the user does not respond within the configured [TIMEOUT_SECONDS], apply the [DEFAULT_POLICY] (either abort or proceed as specified in the prompt's constraints). Log every gate decision, including the model's reasoning, the user's response (or timeout), and the resulting action, for auditability.

For production reliability, add validation on the model's output before acting on it. If the JSON is malformed, missing required fields, or contains an unrecognized decision value, default to pause_for_confirmation and escalate to a human reviewer. Do not default to proceed on parse failure—that creates a silent bypass of the safety gate. Wire the gate function into your agent's existing retry and error-handling infrastructure so that gate failures are surfaced in observability dashboards alongside tool call failures. When integrating with tools that have side effects (writes, mutations, external API calls), set [RISK_LEVEL] to high to trigger more conservative gating behavior. For read-only tools in low-risk contexts, you may configure the prompt to auto-proceed, but always retain the ability to escalate if the model detects ambiguity or conflicting information in the previous tool's output.