# Five specialist subagents, delegated by description

> Five domain-scoped .claude/agents/ subagents, each with its own restricted tool list and per-agent pre-commit skip-list, delegated by description not by name.

**Canonical URL**: https://agentcookbooks.com/blog/custom-subagents-autonomous-delegation/

**Published**: 2026-06-03

**Tags**: claude-code, subagents, agents

---

The usual subagent move is fan-out: spin up N interchangeable workers for independent tasks, collect, discard. This setup is the opposite. Five subagents live in `.claude/agents/`, each scoped to exactly one problem category in the project's domain, each with its own restricted tool list, and the orchestrator decides which one to call from each agent's `description` frontmatter — not from the operator naming it. No before/after time saving has been measured yet; the receipt that follows is about the structure, not the speedup.

## What I ran

This wasn't a skill activation. It was a cross-project transfer of a working Claude Code setup: five custom subagents, all Sonnet-based, each narrowed to one slice of the project's domain. The operator's framing was the load-bearing constraint: *"I don't want to always name the agent — I want you to use them when they fit the task."* So delegation had to come from recognizing a trigger, not from a `@agent-name` call.

The five agents, with their restricted tool lists:

```
regulated-content-validator   validates sensitive-topic content against the
                              editorial stance + canonical rules (pre-commit
                              #13/#16 level)                       Read, Grep, Glob
precommit-debugger            diagnoses why .githooks/pre-commit failed; knows all
                              19 rules + their false-positive traps; NEVER suggests
                              --no-verify                          Read, Grep, Glob, Bash
competitor-watcher            scans known competitors against memory baselines via
                              WebFetch, reports changes + suggested actions
                                                                   Read, Grep, Glob, WebFetch
decision-log-updater          writes decisions into the triple (decision log +
                              spec §14 + project memory), knows the format
                                                                   Read, Edit, Grep, Glob
pseo-gate-checker             validates getStaticPaths against the thin-content gate;
                              checks Search Console health limits + sitemap excludes
                                                                   Read, Grep, Glob, Bash
```

Two structural choices sit on top of the five agents. A **per-agent pre-commit skip-list**: an agent may edit files the pre-commit rules would otherwise reject, because its output is scoped to its expertise — the decision-log-updater quotes regulated terms in a decision context that rule #16 would normally block. And the **autonomous delegation pattern**: the orchestrator reads each subagent's `description` and decides delegation itself.

## What happened

The trigger map lives in project memory. It's what turns "use them when they fit" from a vibe into something the orchestrator can act on:

```
precommit-debugger      → "pre-commit failed" / "rule #N failed" / a hook error message
regulated-content-val.  → editing sensitive-topic content + a regulated term present
pseo-gate-checker       → a getStaticPaths change / a new active=true / "thin content"
decision-log-updater    → a non-trivial choice made + the operator confirms
competitor-watcher      → the operator names a competitor in a comparison
```

The map is also defined by what it refuses to dispatch. The spin-up is deliberately avoided for three things: a single file read or grep (`Read`/`Grep` is faster), a small edit to one file (`Edit` directly), and general strategy discussion (the orchestrator handles synthesis). Dispatching a whole subagent to read one file is pure overhead; the trigger map exists to keep that from happening.

The measured shape of the setup: **5 agents, each with a restricted tool list. 1 trigger map. 0 `--no-verify` bypasses needed.** That last number is the point of the per-agent skip-list — the one agent that legitimately needs to quote regulated terms does so without ever weakening the global guard.

## Persistent specialists vs. one-off fan-out

This is the contrast worth drawing out, because the two patterns look similar on the surface — both "use a subagent" — and they solve opposite problems.

[`dispatching-parallel-agents`](/skills/dispatching-parallel-agents/) is for 2+ *independent* tasks with no shared state. You spin up interchangeable workers, each gets a slice, you collect the results and the workers evaporate. Two posts on this site are that pattern in practice: [one dispatch classifying 160 files](/blog/one-dispatch-160-files-classified-the-rubric-was-the-bug/) and [six personas run in parallel](/blog/six-personas-in-parallel-three-findings-emulated-not-installed/). The worker is generic; the task is what varies. Once it returns, it's gone.

