Handing a task from one agent to another: what the brief carries and what it drops

Goal

Give a second agent (a subagent, a fresh context after compaction, or a different specialist) everything it needs to continue a task correctly, and nothing that would mislead it or fill its context with material it cannot use.

Prerequisites

A clear reason for the handoff: the receiver has tools, permissions or a clean context the sender lacks. The cited Anthropic engineering post on its research system states that each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries, and that without detailed task descriptions agents duplicate work, leave gaps or fail to find necessary information. The Claude Code documentation describes the complementary direction: a subagent starts with a fresh context that does not see the conversation history, works from the delegation message it is given, and returns only the summary.

Steps

1. Write the objective in one sentence and the acceptance check in another ("done when the test suite passes and the diff touches only billing/").
2. Pass material by identifier, not by content: file paths, commit hashes, URLs, record IDs, line ranges. The receiver can fetch what it needs; a pasted copy goes stale and costs tokens twice.
3. List decisions already taken with their reason ("using library X because Y is unmaintained"), so the receiver does not reopen them.
4. List open unknowns explicitly ("not yet checked whether the API is rate-limited"). An unknown that is omitted looks like something already settled.
5. State the scope and the budget: which tools and directories are in bounds, which actions need approval, how many calls or how much time the receiver has.
6. Fix the return format: result, evidence (which checks ran, with output), what changed, and remaining unknowns, in a structure the sender can merge without reading a transcript.
7. Drop the rest: raw tool output, the full conversation, and dead ends. Keep one line per dead end ("tried X, failed with Y") so it is not repeated, and drop the reasoning that led there.
8. Read the brief once as if it were the only thing in the context; anything that only makes sense with the sender's history is rewritten or removed.

Expected result

A receiver that starts working within its first turn instead of asking clarifying questions or re-deriving the sender's decisions, and a return that the sender can merge mechanically.

Limits and test basis

The steps are a proposal derived from the cited documentation; no measurement of handoff quality is claimed. Briefs for adversarial or safety-relevant tasks additionally need the sender's permissions and trust boundaries spelled out, since the receiver inherits nothing implicitly.