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 the services or packages that already import it? In the running scenario there are roughly twelve; in your own lab, use the consumers you actually have. Each consumer may use the library a little differently. Checking them is a set of separate investigations, and doing them one after another in a single chat is both slow and muddy.

This is what subagents are for. A subagent is a separate agent process called by another agent rather than by you, and it runs in its own context. A coordinating agent can dispatch one checker per consumer, each focused on a single service, then collect the verdicts. The number twelve is illustrative; the pattern works for two consumers or twenty.

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 consumers, check each one for breakage. It dispatches a checker per service. Each checker examines one consumer and returns a clean verdict - breaks / doesn’t break, and where. The coordinator gathers the answers into one report you can read.

The coordinator’s file:

.github/agents/consumer-audit.agent.md

---
name: consumer-audit
description: Coordinates per-consumer breakage checks against a proposed shared-lib change.
tools:
  - read
  - glob
  - grep
  - agent
agents:
  - consumer-checker
---

You are a coordinator that audits whether a proposed shared-lib change breaks existing consumers.

Given a description of the change and a list of consumer services:
1. For each consumer, delegate to the consumer-checker subagent with the service name and the change summary.
2. Collect each subagent's verdict: breaks / doesn't break, and which symbols are affected.
3. Produce a single summary report listing every consumer, its verdict, and any required action.

Do not check consumers yourself - delegate every check so each runs in isolated context.

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.