This prompt is for platform engineers and AI architects building compound AI systems where work must move between specialized sub-agents. Use it when an orchestrator needs to generate a structured, machine-readable summary of a sub-agent's completed work, pending items, active constraints, and relevant context before transferring control to another agent. The output is designed to be consumed by a downstream agent's system prompt or context window, not by an end user. This prompt assumes you already have a defined handoff trigger and a known receiving agent with a declared capability manifest.
Prompt
Handoff Summary Generation Prompt Template

When to Use This Prompt
Defines the precise conditions, required infrastructure, and architectural prerequisites for deploying the Handoff Summary Generation Prompt in a compound AI system.
The ideal deployment scenario involves an orchestrator agent that has just received a termination signal from a sub-agent. Before invoking the next agent in the chain, the orchestrator calls this prompt with the raw sub-agent output, the original task assignment, and the receiving agent's capability manifest. The prompt's primary job is to prevent context contamination—it must filter out internal reasoning traces, tool call artifacts, and role-specific instructions that are irrelevant or dangerous for the receiving agent. For example, if a 'Code Analysis Agent' hands off to a 'Documentation Agent,' the summary must retain the API surface and logic flow but strip out linting configurations and test harness details that the Documentation Agent has no permission or need to see.
Do not use this prompt for user-facing summaries, for single-agent workflows, or when the receiving agent's role and permissions are unknown. It is also inappropriate when the handoff requires full conversational history preservation without pruning, as this prompt's core function is to reduce and restructure context. Before implementing, ensure you have a validated Role Transition Validation Prompt in place to authorize the handoff, and a Context Contamination Detection Prompt ready to scan the output before it enters the downstream agent's context. The biggest production risk is a summary that accidentally leaks a prior agent's system instructions or tool outputs into a less-privileged agent, creating a privilege escalation path.
Use Case Fit
Where the Handoff Summary Generation prompt works well and where it introduces risk. Use these cards to decide if this prompt fits your workflow before wiring it into a multi-agent pipeline.
Good Fit: Structured Agent-to-Agent Handoffs
Use when: you have a defined orchestrator dispatching work to specialized sub-agents and need a consistent, machine-readable payload for context transfer. Guardrail: validate the output against the handoff schema before the receiving agent processes it.
Bad Fit: Unstructured Human Note-Taking
Avoid when: the goal is a freeform summary for a human to read later. This prompt produces a structured payload designed for machine consumption. Guardrail: use a meeting-notes or briefing prompt instead if the consumer is a person reading prose.
Required Input: Complete Task State
Risk: the prompt cannot summarize work it cannot see. Missing tool outputs, partial conversation history, or truncated context produces an incomplete handoff. Guardrail: enforce a pre-handoff context completeness check that verifies all required state fields are present before invoking the summary prompt.
Required Input: Role Boundary Definitions
Risk: the summary may include information the receiving agent is not authorized to access, violating role boundaries. Guardrail: pass explicit role permission manifests alongside the prompt and validate the output for boundary violations before transfer.
Operational Risk: Context Contamination
Risk: tool outputs, user messages, or prior agent reasoning can leak into the handoff payload, giving the receiving agent poisoned context. Guardrail: run a contamination detection check on the generated summary before it enters the downstream agent's context window.
Operational Risk: Stale or Bloated Context
Risk: long-running sessions accumulate irrelevant history that wastes tokens and dilutes the receiving agent's attention. Guardrail: apply context pruning rules with salience scoring before generating the handoff summary, and enforce a maximum payload size.
Copy-Ready Prompt Template
A structured prompt for generating a handoff summary payload that transfers task state, context, and constraints between specialized sub-agents.
This prompt template produces a structured handoff summary when work moves from one specialized sub-agent to another. It captures completed work, pending items, active constraints, and relevant context so the receiving agent can continue without replaying the entire session history or violating role-specific boundaries. Replace every square-bracket placeholder with live data from your orchestrator before sending the prompt to the model.
textSYSTEM: You are a Handoff Summary Generator. Your only job is to produce a structured handoff payload that transfers task state from one specialized agent to another. You do not execute the task yourself. You do not add interpretation, commentary, or recommendations beyond what the evidence supports. Follow these rules strictly: 1. Include only information that is relevant to the receiving agent's declared role and task scope. 2. Preserve all active constraints, safety policies, and refusal boundaries from the originating agent's context. 3. Mark every item with a confidence level: [CONFIRMED], [PENDING_VERIFICATION], or [UNRESOLVED]. 4. Do not fabricate completion status. If a task is incomplete, mark it as pending with the last known state. 5. Prune context that is stale, role-irrelevant, or exceeds the token budget specified in [CONTEXT_BUDGET]. 6. If the originating agent's output contains contradictory or ambiguous information, flag it in an [UNRESOLVED_ITEMS] section rather than choosing a side. USER: Generate a handoff summary using the following inputs: [ORIGINATING_AGENT_ROLE]: [ROLE_NAME] [RECEIVING_AGENT_ROLE]: [ROLE_NAME] [TASK_DESCRIPTION]: [TASK_DESCRIPTION] [COMPLETED_WORK]: [COMPLETED_WORK] [PENDING_WORK]: [PENDING_WORK] [ACTIVE_CONSTRAINTS]: [ACTIVE_CONSTRAINTS] [TOOL_OUTPUTS]: [TOOL_OUTPUTS] [SESSION_CONTEXT]: [SESSION_CONTEXT] [CONTEXT_BUDGET]: [CONTEXT_BUDGET] [OUTPUT_SCHEMA]: [OUTPUT_SCHEMA] [RISK_LEVEL]: [RISK_LEVEL] Produce the handoff summary in the exact schema specified in [OUTPUT_SCHEMA]. If [RISK_LEVEL] is HIGH or CRITICAL, add a [HUMAN_REVIEW_REQUIRED] flag and list the specific items that require approval before the receiving agent acts.
Adaptation guidance: The [OUTPUT_SCHEMA] placeholder should reference a concrete JSON schema or structured format your downstream agent expects. If your system uses typed function calls, replace the free-text output instruction with a tool definition. For regulated or high-risk domains, keep the [HUMAN_REVIEW_REQUIRED] path active and wire it to an approval queue before the receiving agent executes any action. Test this prompt with edge cases where the originating agent's output is incomplete, contradictory, or exceeds the context budget—these are the most common failure modes in production handoffs.
Prompt Variables
Each placeholder must be populated before the prompt is assembled. Validation checks prevent silent failures in production handoff pipelines.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[CURRENT_AGENT_ROLE] | Identifies the agent generating the handoff summary | customer_support_triage | Must match a role ID in the active agent registry. Reject if role is not recognized by the orchestrator. |
[TASK_STATE] | Serialized snapshot of completed work, pending items, and active decisions | {"completed": ["verified_account"], "pending": ["refund_approval"]} | Must parse as valid JSON. Schema check: required fields include completed, pending, and blocked. Reject if state exceeds context budget threshold. |
[CONSTRAINTS] | Active policy, compliance, and role-boundary rules that must survive the handoff | Do not disclose account balance. Escalate fraud flags to compliance_agent. | Must not be empty. Each constraint must be a complete sentence. Validate that no constraint contradicts the receiving agent's declared capability manifest. |
[RECEIVING_AGENT_ROLE] | Target role that will consume this handoff summary | refund_processing_agent | Must exist in the capability registry. Reject if the receiving role lacks permission to access fields present in TASK_STATE or CONTEXT. |
[CONTEXT] | Relevant conversation history, tool outputs, and evidence needed by the receiving agent | User reported duplicate charge on 2025-01-15. Transaction ID: TX-8823. | Token count must be below the configured context pruning threshold. Scan for PII or role-inappropriate data before inclusion. Reject if contamination detected. |
[HANDOFF_REASON] | Classification of why the handoff is occurring | capability_boundary: refund processing requires refund_processing_agent | Must match an allowed reason code from the handoff policy registry. Reject unrecognized codes. Audit log must capture this value. |
[OUTPUT_SCHEMA_VERSION] | Schema version the handoff payload conforms to | 2.1.0 | Must match a deployed schema version. Reject if version is deprecated or unknown. Downstream parsers depend on this field for compatibility. |
[ESCALATION_PATH] | Fallback target if the receiving agent cannot process the handoff | human_approval_queue | Must be a valid escalation target in the orchestrator config. Reject if the escalation path is the same as the receiving agent, creating a loop. |
Implementation Harness Notes
How to wire the Handoff Summary Generation prompt into a production application or multi-agent workflow.
This prompt is designed to be called programmatically at the moment a handoff is triggered between two specialized sub-agents. It should not be exposed directly to end-users. The application layer is responsible for gathering the required inputs—the completed work log, the pending task queue, the active constraints, and the receiving agent's capability manifest—and injecting them into the prompt's placeholders. Treat this prompt as a deterministic data transformation step: structured state in, structured handoff payload out. The model's job is to format, prune, and contextualize, not to invent new tasks or alter the priority of existing constraints.
To wire this into an application, wrap the prompt call in a function that enforces a strict output contract. Before making the API request, validate that all required inputs are present and non-empty. After receiving the response, parse the JSON output and run it through a schema validator that checks for required fields (task_state, completed_work, pending_items, active_constraints, relevant_context, role_boundary_notes). If validation fails, implement a single retry with the validation error message appended to the prompt as additional context. Log every handoff—including the raw input state, the generated summary, and the validation result—to a structured logging system for debugging and audit purposes. For high-stakes domains, insert a human review step before the summary is forwarded to the receiving agent, especially when the handoff involves a role with elevated permissions or a change in safety-critical constraints.
Model choice matters here. Use a model with strong instruction-following and JSON output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may drop fields, hallucinate task details, or fail to respect the context pruning rules. If you are using a model that supports structured output modes (e.g., OpenAI's response_format with a JSON schema or Claude's tool use with a defined input schema), bind the output directly to the handoff schema rather than relying on a free-text prompt alone. This reduces parsing errors and eliminates the need for regex-based extraction. For teams running local or air-gapped deployments, test the prompt extensively with your chosen open-weight model and be prepared to add few-shot examples of correctly formatted handoff summaries to the prompt template if the model struggles with schema adherence.
Expected Output Contract
Defines the structured payload a handoff summary prompt must produce. Use this contract to validate the output before passing it to a downstream sub-agent.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
handoff_id | string (UUID v4) | Must match regex for UUID v4. Reject if missing or malformed. | |
source_role | string | Must exactly match an active role ID from the capability registry. Reject unknown roles. | |
target_role | string | Must exactly match an active role ID. Reject if target_role equals source_role without explicit self-handoff justification. | |
task_state | enum [completed, blocked, in_progress, not_started] | Must be one of the four allowed values. Reject any other string. | |
completed_work | array of strings | Must be a non-empty array if task_state is completed or in_progress. Each string must be under 500 characters. | |
pending_items | array of objects | Each object must contain 'description' (string, required) and 'priority' (enum: high, medium, low, required). Reject if array is empty when task_state is blocked. | |
active_constraints | array of strings | Each string must reference a constraint ID from the active session policy. Reject if a constraint is not found in the policy registry. | |
relevant_context | string or null | If provided, must be under 2000 characters. Allow null when no additional context is needed beyond completed_work and pending_items. |
Common Failure Modes
Handoff summaries fail in predictable ways. These are the most common production failure modes and the guardrails that catch them before they corrupt downstream agent behavior.
Context Contamination Across Role Boundaries
What to watch: The handoff summary leaks tool outputs, user PII, or role-specific instructions that the receiving agent should never see. This happens when pruning rules are too permissive or when raw conversation history is passed without sanitization. Guardrail: Run a context contamination detection prompt on the serialized payload before handoff. Validate that no data from the source agent's restricted scope appears in the transfer object. Reject handoffs that fail the contamination check.
Missing Pending Items and Unresolved Decisions
What to watch: The summary declares work complete but omits pending approvals, unanswered clarification questions, or partially finished tasks. The receiving agent starts from a false assumption of completion and either duplicates work or skips critical steps. Guardrail: Require a structured pending-items field in the handoff schema. Validate that every open loop from the source agent's session state has a corresponding entry before the handoff executes. Reject summaries with empty pending sections when the session log shows unresolved items.
Constraint Stripping During Summarization
What to watch: Safety policies, refusal boundaries, or compliance constraints present in the source agent's instructions are omitted from the handoff summary. The receiving agent operates without inherited guardrails and may perform actions the source agent was prohibited from doing. Guardrail: Use a policy inheritance prompt that explicitly copies parent-level constraints into the handoff payload. Validate that all non-overridden safety rules appear in the transferred context. Flag missing constraints as a blocking handoff failure.
Role Capability Mismatch After Transfer
What to watch: The handoff assigns a task to a receiving agent that lacks the required tools, domain knowledge, or permission scope. The receiving agent either fails silently, hallucinates capabilities, or attempts out-of-scope actions that trigger downstream errors. Guardrail: Validate the assigned task against the receiving agent's capability manifest before handoff. Reject assignments that exceed declared capabilities and route to a fallback agent or escalate to a human operator.
State Bloat and Token Budget Overrun
What to watch: Handoff summaries grow unbounded across multiple agent transitions, carrying stale context, redundant conversation history, and irrelevant tool outputs. Token budgets are consumed by noise, and the receiving agent's reasoning degrades under context overload. Guardrail: Apply context pruning with explicit salience scoring before serialization. Retain only information relevant to the receiving agent's task. Set a hard token budget for handoff payloads and truncate with priority ordering when exceeded.
Silent Handoff Failures Without Recovery Paths
What to watch: A handoff fails due to schema mismatch, timeout, or agent unavailability, but the orchestrator has no recovery logic. The session hangs, the user receives no feedback, and no fallback agent is activated. Guardrail: Implement a handoff failure recovery prompt with explicit retry logic, fallback agent selection, and user notification templates. Set timeout thresholds and abort conditions. Log every handoff attempt with success/failure status for observability.
Evaluation Rubric
Criteria for testing the quality of a generated handoff summary before integrating it into a multi-agent pipeline. Use these checks in automated eval harnesses or manual spot reviews.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Task State Completeness | Summary includes current task status, completed items, and pending items as distinct sections. | Missing one or more of: task status, completed work list, or pending items list. | Schema check for required fields; LLM-as-judge assertion that all three categories are present and non-empty. |
Constraint Preservation | All active constraints from the originating role are explicitly listed and unmodified in the summary. | A constraint present in the source context is absent or semantically altered in the handoff payload. | Diff check between source constraint list and summary constraint list; semantic similarity score above 0.95 required. |
Context Pruning Accuracy | Irrelevant context is removed; role-specific context needed by the receiving agent is retained. | Summary contains stale data from 5+ turns ago with no relevance to the pending task, or omits a critical tool output needed for continuation. | Salience scoring: human-annotated key facts must appear; annotator-flagged irrelevant facts must not appear. |
Role Boundary Adherence | Summary contains no instructions, tool calls, or data access patterns that exceed the receiving agent's declared capability manifest. | Summary includes a directive to call a tool the receiving agent does not have, or references data outside its permission scope. | Validate summary actions against the receiving agent's capability declaration schema; any mismatch is a hard failure. |
Output Schema Compliance | Handoff payload strictly conforms to the defined JSON schema with all required fields populated. | Missing required field, wrong type, or extra field not in schema. | JSON Schema validator run in CI; any validation error fails the test. |
Source Grounding | Every factual claim in the summary can be traced to a specific turn, tool output, or explicit context entry. | Summary contains a claim not present in the session transcript or tool outputs. | Citation extraction: each claim must have a source pointer; ungrounded claims trigger a failure. |
Conciseness Under Budget | Summary fits within the target token budget without dropping required fields or constraints. | Summary exceeds token budget by more than 10% or achieves budget by truncating a required field mid-sentence. | Token count check; schema completeness check post-truncation. |
Idempotency Readiness | Summary includes a state checkpoint marker and pending decision log so the receiving agent can safely retry without duplicating work. | No checkpoint marker present, or pending decisions are described ambiguously. | Keyword check for checkpoint marker; LLM judge verifies pending decisions are specific and actionable. |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Use the base prompt template with lighter validation. Replace [OUTPUT_SCHEMA] with a simple JSON structure and skip strict enum checks. Focus on getting the handoff shape right before adding production constraints.
Watch for
- Missing required fields in the handoff payload
- Overly broad [CONTEXT] that bloats the summary
- No checks for role boundary violations in transferred state

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us