Handoffs and the plan agent

You’ve built three things: a library-reviewer that judges a change against the library’s rules, a consumer-audit coordinator that fans subagents across the twelve consumers, and — from the start of the course — the built-in plan agent that produces an approach before any code is written. For the shared-lib change, those aren’t three separate errands. They’re stages of one careful workflow: plan the change, review the proposed surface against the rules, audit the consumers for breakage. The last primitive in this chapter is how you make agents flow into each other deliberately instead of you driving each one by hand.

Handoffs chain agents into a sequence

The handoffs field in an agent’s frontmatter declares which agents it can hand off to as sequential workflow transitions. Where the agents field is about delegating downward — a coordinator calling subagents that report back — handoffs is about moving forward: finishing one stage and transitioning to the next agent in line, carrying the work along.

For the library change, the natural chain reads like the work itself: plan the change first, then hand off to library-reviewer to check the planned surface against the additive-only rule, then hand off to consumer-audit to confirm none of the twelve consumers break. Each stage’s output becomes the next stage’s input. You’re not babysitting three separate conversations and copying findings between them — you’re defining the pipeline once and letting the handoffs move the work down it. On a change this consequential, a fixed sequence is a feature: it means the review and the consumer audit can’t be skipped just because you were in a hurry.

The plan agent comes first

Notice that the chain starts with a plan, and that’s not incidental. Back in the modes chapter you met Plan mode — Copilot producing a structured, step-by-step approach before writing any code, so you could approve the approach while it was still cheap to change. The plan agent is that same capability as a first-class step you can put at the head of a workflow.

For the highest-blast-radius change in the course, leading with a plan is the only sane opening. You don’t want an agent improvising edits to a library twelve services depend on; you want to see the proposed sequence — what surface gets added, in what order, with what compatibility guarantees — and sign off on it before a line changes. The plan is what your reviewer reviews and what your consumer audit is run against. Plan first, then review, then audit, then build. The plan agent is how that careful posture from Chapter 2 becomes a repeatable, agent-driven first move instead of a discipline you have to remember.

What you built in Act 1’s opening

Step back and look at the team you assembled, because it’s the shape of careful work on shared code:

• A reusable reviewer that carries the library’s compatibility rule so you never re-explain it.
• A coordinator that fans subagents across all twelve consumers in isolated context, turning a dozen risky guesses into a dozen clean verdicts.
• A workflow — plan, review, audit — chained with handoffs so the careful steps can’t be skipped.

That’s reusable, delegated context doing exactly what this part of the course is about: making a change you couldn’t safely make by hand into one you can ship with confidence.

There’s one piece of shared-lib’s knowledge you’ve been carrying in prose — the team’s audit-event convention, the specific shape of the new approval.requested / approval.granted events the library is gaining. Right now it lives in your reviewer’s instructions and in your head. The next chapter packages that convention into something portable that both repos can use, and that works across more than just Copilot. Next chapter: Skills.