Handoff Summary Generation Prompt Template

Use this prompt when you need a structured, human-readable summary of an agent's completed work before transferring context to another agent, a human reviewer, or an audit system. The primary job-to-be-done is creating a concise record that answers: what the agent did, what evidence it used, what decisions it made, and why those decisions were made. This is essential for platform engineers and orchestration builders who need handoff records that operators can read during incident review, that compliance teams can archive, and that downstream agents can use as orientation context before continuing work.

This prompt is designed for workflows where traceability and human interpretability matter more than machine-to-machine throughput. Ideal scenarios include: an agent completing a research task and handing findings to an analyst, a coding agent finishing a patch and handing off to a reviewer, or a triage agent escalating a complex case to a human operator with full context. The prompt expects inputs such as the agent's original task, actions taken, tools called, evidence retrieved, decisions made, and any unresolved items. It produces a structured summary with sections for task description, actions, evidence, decisions, rationale, and pending items.

Do not use this prompt when you need a machine-readable state serialization for direct consumption by another agent. For structured payloads with strict schemas, idempotency keys, and programmatic parsing, use the Agent Handoff State Serialization Prompt Template instead. Also avoid this prompt when the handoff target is a simple router or queue system that only needs a task ID and status code—the human-readable format adds unnecessary token overhead. This prompt is not suitable for real-time streaming handoffs where latency constraints prohibit generating a full narrative summary.

Before using this prompt, ensure you have access to the agent's execution trace, tool call logs, and any retrieved evidence. The quality of the handoff summary depends entirely on the completeness of this input context. If the agent's internal state is not observable or its decision points are not logged, the summary will contain gaps that mislead downstream consumers. Wire this prompt into your orchestration layer after agent completion but before context transfer, and validate the output against the eval checks described in the testing section of this playbook.

This template produces a concise, structured summary of an agent's activity before transferring work to another agent or a human reviewer. It captures the agent's decisions, evidence used, rationale, and any unresolved items. Replace the square-bracket placeholders with your agent's actual execution data, tool outputs, and task context. The template is designed to be wired into an orchestration layer that collects trace data and injects it before calling the model.

textCopy
You are generating a handoff summary for a downstream agent or human reviewer. Your summary must be self-contained, evidence-grounded, and actionable.

## INPUT DATA
- Agent Identity: [AGENT_NAME]
- Task Description: [TASK_DESCRIPTION]
- Execution Trace (steps taken, tools called, outputs received):
  [EXECUTION_TRACE]
- Partial Results (completed work products, intermediate findings):
  [PARTIAL_RESULTS]
- Pending Actions (tasks not yet started or incomplete):
  [PENDING_ACTIONS]
- Unresolved Dependencies (blockers, missing information, required inputs):
  [UNRESOLVED_DEPENDENCIES]
- Confidence Assessment (per-finding or overall confidence levels):
  [CONFIDENCE_ASSESSMENT]
- Source References (documents, API responses, database records cited):
  [SOURCE_REFERENCES]

## OUTPUT SCHEMA
Produce a JSON object with the following fields:
- "summary": A 2-4 sentence narrative of what the agent accomplished and why.
- "key_decisions": An array of objects, each with "decision", "rationale", and "evidence_used" fields.
- "completed_work": An array of completed deliverables with "item" and "status" fields.
- "pending_work": An array of remaining tasks with "item", "priority", and "blocker" fields.
- "confidence_flags": An array of findings where confidence is below threshold, each with "finding" and "confidence_level" fields.
- "handoff_recommendations": Specific instructions for the receiving agent or human about what to do next.
- "source_citations": An array of sources referenced, each with "source_id" and "relevance" fields.

## CONSTRAINTS
- Do not invent facts not present in the execution trace.
- If confidence is low on any finding, flag it explicitly in "confidence_flags".
- Preserve the agent's stated rationale verbatim where possible; do not reinterpret.
- If source references are provided, cite them by their source_id in relevant decisions.
- If the execution trace is empty or the task was not attempted, state that clearly in the summary.
- Do not speculate about what the downstream agent should do beyond what the trace supports.

