Structured Handoff Protocols
Hand off with ID, summary, actions and recommendation.
Why Handoffs Need Structure
In a hub-and-spoke multi-agent system, the coordinator constantly hands work to subagents and receives results back. The CRITICAL fact: subagents do NOT inherit the coordinator's conversation history — the model keeps no state, so the FULL request history travels in messages every turn.
That means every handoff must carry its own context explicitly. An unstructured "go fix the auth bug" loses the case ID, what was already tried, and what decision the coordinator needs back. A structured handoff protocol fixes this: each transfer carries an identifier, a summary, the actions taken, and a recommendation.
The Four-Part Handoff
A reliable handoff payload has four fields, each solving a specific failure mode:
- ID — a stable correlation key (case_id, custom_id) so results can be matched to requests, even across parallel calls.
- Summary — the verbatim transactional facts the receiver needs (verified customer ID, order number, amounts).
- Actions — what was already attempted, with results, so work isn't repeated.
- Recommendation — the proposed next step or decision the receiver must confirm or override.
This maps directly onto how coordinators decompose, delegate, aggregate, and route.
All lessons in this course
- PostToolUse & Outgoing-Call Hooks
- Deterministic Enforcement vs Prompts
- Programmatic Preconditions
- Structured Handoff Protocols