Spawning subagents is the easy half. The gate is the hard half.

It means a parent Claude Code session uses the Task tool to spawn specialised child agents, each with its own context window, tool allowlist, and system prompt, and then merges their outputs into one pull request. The pattern only becomes production-safe when every subagent PR runs through a CI rubric that can block the merge. The rubric, the subagent definitions, the workflow, and the operator runbook live as four files inside the client's repo; the orchestrator is a verb, the four files are the noun.

Because a human reviewer is the wrong bottleneck for parallelised agent work. When one issue spawns four subagents and the orchestrator opens a single PR with a multi-file diff, the reviewer is effectively being asked to scan the output of four agents at once in the same attention budget they used to spend on one engineer's PR. The rubric moves the hardest parts of that judgement (per-section correctness, security, domain invariants) into a structured score the reviewer can trust. The reviewer still approves, but they are approving a diff that has already beaten 0.82 on a rubric they wrote.

YAML frontmatter plus a system prompt. The frontmatter has `name`, `description`, `tools` (an allowlist, explicitly scoped), and `model`. The body is the subagent's system prompt, which encodes what it is allowed to do, what it is explicitly not allowed to do, and the output format it must produce. The reviewer subagent we ship is about forty lines and ends with an explicit prohibition on recommending merges below the rubric threshold. Having the prohibition in the prompt is load-bearing; it is the part a compliance reviewer reads first.

Agent Teams lets multiple Claude Code sessions run in parallel and talk to each other directly, with a team lead coordinating. It is a runtime feature. Our pattern is an engineering pattern: subagents as Markdown files, a CI workflow as the gate, a rubric as the contract, a runbook as the handoff artifact. The two are compatible — you can run Agent Teams behind the rubric gate, you just enable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS in settings.json and treat the team lead as the orchestrator. The pattern here is what you would leave behind in the repo regardless of which Claude Code runtime is enabled.

Only for PRs labelled `claude-subagent`. The label is applied by the orchestrator when it opens a PR; a human-authored PR does not get the label and skips the eval workflow. This keeps the rubric focused on the failure mode it was designed for, which is multi-agent diff sprawl, and it keeps human PRs on their existing review path. The branch protection rule names claude-eval as a required status check only when the label is present.

The workflow posts a PR comment naming the score, the failing sections, and the specific complaints from the reviewer subagent. The orchestrator reads the comment, decides which of its subagents can target the failing sections, respawns only those, and re-opens the PR with the new diff. Three repair cycles are allowed. If the third cycle still fails, the orchestrator pings the named engineer via the runbook's escalation entry and stops. No PR merges on a repaired-but-still-failing rubric; the 0.82 threshold is the same whether it is the first or the third attempt.

Portability and auditability. The rubric describes what a correct change looks like in this product; it is a higher-value artifact than most unit tests because it encodes judgment, not just mechanics. Keeping it in the repo means the git history records who changed the rubric and why, the pull request that changed the rubric is reviewable like any other, and an engineer who leaves the team cannot take the rubric with them. It also means we do not sell our clients a platform dependency; the whole Claude Code orchestration pattern runs on GitHub, Claude Code, and the Anthropic API, with no fourth vendor.

The rubric invocation is a single call on the reviewer subagent, and that call typically runs against a diff rather than the whole repo, so it is a small fraction of the orchestration budget. In our client engagements, the reviewer pass usually runs between 20K and 60K input tokens and produces a few thousand output tokens of JSON. The orchestration itself is usually 5-15x that, depending on how many subagents the orchestrator spawned and how much code each one read. FinOps sees both numbers on the per-run JSON artifact.

Yes. The CI workflow runs in the client's GitHub Actions runner, inside the client's VPC if they use self-hosted runners, with their Anthropic API key (or Bedrock endpoint, via the Bedrock integration). The code leaves GitHub Actions only to hit the model endpoint, which is the same network boundary the rest of the client's Claude Code usage already crosses. No third-party orchestration platform sits in the middle. For clients on Bedrock with PrivateLink, traffic does not leave the VPC.

The four files on main: `.claude/agents/<role>.md` for each subagent role, `.github/workflows/claude-eval.yml`, `evals/rubric.yaml`, and `runbook.md`. Plus CODEOWNERS on the four paths, branch protection requiring claude-eval as a status check on labelled PRs, and a 90-minute handoff session with the on-call rotation. The named engineer who wrote them stays available for 12 months after the engagement for paid two-hour consults at a published rate. That is the whole inventory; there is no vendor-hosted runtime to cancel and no platform subscription to renew.