To adapt this template, replace each bracketed placeholder with data from your agent's execution log. The EXECUTION_TRACE should include timestamps, tool calls, and raw outputs. The PARTIAL_RESULTS field should contain any work products already generated. Before deploying, validate that the model's output conforms to the JSON schema and that all cited sources exist in the provided references. For high-stakes handoffs, route the generated summary through a human review step before the downstream agent acts on it.

The Handoff Summary Generation prompt is not a standalone artifact—it is a component inside an agent orchestration harness. In production, this prompt fires when an agent reaches a transfer boundary: task completion, escalation, or a capability gap. The harness is responsible for assembling the prompt's inputs from the agent's execution trace, invoking the model, validating the output, and routing the summary to the downstream agent or human reviewer. Treat this prompt as a deterministic function with a strict output contract; the harness enforces that contract before any downstream system consumes the summary.

Start by defining the input assembly pipeline. The prompt expects [AGENT_IDENTITY], [TASK_ORIGINAL_REQUEST], [ACTIONS_TAKEN], [EVIDENCE_USED], [DECISIONS_MADE], [UNRESOLVED_ITEMS], and [CONFIDENCE_ASSESSMENT]. These fields must be extracted from the agent's runtime state—tool call logs, retrieved documents, internal reasoning traces, and explicit decision records. Build a serialization layer that captures these fields at the handoff trigger point. If any required field is empty, the harness should either abort the handoff and request the agent to produce the missing data, or mark the field explicitly as `

unavailable"with a reason. Never passnull` or empty strings silently; downstream agents rely on these fields to avoid re-doing work or making decisions on incomplete context."

Model choice matters for this prompt. The task requires faithful summarization of agent actions, not creative generation. Use a model with strong instruction-following and low hallucination rates on structured summarization tasks—GPT-4o, Claude 3.5 Sonnet, or equivalent. Set temperature=0 or very low (0.1) to maximize factual consistency. If your orchestration system supports it, enable structured output mode (JSON mode, function calling with a strict schema, or constrained decoding) to enforce the output schema at the token level rather than relying on post-hoc parsing. The output schema should include: summary_text, key_decisions[] (each with decision, rationale, evidence_citation), unresolved_items[], confidence_score (0.0–1.0), and recommended_next_agent.

Validation is the critical gate. After the model returns, run a multi-check validator before the summary enters any downstream queue. Schema check: confirm all required fields exist and types match. Evidence grounding check: for each key_decisions[].evidence_citation, verify the citation references a source that exists in the original [EVIDENCE_USED] input—this prevents hallucinated citations. Rationale preservation check: use a second LLM call (or a lightweight classifier) to compare each decision's rationale against the original agent trace; flag any rationale that contradicts or invents facts not present in the trace. Confidence calibration check: if the agent's own confidence markers are available, compare the summary's confidence_score against them; large discrepancies trigger a review. If any check fails, the harness should either retry the prompt with the validation errors fed back as [CONSTRAINTS], or escalate to a human reviewer with the failed validation report attached.

Retry logic must be bounded. Configure a maximum of 2 retries for validation failures. On each retry, append the specific validation errors to the prompt as additional constraints (e.g., 'The previous output had a hallucinated citation for source X. Only cite sources present in [EVIDENCE_USED].'). If retries are exhausted, log the failure, attach the partial output and validation report to the handoff record, and flag the transfer for human review. Never silently accept a failed summary—downstream agents acting on incorrect handoff context create compounding errors that are expensive to untangle. Log every handoff attempt with the prompt version, model, input hash, output, validation results, and routing decision. This log becomes your audit trail and your debugging surface when handoff quality degrades.

Finally, wire the validated summary into your agent routing system. Use the recommended_next_agent field as a suggestion, not an automatic routing decision—your orchestrator should still verify that the recommended agent is available, within capability scope, and not already involved in the task chain (to prevent loops). If the confidence score falls below a configurable threshold (start with 0.7), route to a human review queue instead of an automated downstream agent. This harness design turns the prompt from a text generation exercise into a reliable, observable, and safe component of your multi-agent pipeline.