Context Transfer Prompt for Escalation Handoff

This prompt is designed for architects of compound AI systems where a conversation or task must be handed off from one specialized role or agent to another. Its primary job is to compress the entire interaction state into a dense, structured context package that the receiving role can consume without needing to replay the full history. The ideal user is an AI engineer or product developer building a multi-agent system, a customer support automation pipeline, or any workflow where an initial handler must escalate to a human or a more capable AI. The core problem it solves is context loss during handoff, which is a leading cause of user frustration, repeated questions, and broken workflows in production AI systems.

You should use this prompt when the handoff target has a different system prompt, tool set, or capability boundary than the originating role. It is essential when the receiving role cannot access the original conversation memory due to architectural separation, such as crossing between different model providers, moving from an AI agent to a human review queue, or transitioning from an async job to a real-time agent. The prompt requires several inputs to function: the full conversation history, the reason for escalation, the user's explicit and implicit needs, and any active constraints or policies that must survive the transfer. It is not a general summarization prompt; its output is a machine-readable context payload, not a human-readable summary.

Do not use this prompt for simple logging or for handoffs within a single monolithic agent that already has access to the full conversation state. It is also inappropriate when the escalation target is a human who needs a narrative summary rather than a structured data package; for that, use a dedicated Human Handoff Summary Prompt. This prompt is a high-risk component in your system architecture because information loss here directly causes downstream failures. Always pair it with evaluation checks for context completeness and irrelevant information inclusion. Before deploying, validate that the compressed context package allows the receiving role to resolve the user's issue without asking for any information already provided in the originating conversation.

This prompt template is designed to be inserted into a system or developer message when an escalation trigger fires. Its job is to take the full conversation history, active constraints, and unresolved items and produce a compact, machine-readable handoff object that the next role or system can consume without replaying the entire session. The template uses square-bracket placeholders for all variable inputs so you can wire it directly into your prompt assembly pipeline.

textCopy
SYSTEM: You are a Context Transfer Compiler. Your only job is to read the provided conversation history and produce a structured escalation handoff package. Do not continue the conversation. Do not answer the user. Do not add commentary.

[CONVERSATION_HISTORY]

[ACTIVE_CONSTRAINTS]

[OUTPUT_SCHEMA]
{
  "escalation_reason": "string (primary reason code: CAPABILITY_GAP | CONFIDENCE_LOW | TOOL_FAILURE | PERMISSION_DENIED | LOOP_DETECTED | USER_REQUESTED | RETRY_EXHAUSTED | FRUSTRATION_DETECTED)",
  "severity": "string (CRITICAL | HIGH | MEDIUM | LOW)",
  "summary": {
    "user_goal": "string (what the user was trying to accomplish)",
    "actions_taken": ["string (ordered list of actions already attempted)"],
    "unresolved_items": ["string (questions or tasks still open)"],
    "user_sentiment": "string (FRUSTRATED | CONFUSED | NEUTRAL | SATISFIED | URGENT)",
    "key_entities": ["string (people, products, dates, amounts, or identifiers mentioned)"]
  },
  "active_policy_constraints": ["string (constraints that must survive the handoff)"],
  "recommended_next_role": "string (suggested target role or queue)",
  "context_compression_notes": "string (what was intentionally omitted and why)"
}

[CONSTRAINTS]
- Output only valid JSON matching the schema above.
- Do not invent information not present in the conversation.
- If the user's goal is unclear, set user_goal to "UNCLEAR" and note ambiguity in unresolved_items.
- If sentiment cannot be determined, use "NEUTRAL".
- Omit personally identifiable information unless it is essential to resolving the escalation.
- Keep the summary concise. Prefer specific facts over narrative.

To adapt this template, replace each bracketed placeholder with your application's actual values. [CONVERSATION_HISTORY] should contain the full turn-by-turn transcript, including tool calls and their outputs. [ACTIVE_CONSTRAINTS] should list any policy, compliance, or role-boundary rules that were active during the session. The [OUTPUT_SCHEMA] and [CONSTRAINTS] blocks are part of the prompt itself and should be kept as-is unless your escalation target requires different fields. After generating the handoff, validate the JSON against your schema before forwarding it to the next system. For high-risk domains, log the raw output and the validated handoff separately so you can audit compression fidelity later.

The Context Transfer Prompt for Escalation Handoff is not a standalone chat prompt—it is a middleware component that sits between two roles or systems. When the primary role determines it cannot resolve a request and triggers an escalation, the application layer must call this prompt with the full conversation history, unresolved items, active constraints, and any tool outputs. The prompt compresses that state into a structured handoff package that the next role or human reviewer can consume without replaying the entire session. This means the harness must capture and pass [CONVERSATION_HISTORY], [UNRESOLVED_ITEMS], [ACTIVE_CONSTRAINTS], [USER_SENTIMENT_SIGNALS], and [TOOL_OUTPUTS] as explicit inputs—not rely on the model to infer them from a raw transcript.

Wire this prompt as a synchronous step in your escalation pipeline. After the primary role emits an escalation signal, construct the input payload by extracting the last N turns of conversation (typically 10–20 turns, depending on context window budget), appending any structured fields for unresolved items and constraints, and injecting the output schema as a system-level instruction. Validate the model's output against the expected schema before forwarding it: check that context_summary is non-empty, unresolved_items is a non-empty array, user_sentiment matches your enum values, and active_constraints includes any safety or policy flags. If validation fails, retry once with a repair prompt that includes the validation error message. If the retry also fails, log the failure and fall back to a raw transcript handoff with a warning flag for the downstream role. For high-stakes domains (healthcare, finance, legal), always insert a human review step before the handoff package reaches the next system—do not auto-forward compressed context without approval when the cost of context loss is severe.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may drop fields or hallucinate sentiment when the conversation is long. Set temperature low (0.0–0.2) to maximize consistency across handoffs. Log every handoff package with a unique handoff_id, the model version, input token count, output token count, and validation result. This trace data is essential for debugging context loss, detecting compression drift, and proving to auditors that the escalation preserved the necessary information. Do not use this prompt for real-time streaming handoffs—batch the context, generate the package, validate it, then forward.