Async Tool Call Cancellation and Cleanup Prompt Template

This prompt is for agent developers who need to implement graceful cancellation of in-flight asynchronous tool calls. It is designed for systems where a user or upstream process requests cancellation of a long-running operation, and the agent must propagate that signal, handle any partial results, verify resource cleanup, and notify the user of what was completed and what was abandoned. Use this prompt when your agent orchestrates tools that support cancellation tokens, abort signals, or equivalent mechanisms. The prompt assumes the agent has access to tool-specific cancellation functions and a log of in-flight call metadata including correlation IDs, start times, and resource handles.

Do not use this prompt for synchronous tool calls that complete within a single request-response cycle; cancellation there is a transport-layer concern, not an agent reasoning task. This prompt is also inappropriate for fire-and-forget async calls where the agent has no ability to propagate a cancellation signal or verify cleanup. Before using this template, confirm that your tool contracts expose cancellation endpoints, that your agent runtime can track in-flight calls with correlation IDs, and that you have defined what 'partial completion' means for each tool in your ecosystem. Without these prerequisites, the agent will hallucinate cancellation confirmations without actually stopping work.

The ideal user is an agent infrastructure developer or platform engineer building a multi-step agent that invokes tools with variable latency—database migrations, report generation, external API workflows, or model inference jobs. The prompt expects structured input: a list of in-flight tool calls with their correlation IDs, tool names, start times, resource handles, and current status. It produces a structured cancellation plan, per-tool cleanup verification steps, a partial-results summary, and a user-facing status message. Wire this prompt behind a cancellation command handler in your agent loop, not as a standalone chat interaction.

Avoid using this prompt when the cancellation request itself is ambiguous—for example, when a user says 'stop' but might mean 'pause' or 'go back a step.' In those cases, use a clarification prompt before invoking cancellation logic. Also avoid this prompt when the agent lacks authority to release resources; if cleanup requires human approval, the prompt should escalate rather than attempt autonomous resource deallocation. The next section provides the copy-ready template with placeholders you'll adapt to your specific tool contracts and cancellation primitives.

This prompt template gives your agent explicit instructions for handling cancellation requests while async tool calls are still in progress. It covers three critical phases: propagating the cancellation signal to the external tool or service, assessing whether partial results are salvageable, and verifying that no orphaned resources remain. Paste this into your agent's system prompt or cancellation-handler instruction block, then replace the square-bracket placeholders with your actual tool names, resource types, and output schema.

textCopy
You are an agent that executes tool calls asynchronously. When a user or upstream system requests cancellation of an in-flight operation, follow these rules precisely.

## Cancellation Signal Propagation
1. Immediately send a cancellation request to every in-flight tool call using the appropriate cancellation mechanism for each tool.
2. For tools that accept cancellation tokens: pass [CANCELLATION_TOKEN] in the cancellation request.
3. For tools that require an explicit undo or rollback call: invoke the [ROLLBACK_TOOL] with the original [REQUEST_ID] and [TOOL_CALL_ID].
4. For tools with no native cancellation: log the [TOOL_NAME] and [TOOL_CALL_ID] as UNRECOVERABLE and include them in the user-facing summary.

## In-Progress Result Handling
5. If a tool returns partial results before acknowledging cancellation, evaluate whether those results are safe to present:
   - If the partial result is a complete, valid subset of the expected output, include it in the final response with a PARTIAL_RESULT marker.
   - If the partial result is incomplete or potentially misleading, discard it and mark the tool output as CANCELLED_INCOMPLETE.
   - If the partial result represents a side effect that cannot be reversed, flag it as ORPHANED_SIDE_EFFECT and include the [TOOL_NAME], [TOOL_CALL_ID], and a description of the unreversed action.

## Resource Cleanup Verification
6. After all cancellation signals are sent, verify cleanup by checking the following resource types:
   - [RESOURCE_TYPE_1]: check using [VERIFICATION_TOOL_1] with [VERIFICATION_PARAMETERS].
   - [RESOURCE_TYPE_2]: check using [VERIFICATION_TOOL_2] with [VERIFICATION_PARAMETERS].
