Orchestration
When one agent spawns twenty,
who governs the twenty?
Multi-agent pipelines decompose a task, fan out subagents, verify adversarially, and merge results — unattended. Every subagent in a governed pipeline is a skoored agent: spawned with its scope declared, its ceilings inherited, its conduct journaled, and its own row on the skoorboard. Skoor governs orchestration. It never orchestrates.
Implementing a skoored subagent, step by step
Every step uses mechanisms that exist today — Claude’s own agent definitions, tool allowlists, effort configuration, and result journaling — plus the skoorboard discipline. No special runtime, nothing of ours in the loop.
Name it on the roster before it runs
A subagent nobody can name is a subagent nobody governs. Before the first spawn, the agent gets a skoorboard row: an id, an owner, a purpose, and the profile version it will run under. This is a bookkeeping act, not a technical one — and it is the step most pipelines skip.
Write its scope before its prompt
Least privilege, declared as an allowlist: which tools and connectors this subagent may use, bound tighter than its parent. In Claude Code that is the agent definition's tools list; in Claude Managed Agents it is the tools and guardrails configured per agent. Anything unlisted is unreachable — enforcement by construction, not by request.
Put the refusals where the agent reads them
The same mechanism Anthropic documents for standing consent works for standing refusal: rules written into the subagent's system prompt and tool descriptions ride along on every turn. Never post, never send, never touch payroll — stated where the model actually looks, not in a policy PDF nobody loads.
Set the ceilings — and make them inherited
Effort level, budget, and turn caps per task class, set at spawn time. The orchestration policy's hard rule: a subagent's ceilings are always at or below its parent's. Fan-out multiplies capability; it must never multiply permission.
Journal every run to a store you control
Orchestration patterns already journal results for idempotency — that journal is audit-trail-shaped. Route it to your own sink and require the fields on every entry: agent id, profile version, what was reached, timestamp. A run that leaves no record is a drift event, not a quiet success.
Spawn it governed
The orchestrator passes the constrained definition — scope, refusals, ceilings — as the subagent's identity, not as a suggestion. The pipeline policy says who may spawn what: which parents, which molds, how deep. A subagent spawning subagents inherits the whole chain.
Leave its score slot empty
A new subagent's Agent Skoor starts unmeasured — an empty slot on the board, never a placeholder number. Conduct accumulates session by session; the number is computed from the journal, not typed into it. If a pipeline runs a hundred subagents, the board shows a hundred honest rows.
What steps 02 and 03 look like in practice
A subagent definition in the shape Claude Code uses — the allowlist is the scope, and the refusals live in the prompt the agent actually reads. The pattern, shown generically:
--- name: reconciliation-subagent description: Reads the ledger, drafts the reconciliation memo. Read-only. tools: Read, mcp__ledger__read # the allowlist IS the scope (step 02) --- You are the reconciliation subagent. Profile v1 applies. Standing refusals (step 03): - Never post, edit, void, or delete any entry. - Never send anything to anyone. - Never reach an account not named in your profile. Every result: journal to the audit sink with your agent id, profile version, what was read, and a timestamp (step 05).
The pattern, not a vendor’s exact syntax — Managed Agents express the same scope and guardrails through their API and Console configuration.
What the board shows mid-pipeline
A pipeline’s roster, honestly rendered: every spawn is a row, every new row starts empty. Numbers arrive from conduct, never from optimism.
skoorboard · Your firm
nothing measured yetAgent · Orchestrator
profile v1 · spawns constrained
Subagent · Researcher
ceilings inherited from parent
Subagent · Reconciler
read-only scope, step 02
Subagent · Verifier
adversarial pass, journaled
The wiring: not an SDK
There is no Skoor runtime library, deliberately. A library in the loop would make Skoor the enforcement layer — and a scorer inside the loop cannot independently attest to the loop. The wiring is configuration plus two things that already exist:
The local Skoor MCP server hands Claude the mold
When an orchestrator is about to spawn, it can ask the Skoor connector for the mold: list_molds, get_mold, and get_journal_schemareturn the scoped definition, the standing refusals, and the audit fields — local, read-only, published data. Claude writes the subagent itself; nothing of ours executes in the run.
The platform already carries the journal
Locally, every Claude Code session is a transcript file on your own machine, and a session-end hook can archive it to your audit sink automatically — the trail, wired with configuration you already have. On managed agents, session tracing plays the same role under your own account. Either way the record lands in a store you control, and Skoor reads it to compute the scores.
Stated plainly
Skoor is not the orchestrator. Nothing of ours sits in the loop, schedules a run, or steers a subagent — the platform enforces the policy; we certify what the policy says and measure whether conduct stayed inside it. A scorer inside the loop could not independently attest to the loop.
And no certification is claimed here: profiles and scopes on this page are the discipline Skoor certifies when engaged, stated in advance. The board renders unmeasured because that is the truth until a rubric-computed number exists.
Govern the twenty before you spawn them.
The assessment maps what your agents and their subagents can already reach — and produces your baseline Company Skoor.