Session Handoff Prompt Between Agents

This prompt is designed for multi-agent systems where a conversation must be transferred from one specialized assistant to another. The core job-to-be-done is generating a structured, lossless handoff summary that allows the receiving agent to continue the workflow without repeating steps, asking already-answered questions, or losing critical user preferences. The ideal user is an AI/ML engineer or platform developer building an agent orchestration layer, where a router or supervisor agent delegates tasks to sub-agents with distinct capabilities or domain knowledge.

Use this prompt when the handoff is between agents with different system instructions, tool access, or knowledge bases. The required context includes the full conversation transcript, the sending agent's role and completed actions, and any unresolved tasks or user constraints. Do not use this prompt for simple, single-agent context summarization or for logging purposes. It is specifically for active state transfer where the receiving agent will immediately act on the information. The prompt is overkill if the receiving agent is stateless or if the conversation is simply ending.

Before implementing, ensure you have a clear contract for the handoff schema. The output must be machine-readable to be injected into the receiving agent's context. The primary failure mode is information loss, where a pending action or user preference is omitted from the summary, causing the receiving agent to make a contradictory or redundant request. A secondary risk is carrying over stale context that the user has since corrected. Always pair this prompt with a validation step that checks the handoff summary against the last few turns of the conversation to confirm that active intent and recent corrections are accurately captured.

This template is the core instruction set for a handoff agent. Its job is to read the raw conversation history and produce a structured, lossless summary that the receiving agent can use to continue the work without repeating steps, asking answered questions, or violating established user preferences. The template uses square-bracket placeholders so you can wire it into your existing multi-agent orchestration code. Every placeholder represents a variable your application must supply at runtime.

codeCopy
SYSTEM:
You are a Session Handoff Agent. Your only job is to produce a structured handoff summary from the provided conversation history. Do not continue the conversation. Do not greet the user. Do not take any action on behalf of the user.

INPUT:
[CONVERSATION_HISTORY]

INSTRUCTIONS:
1. Analyze the entire conversation history to extract the following structured information.
2. If a field has no applicable information, use `null` or an empty array `[]` as specified.
3. Do not infer, assume, or hallucinate information not present in the history.
4. Preserve the user's exact terminology for preferences and constraints.

OUTPUT_SCHEMA:
{
  "handoff_summary": {
    "primary_intent": "string (the user's main goal, stated as a concise imperative)",
    "completed_steps": [
      {
        "step": "string (what was done)",
        "result": "string (outcome or confirmation)",
        "timestamp": "string (ISO 8601 if available, else relative turn reference)"
      }
    ],
    "pending_actions": [
      {
        "action": "string (what needs to be done next)",
        "owner": "string (user | agent | system)",
        "blockers": ["string (what is preventing this action)"],
        "priority": "string (high | medium | low)"
      }
    ],
    "unresolved_questions": [
      {
        "question": "string (the open question)",
        "asked_by": "string (user | agent)",
        "context": "string (why this question matters)"
      }
    ],
    "user_preferences": {
      "explicit": ["string (stated preference)"],
      "observed": ["string (behavioral pattern, noted as observation)"]
    },
    "active_constraints": ["string (rules, deadlines, or limits in effect)"],
    "key_entities": [
      {
        "name": "string",
        "type": "string (person | product | company | policy | other)",
        "role": "string (how this entity relates to the conversation)"
      }
    ],
    "conversation_tone": "string (e.g., urgent, exploratory, frustrated, neutral)",
    "risk_flags": ["string (escalation signals, compliance concerns, user dissatisfaction indicators)"],
    "handoff_context": "string (a 2-3 sentence narrative summary for the receiving agent to read first)"
  }
}

CONSTRAINTS:
[CONSTRAINTS]

EXAMPLES:
[EXAMPLES]

To adapt this template, start by defining your [CONSTRAINTS]. This is where you enforce domain-specific rules, such as PII redaction requirements, maximum summary length, or mandatory fields for regulated workflows. Next, supply 2-3 [EXAMPLES] that demonstrate the desired output for typical handoff scenarios in your product. These few-shot examples are critical for teaching the model the expected level of detail and the boundary between factual extraction and inference. Finally, replace [CONVERSATION_HISTORY] with your application's serialized dialogue, ensuring that speaker roles and turn boundaries are clearly delimited. The output schema is designed to be parsed directly by your orchestrator, so validate the JSON structure before forwarding it to the next agent. For high-risk domains, add a human review step that checks the risk_flags array and the handoff_context narrative before the receiving agent acts.

Integrating the session handoff prompt into a production multi-agent system requires treating the handoff summary as a critical data contract, not just a text blob. The prompt should be called by the current agent when a handoff trigger is detected—typically a classifier router, an explicit user request, or a task-completion signal. The output must be a structured JSON object that the target agent can parse programmatically. Before passing the summary to the next agent, validate it against a strict schema: check that required fields like active_intent, completed_steps, pending_actions, and unresolved_context are present and non-empty where expected. If validation fails, re-prompt the model with the specific schema errors rather than silently passing incomplete state to the downstream agent.

Implement a retry loop with a maximum of two attempts for schema validation failures. On the first failure, append the validation error message to the prompt and re-request the structured output. If the second attempt also fails, log the raw output and the errors, then fall back to a degraded handoff: pass whatever valid fields exist and flag the handoff as partial_handoff: true with a validation_errors field. The receiving agent should check for this flag and, when present, ask the user a brief clarifying question before proceeding with any irreversible actions. For model choice, prefer a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) since schema adherence is the primary failure mode. Avoid smaller or older models that tend to drop fields or hallucinate values under complex output constraints.

Log every handoff event—successful, partial, or failed—to your observability platform. The log should include the session_id, source_agent_id, target_agent_id, the validated handoff payload, the handoff_timestamp, and the validation_status. This audit trail is essential for debugging multi-agent workflows where context loss or contradictory state can cascade across agents. Additionally, implement a handoff relevance check in the receiving agent: before acting on the summary, have the target agent evaluate whether the handoff context is still relevant or has been superseded by a new user message that arrived during the handoff window. This prevents stale-state execution, which is a common failure mode in asynchronous agent architectures. Finally, for high-stakes domains like healthcare or finance, require a human-in-the-loop review step before the receiving agent executes any action that modifies external systems based solely on handoff context.