7. If any resource remains allocated after cancellation, retry cleanup once using [CLEANUP_TOOL]. If the retry fails, log the resource as ORPHANED and include it in the user-facing summary.

## User Notification
8. Produce a final cancellation summary in the following [OUTPUT_SCHEMA]:
   {
     "status": "CANCELLED" | "PARTIALLY_CANCELLED" | "CANCELLATION_FAILED",
     "cancelled_tool_calls": [
       {
         "tool_call_id": "string",
         "tool_name": "string",
         "cancellation_status": "CANCELLED" | "CANCELLED_INCOMPLETE" | "UNRECOVERABLE",
         "partial_result": { } | null,
         "orphaned_resources": ["string"] | []
       }
     ],
     "orphaned_side_effects": [
       {
         "tool_name": "string",
         "tool_call_id": "string",
         "description": "string"
       }
     ],
     "user_message": "string"
   }
9. The user_message field must clearly state what was cancelled, what partial work was saved, and what could not be reversed. Do not claim successful cleanup if any resource or side effect remains orphaned.

## Constraints
- Never ignore a cancellation request to let a tool call complete.
- Do not fabricate cleanup confirmation. Only report resources as cleaned if verification confirms it.
- If [RISK_LEVEL] is HIGH, escalate orphaned resources to [ESCALATION_CHANNEL] immediately after producing the summary.

To adapt this template, replace the bracketed placeholders with your actual tool names, resource types, verification procedures, and escalation channels. If your system doesn't support native cancellation tokens, remove that branch and expand the rollback or logging path. For low-risk workflows, you can simplify the output schema by removing the orphaned_side_effects array, but always preserve the distinction between confirmed cleanup and unverified claims. Test the adapted prompt against the eval checks described in the full playbook: orphaned resource detection, incomplete side-effect reversal, and misleading user messages that claim cleanup when resources remain allocated.

This prompt is designed to sit inside a cancellation handler—a code path triggered when a user interrupts a long-running operation, a timeout fires, or a parent workflow aborts. The handler should inject the prompt into a fresh model call, passing the list of in-flight tool calls, their current states, and any partial results already received. The model's job is to produce a structured cancellation plan, not to execute the cancellation itself. Your application code reads that plan and performs the actual tool-call abort, resource cleanup, and user notification.

The implementation loop follows a strict plan-then-execute pattern. First, gather all active tool_call_id values, their tool names, start times, and any partial payloads. Populate the [ACTIVE_TOOL_CALLS] placeholder with a JSON array of objects containing id, tool, status (one of in_flight, partial_result_received, awaiting_callback), started_at, and partial_result. Set [CANCELLATION_REASON] to the trigger cause (user_interrupt, timeout, parent_abort, circuit_breaker). Call the model with the prompt template and parse the output against a strict schema: an array of actions, each with tool_call_id, action (abort, await_partial, rollback, notify, noop), cleanup_steps (array of strings describing resource release actions), and user_message (a short, honest summary for the end user). Validate that every active tool call appears in the output exactly once. If validation fails, retry once with the validation error appended to [CONSTRAINTS]. After two failures, fall back to a hard-coded abort-all strategy and log the incident.

After parsing the model's cancellation plan, execute actions sequentially in dependency order: abort in-flight calls first, then process any partial results marked for salvage, then run cleanup steps, and finally surface user messages. Log every step with the tool_call_id, action taken, timestamp, and success/failure status. This trace is critical for debugging orphaned resources. Implement a cleanup verification gate: after executing all cleanup steps, wait 2–5 seconds and re-query the tool systems to confirm resources (locks, sessions, file handles, database transactions) were actually released. If verification fails, escalate to an on-call channel rather than silently proceeding. For high-risk tools (database writes, payment operations, external API mutations), require a human approval step before executing rollback actions—the model's plan is advisory, not authoritative. Never allow the model to directly invoke cancellation or rollback APIs; all execution must happen in your application code with audit trails intact.