Fan subagents out across the consumers

You have a reviewer that judges the change. Now the harder question: the new shared-lib version is about to go out — does it break any of the roughly twelve services that already import it? Each consumer uses the library a little differently. Checking them is twelve separate investigations, and doing them one after another in a single chat is both slow and muddy — by the eighth consumer your conversation is so full of the first seven that Copilot is reasoning through fog.

This is what subagents are for. A subagent is a custom agent called by another agent rather than by you, and it runs in its own isolated context. So a coordinating agent can spin up one subagent per consumer, each starting clean, each focused on a single service, none of them polluting the others. Twelve checks, twelve fresh contexts, one coordinator collecting the verdicts.

What makes an agent a coordinator

Delegation isn’t on by default — an agent has to be explicitly allowed to call others, and that takes two things in its frontmatter, both required:

1. It must include the agent tool in its tools list. That’s the capability to invoke another agent at all. No agent tool, no delegation.
2. It must list the agents it’s permitted to call in its agents field — by name, or * for all of them.

Miss either one and the coordinator simply can’t fan out: the agent tool without an agents allowlist has nothing it’s cleared to call, and an agents list without the agent tool has no mechanism to call them. You need both. Think of it as a capability (agent in tools) plus a guest list (agents).

Build the fan-out

Make a coordinating agent — call it something like consumer-audit — whose job is to check the consumers against the new shared-lib surface. In its frontmatter, add the agent tool and set agents to allow the per-consumer checker it will delegate to. The checker itself is a custom agent like any other: a focused persona that, given one service, reads how that service uses shared-lib and reports whether the upcoming change breaks it. You might even mark the checker user-invocable: false, since it’s meant to be summoned by the coordinator, not picked from your dropdown.

Now hand the coordinator the job: here’s the new shared-lib surface, here are the twelve consumers, check each one for breakage. It dispatches a subagent per service. Each subagent opens that one repo’s usage, reasons in a context that contains nothing about the other eleven, and returns a clean verdict — breaks / doesn’t break, and where. The coordinator gathers the twelve answers into one report you can read.

Why isolation is the whole point

The reason this beats a long single conversation isn’t just speed, though running them in parallel is faster. It’s that each consumer gets reasoned about on its own terms. A subagent checking service number nine isn’t carrying the assumptions, the half-remembered file paths, or the conclusions from services one through eight. Isolated context means each verdict stands on its own evidence — which is exactly the rigor you want when “doesn’t break” is a promise you’re making to twelve teams.

That fan-out gives you a list: which consumers are clear, which need a heads-up, which would actually break. That list is an input to a plan — the careful sequence in which you’ll make the change, given everything the subagents found. Sequencing agents into a deliberate workflow, and producing that plan before any code, is the last move in the chapter. Next: handoffs and the plan agent.