The five-agent setup inverts every part of that:

- **Persistent, not one-off.** The agents are checked-in files in `.claude/agents/`, chosen per problem *category*, reused across sessions — not workers spun up for one task and discarded.
- **Specialist, not interchangeable.** Each knows *one* thing exactly. The precommit-debugger doesn't say "rule #14 failed" — it knows #14 only covers `active=true` districts and that its false-positive trap is the 50-character validation on one field. A generic guide could be called for any of these, but its answer would be generic and the operator would still have to map context → project-specific rule by hand.
- **Restricted tool list per agent, not the orchestrator's full kit.** The regulated-content-validator gets `Read, Grep, Glob` and nothing else; it can't write. The decision-log-updater gets `Edit` because writing the triple is its job. The tool list *is* the scope.
- **Per-agent pre-commit skip-list, not a global loosening.** A global skip-list would weaken the guard everywhere. Per-agent keeps the guard tight on all other work while letting the one agent that needs to quote regulated terms do so — compliance by construction, not by bypass.
- **Delegated by description, not by name.** The trigger lives in the agent's `description` frontmatter, so the orchestrator self-selects. Fan-out is the operator deciding "run these N now"; this is the orchestrator deciding "this is a precommit-debugger problem" from the shape of the request.

Same primitive — a subagent — pointed at a different problem. Fan-out parallelizes throughput on independent work. Persistent specialists encode project-specific judgment that a generic agent doesn't have.

## Where it drifted

Three reasons this beats a generic expert agent, and the place each one can go wrong.

**Specificity beats generality — but only if the specificity is real.** Each agent earns its keep by knowing the thing a generic guide can't: the 19 pre-commit rules plus their skip-lists, the regulated-term list plus the official-source-link requirement, the competitor baselines. The failure mode is an agent whose `description` promises specificity its body doesn't deliver — then you've paid the dispatch cost for a generic answer wearing a specialist's name.

**Per-agent skip-list is compliance-by-construction — but the boundary has to be drawn per agent.** The temptation under pressure is a global skip-list to make a stubborn commit go through. That weakens the guard on every future edit. The discipline is to grant the exception to exactly the one agent whose scoped output needs it (decision-log-updater quoting regulated terms) and to nobody else. The payoff shows up as the `0` in "0 `--no-verify` bypasses needed."

**Autonomous delegation lowers operator cognitive load — but only if the trigger map is precise.** This is where it drifts hardest. A loose trigger ("spin up the decision-log-updater whenever 'decision' is said") fires constantly and erodes trust. The version that works is narrow: "...when ≥3 options were weighed *and* the operator confirms." The trigger map isn't documentation — it's the actual control surface for autonomous delegation, and a vague entry is a misfire waiting to happen.

## What I would change

The honest gap is measurement. The receipt is marked **ship, needs-more** on outcome metrics: the structure is sound and reused, but no before/after time saving has been captured. Five agents, one trigger map, zero bypasses is a real shape — it just isn't yet a *speedup* anyone has clocked.

So the change is to instrument it. Run a real session with the trigger map live and log: how often the orchestrator self-delegates correctly, how often it misfires (dispatches when a direct `Read`/`Edit` would've been faster), and whether any commit needed a `--no-verify` the per-agent skip-list should have covered. Until those numbers exist, the claim is "this structure encodes project-specific judgment a generic agent lacks" — not "this structure is faster." Pairing the next run with [`verification-before-completion`](/skills/verification-before-completion/) on the dispatched output would catch the misfires before they ship.

The reusable idea stands on its own regardless: domain-specific subagents are more than `CLAUDE.md` rules. They're a *chosen specialist per problem category*, each with its own tool limits, its own pre-commit skip-list, and an autonomous-delegation trigger living in its `description`. Generic agents don't know your project's false-positive traps. **5 agents, 1 trigger map, 0 `--no-verify` bypasses.**