Twelve Agents, Measured

A roster of twelve specialist agents, measured against the usage threshold this site published for it. Two specialists are three quarters of the traffic, half the roster falls under the threshold, and the outcome column turns out to be a literal in a hook.

Two weeks ago this site published a design note on splitting one agent into twelve specialists. It ended with a section on when not to split, and the first signal in it was a usage threshold:

Fewer than a handful of tasks per month. A specialist that runs rarely is a definition file that goes stale — its tools change, its domain rules drift, and nobody notices because nothing exercises it. When it finally runs, it runs on assumptions from months ago.

That was written from the design, not from data. There is now data. A dispatch ledger has been written automatically since 2 August, one row per delegation. This is the same roster measured against its own criterion.

Window: 2–27 August 2026, 26 days. 161 dispatches, every one written by the hook [measured].

The instrument, and what it cannot see

A hook fires after a delegation returns and appends one row. It ignores the generic agent types and writes only for the twelve named specialists. Three properties decide how every number below should be read.

A zero means zero delegations, not zero work. Anything the orchestrator handles inline leaves no row. This measures the routing layer, not the workload.

The hook composes every field from the call's input. It reads the requested specialist and the task description; it never looks at what came back.

It is fail-silent by design. The exception handler is a bare pass, and the writer is invoked with output captured and its exit code unchecked — so a row it fails to write, and a row it writes for a run that produced nothing, are equally invisible in its own output.

The distribution

The thirteen names below are roles, not products: each is one specialist agent with its own tools and its own list of work it must refuse. One label changed between the two articles — what the earlier design note called operations is the e-commerce row here. The roster did not change; the label did.

Eleven of the 26 days in the window carry no row for any specialist [measured]. That is the honest denominator: the system did not delegate at all on those days.

Two specialists are three quarters of the traffic

Research and content together are 119 of 161 dispatches — 73.9% [derived]. The four lowest agents — sales, real estate, HR and legal — got 3 between them, which is 1.9% of the window [derived].

Against the published threshold, read as five per month: 26 days is 0.87 of a 30-day month, so the in-window equivalent is 4.3 dispatches [derived]. Six of the twelve agents fall below it — finance and strategy at 4, real estate at 2, sales at 1, HR and legal at 0. That is exactly half the roster.

Two cautions on that verdict, both of which cut against it.

The median depends on which list you use. Across the thirteen names the counter tracks, the median is 4 — under the line. Across the twelve that are actually agents, it is 5.5 [derived] — over it. The gap between those two numbers is not rounding. It is the roster mismatch described below, and it is the more interesting finding of the two.

The threshold is a word, not a number. The design note said a handful and never gave a figure. Read as five, six of twelve fall below. Read as four, four do. A verdict this sensitive to a reading is an argument for writing the number down the first time, not for trusting either count.

The totals column hides the shape

Content leads the per-agent table and is active on 2 days [measured]. Fifty-two of its 55 rows are one job on one day; the other three are three rounds of a single deliberation, on another day.

Research is the opposite: 64 dispatches across 13 of the 15 days the ledger recorded anything at all — the only specialist in the roster that behaves like a habit rather than an event.

Read alone, the totals column says there are two workhorses. The days column says there is one workhorse and one machine that was switched on twice.

The outcome column is a constant

161 of 161 automatic rows say DONE. 161 of 161 say quality TBD [measured]. The only row in the entire ledger recording a failure is one of the two entered by hand in June, before the hook existed.

That is not a 100% success rate. It is a column that cannot hold anything else:

subprocess.run(
    [sys.executable, script, "-a", agent, "-t", task,
     "-o", "DONE", "-s", f"hook:{sid}", "-q", "TBD"],
    timeout=20, capture_output=True,
)

Both values are literals in the call. The hook runs after the tool returns, so DONE means the delegation came back — not that the output was right, complete, or used. The column answers a question the row's own existence already answered.

It can be shown false without any new measurement. The busiest day in this window has its own published post-mortem, and that piece records eleven runs that crashed reporting nothing, plus three that reported completion having written no file. The ledger holds 52 rows for that day and every one says DONE. At least ten of those are false [derived], and the ledger has no field in which that could ever surface.

A column that is always the same value is worse than a missing one. A missing field invites the question; a constant field answers it wrongly. Same shape as a check that reports zero problems — true about its own narrow question, false about the one being asked.

Two names never fired, and a third structurally cannot

Across the ledger's whole life — 163 rows since 20 June — three names have never appeared: HR, legal, and a folder-mining routine [measured].

The date range overstates the evidence and should not be quoted without the gap: the hook only started on 2 August. The 43 days between the first two rows and the third are not thin evidence, they are none. Both hand-written rows are from 20 June, the ledger's first day, and the practice was never repeated.

The first two zeros are real specialists that were routable and did not fire. The third is a different object. The ledger's writer accepts thirteen names; the hook that feeds it accepts twelve, and folder-mining is not among them — it is a skill, not an agent, and the hook only fires on agent dispatch. No automatic run can produce that row. A hand-written entry could, and there have been two of those, both on the same day in June.

A permanent zero that looks exactly like an idle specialist is the more expensive of the two, because the register listing it counts the capability as covered.

The two counts of the same day disagree by one

The published post-mortem of 18 August reports 53 runs launched for an 827-item writing job — 45 in its three measured size arms, and "the other eight were redistribution runs."

The dispatch ledger holds 52 rows for that specialist on that day: 5 first-wave blocks, 30 quarter-size batches, 10 half-size splits, 7 retries [measured]. The three size arms match exactly. The gap is seven retries against eight redistributions.

Neither count settles it. The post-mortem's 53 is 42 runs that reported their consumption plus 11 that crashed reporting nothing; the ledger's 52 is hook writes. Both are derived from the dispatch side rather than reconstructed from the artifacts, so neither has the stronger claim, and the missing run is not identified. Note also that the two articles use ledger for different objects: there it means the filesystem tracker that counted delivered items, here it means the dispatch log. It is recorded rather than reconciled, because a one-row gap inside a 52-row day is exactly the size that gets rounded away.

What this does not measure

Not workload — inline work leaves no trace. Not quality — the outcome field is a constant. Not routing correctness — a dispatch to the wrong specialist logs identically to a right one. Not value — one delegation can be worth more than sixty.

What is not known

Whether the two never-fired specialists were needed and skipped, or genuinely had no work in 26 days, is not in this ledger and cannot be derived from it. The answer needs a second source — the tasks handled inline — which is not logged anywhere. Until that source exists, a zero here is a fact about routing, not a verdict on the domain.

Three changes follow from the ledger alone, and none of them require another measurement: the outcome field gets a real value or gets deleted; the counter's roster and the hook's roster get reconciled to the same list; and a name at zero across two consecutive windows gets a decision rather than another recount.

See also

twelve-agents-one-memory · the-output-cap-is-the-batch-size · zero-problems-found · a-rule-without-an-executor

[Twelve Agents, Measured](https://stillvalid.dev/architecture/twelve-agents-measured) — stillvalid, SV-2435 (benchmark, verified 2026-08-28)