Fan subagents out across the consumers

You have a reviewer that judges a proposed change against the rules of shared-lib - the course’s illustrative internal library, imported by about a dozen services. The harder question comes when you are about to ship: does the new library version break the services that already import it, as each of them uses it today? In the running scenario there are roughly a dozen consumers; use whichever consumers your own library has. Each one is a separate investigation, and running them one after another in a single chat is both slow and muddy - by service nine, the conversation is carrying the assumptions of services one through eight.

That is what subagents are for. A subagent is a separate agent invocation called by another agent rather than by you, and it runs in its own context. A coordinator 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 takes two things in the coordinator’s frontmatter, and they do different jobs:

1. The agent tool in its tools list is the capability to invoke another agent at all. No agent tool, no delegation - and an agents list without it has no mechanism to call anyone.
2. The agents field is the guest list: the agents it may call, by name. Leave it out and the subagents documentation treats it as *, every available agent; [] blocks subagents entirely (as of September 2026).

So the tool is required and the list is a narrowing. For an audit whose whole value is a predictable checker per consumer, name the checker rather than leaving the list open.

Build the fan-out

Two files make the fan-out: a per-consumer checker, and a coordinator - call it consumer-audit - that delegates to it (the agents allow-list, the * wildcard, and user-invocable are documented agent fields, verified September 2026).

The checker is a custom agent like any other: a focused persona that, given one service, reads how that service uses the library and reports whether the upcoming change breaks it. It gets read-only tools and user-invocable: false, because it is meant to be summoned by the coordinator, not picked from your dropdown:

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

---
name: consumer-checker
description: Checks one consumer service against a proposed shared-lib change and reports breaks per affected symbol.
tools:
  - read
  - search
user-invocable: false
---

You check exactly one consumer service against a proposed shared-lib change.

Given the service name and the change summary:
1. Find every import of shared-lib in that service.
2. For each imported symbol the change touches, decide whether the service's current usage still compiles and behaves the same.
3. Report a verdict: breaks / doesn't break, with each affected symbol and the file that uses it.

Report only. Do not edit files.

The coordinator adds the agent tool and names the checker in agents. It keeps the search tool set only to gather the change summary and the consumer list before delegating - the checking itself is delegated:

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

---
name: consumer-audit
description: Coordinates per-consumer breakage checks against a proposed shared-lib change.
tools:
  - search
  - 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.

Hand the coordinator the job - here is the new library surface, here are the consumers, check each one - and it dispatches a checker per service. Each checker examines one consumer and returns a verdict: breaks, does not break, and where. The coordinator gathers the answers into one report you can read.

Why isolation is the whole point

The reason this beats a long single conversation is not just speed, though the documentation describes subagents running in parallel. Nor is it cost: a dozen subagent invocations is a spend decision, even when each focused check is small. It is that each consumer gets reasoned about on its own terms. The subagent checking service nine is not carrying assumptions, half-remembered file paths, or 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 are making to other teams.

The 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 make the change given everything the subagents found. Sequencing agents into a deliberate workflow, and putting a plan at the front of it, is the last move in the chapter. Next: handoffs - chaining plan, review, and audit.