Lead-to-Teammate Plan-Approval Handshake¶

The handshake holds a teammate in read-only plan mode until the lead approves its plan; rejections round-trip with feedback before any writes happen.

Related lesson: Handoffs and Coordination Contracts — this concept features in a hands-on lesson with quizzes.

The handshake¶

In a lead-and-teammates topology, each teammate works in its own context window and claims tasks from a shared list. A plan-approval handshake gates the first write. The teammate writes a plan in read-only mode, sends it to the lead as a structured approval request, and starts editing only after the lead approves.

sequenceDiagram
    participant L as Lead
    participant T as Teammate (plan mode)
    L->>T: Spawn with task + "require plan approval"
    T->>T: Read codebase, write plan
    T->>L: Plan-approval request
    alt Approved
        L->>T: Approve
        T->>T: Exit plan mode, begin writes
    else Rejected
        L->>T: Reject + feedback
        T->>T: Revise plan (still in plan mode)
        T->>L: Resubmit
    end

The Claude Code agent-teams documentation describes the loop verbatim: "When a teammate finishes planning, it sends a plan approval request to the lead. The lead reviews the plan and either approves it or rejects it with feedback. If rejected, the teammate stays in plan mode, revises based on the feedback, and resubmits. Once approved, the teammate exits plan mode and begins implementation" (Claude Code: agent teams).

What makes it a gate, not a suggestion¶

The teammate cannot start writing until approval lands, because the permission model enforces plan mode rather than prompt discipline. In plan mode, "Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source" (Claude Code: permission modes). The edit tools stay unavailable until the mode changes, and only the lead's approval changes it. This sets the pattern apart from a prompt-level "please get approval before editing" — agents break those instructions routinely under load.

Criteria live in the lead's prompt¶

The lead approves autonomously. You steer its judgment through the prompt itself, not a separate rules file or hook. The Claude Code docs give the canonical examples: "give it criteria in your prompt, such as 'only approve plans that include test coverage' or 'reject plans that modify the database schema'" (Claude Code: agent teams). Criteria scope to the team and disappear when the team disbands, so there is no global rule registry to drift.

Pairing with critic-agent plan review¶

The critic-agent pattern and the lead-teammate handshake apply review at the same stage — the plan — but differ in who reviews and why:

Dimension	Critic Agent	Lead-Teammate Handshake
Reviewer context	Fresh, scoped to the single plan	Team-wide, sees other teammates' work and the shared task list
Reviewer identity	Often a different model class	Same model class as the team; cross-task visibility is the unique signal
Trigger	Every plan from one planner	Only teammates configured with the requirement
Failure surface	Critic misses model-shared blind spots	Lead rubber-stamps under queue pressure

The two compose. A team can require plan approval and also route those plans through a critic agent before the lead sees them. That puts a fresh-context grader and a cross-task coordinator on the same artifact.

Why it works¶

The handshake moves error-fixing to the cheapest moment. A plan-stage mistake caught by the lead costs one extra model call. Caught mid-execution, it needs rollback, re-planning, and re-execution — each one paying again the token cost of consumed steps. This is the same economic argument that grounds the critic-agent pattern.

What this adds over a generic critic is cross-task coherence. Each teammate plans in isolation — "the lead's conversation history does not carry over" (Claude Code: agent teams). So without a gate, two teammates can write plans that collide on the same file or solve overlapping problems in diverging ways. The lead sees both plans against the shared task list, the only vantage point in the team with that view. The Multi-Agent System Failure Taxonomy (Cemri et al., 2025) annotates more than 1,600 production traces and names inter-agent misalignment as one of three primary failure categories. The lead's plan-time veto is the cheapest way to intervene against it.

Read-only enforcement matters because it stops a teammate from acting on its blind spots before review. Prompt-discipline alternatives share an architecture with same-model self-correction, which shows a 64.5% average blind-spot rate across 14 tested LLMs (Chen et al., 2025: Self-Correction Bench).

When this backfires¶

Trivial or solo-shaped tasks: when each teammate's first write is a one-file edit with obvious scope, the handshake doubles round-trips to prevent errors a post-write diff review would catch in one round. Anthropic's own guidance warns that teams "add coordination overhead" and "work best when teammates can operate independently" (Claude Code: agent teams).
Same-model lead with no rubric: when the lead is the same model as the teammate and approves without external criteria, the 64.5% self-correction blind spot applies to the gate itself (Chen et al., 2025). The handshake becomes ceremony.
Lead-as-bottleneck team sizes: with five or more teammates requesting approval on staggered timelines, the lead's queue becomes the critical path. The lead either rubber-stamps to clear depth or leaves teammates idle waiting.
Rapidly evolving plans: when discoveries force the plan to change mid-execution, the gate becomes a re-approval treadmill. For exploratory work the gate's cost rises while its benefit drops.
Autonomous-lead rubber-stamping: "the lead makes approval decisions autonomously" (Claude Code: agent teams) — a same-architecture LLM judging the plan. For high-stakes work, escalate to user-as-lead or wire a TeammateIdle or TaskCompleted hook (Claude Code: agent teams — hooks) to require human sign-off.

Example¶

A lead spawns a team to refactor an authentication module with a plan-approval requirement:

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes. Only approve plans that:
- preserve the existing JWT contract for issued tokens
- include a backward-compatibility shim for callers on the old API
- list which test files will be updated

The architect explores the codebase in plan mode, then submits a plan-approval request that describes a rewrite of the session store. The lead reads the plan, notices it omits the backward-compatibility shim, and rejects it with the feedback: "Plan must include a shim for the existing /auth/session endpoint — current callers cannot break in this release." The teammate, still in plan mode, revises and resubmits. The lead approves. The teammate exits Claude Code plan mode and begins editing.

No code is written during the rejection round. Catching the missing shim costs one extra model round-trip, not a revert.

Key Takeaways¶

The handshake gates writes on peer review: a teammate stays in read-only plan mode until the lead approves its plan.
The gate is enforced by the permission model, not by prompt discipline — a teammate in plan mode is structurally incapable of editing.
Approval criteria live in the lead's spawn prompt, keeping policy scoped to the team rather than a global rule surface.
The pattern composes with the critic-agent pattern — same review stage, different reviewer purpose (cross-task coherence vs fresh-context grading).
Failure modes are predictable: solo-shaped tasks, same-model lead without rubric, lead-as-bottleneck queue depths, and exploratory work where plans must change mid-execution.