Case study
Multi-agent operations architecture
I wrote the office's constitution — roles, escalation, write scopes, tool-call caps — then built the gate enforcing it against every page, including mine.
Context
A delegated unit fails in a specific way, and it is not the way people expect. It does not refuse the work. It produces a plausible artifact, states a number it never measured, and the number propagates into published copy because the next stage reads the artifact rather than the world.
The cheap version of this cost a run once: a 3.7 KB extraction passed an existence check against an 89 KB peer, and the gap cascaded through every downstream stage. The fix was not a better instruction. It was a check that compares file sizes against a minimum and exits non-zero.
So the office is written down before anything is delegated — who may decide what alone, what must escalate, where each stage may write, how many tool calls it gets, and what condition it has to satisfy before it may hand its work on. The organisation is the design. The gate is what makes the design real, and it runs on my own pages under the same terms as everything else.
What I built
Eight charter files define seven seats across four departments — forensic research, market research, security, and a four-seat data office. A charter is not a prompt. It declares the seat, the ground it may decide on alone, the ground it must escalate, its hard laws, and a closing form that will not accept the word done without the output it rests on, duration and an explicit full-or-partial state; partial keeps the task open. Authority is written as a boundary rather than a permission: a department may fix anything it likes behind the gate, and may not move the gate.
Below the charters sits the part that is mechanical. The publish pipeline runs six stages, each with a single writable root; the five worker stages also carry a hard tool-call cap — 40, 60, 15, 40, 50 — 205 calls per project before any work starts. The fifth stage runs in a fresh context, sees only the evidence file and the built page, never the earlier stages' reasoning, and re-runs every command those stages claimed to have run. Two consecutive failures there freeze the project: a reduced variant ships and the queue moves on. At the publication boundary sits a gate of 7 checks and 43 denylist patterns; the one path that can still be skipped rather than failed warns loudly and is named in the record.
The gate runs against every page the pipeline produces. The opening case study came back FAIL — six claim-level mismatches and two imprecisions, one of them the audit stage's own stated command failing to reproduce its own number. It stayed unpublished until the arithmetic matched.
The six-stage pipeline — one writable root per lane, a cap on each worker lane, the verify lane severed, the stop rule returning
VERDICT: FAIL
build ............... PASS
publish gate ........ FAIL 4 pass / 2 fail
identity scan ....... PASS
style ............... PASS
claim-by-claim ...... FAIL 6 mismatches, 2 imprecisions
mismatch 1/6 the audit stage's own stated counting command does
not reproduce the audit stage's own number: six of
the matched lines were prose about the decorator,
not the decorator itself
note the page's story survives verification. The
interesting facts are real and reproduced. The
arithmetic is not, so the page does not ship.Decisions
Chose an independent verify stage that re-runs the commands over accepting the fixing stage's report, because a stage can produce a plausible artifact and state a number it never measured — the verifier runs in a fresh context, is handed only the evidence file and the built page, never sees the earlier stages' reasoning, and its gate to advance is zero mismatches and zero unverified claims; the first case study of the week came back FAIL with six of them.
Chose per-stage write scopes and tool-call caps over instructions asking a unit to be careful, because a limit written in prose is advice and a limit written into the stage definition is arithmetic — the fix stage writes only into a clean-room worktree and its gate to advance is mechanical rather than declarative: the source tree's
git status --porcelainunchanged, plus a modification-time sweep over the source since stage start that returns empty.Chose a machine denylist at the publication boundary over the written identity policy alone, because the policy depends on every seat remembering it while the gate catches the forgetting — the written policy stayed and became 43 patterns across 5 categories run as one of 7 checks, and the gate was itself tested with a seeded-leak fixture before it was trusted, which is how two defects in the gate were caught and re-verified after fixing.
Evidence
Research artifact · evidence ledger
| Claim | How it was checked | Status |
|---|---|---|
| The roster is 8 charter files covering 7 distinct seats, with 1 retired role kept in the archive — one role carries two profiles, which is why 8 files map to 7 seats. Together they run to 1,231 lines and 134,477 bytes, and every data-office seat carries an identical section headed "Closing a task (MANDATORY, tool-enforced)". | ls -1 <roster>/*.md | wc -l → 8 ; grep -h '^name:' <roster>/*.md | grep -v '{{' | sort -u | wc -l → 8 declared names, two of which name the same role (a full role card and a lighter orchestrator card) → 7 distinct seats ; ls -1 <roster>/_archive/ → 1 retired role, date in the filename ; cat <roster>/*.md | wc -lc → 1231 134477 ; grep -nE '^#{1,3} ' over the data-office charters → the same spine in each | published |
| Written doctrine is 16 operating rules held in the operating memory, inside an index of 37 entries — 16 rules, 14 project-state records, 6 references and the standing brief. Three of the sixteen have mechanical enforcement; the rest are conventions that depend on being read at session start. | ls -1 <memory>/feedback_*.md | wc -l → 16 ; ls -1 <memory>/reference_*.md | wc -l → 6 ; ls -1 <memory>/project_*.md | wc -l → 14 ; grep -cE '^- \[' <memory>/index → 37 | published |
| The publish pipeline is 6 stages, each with one writable root, and a hard tool-call cap on the five worker stages — audit 40, fix 60, secure 15, package 40, verify 50 — for 205 calls allocated per project before the work starts, under an execution plan carrying 9 non-negotiable guardrails and a stop rule that freezes a project after two consecutive verify failures. | sed -n '/Per-project pipeline/,/Stop rule/p' <plan> → the six stages with scope, cap and gate ; grep -cE '^[0-9]+\. ' over the guardrails section → 9 | published |
| The written identity policy runs to 8 sections and defines the forbidden identifier classes; the gate turns it into machine work — 43 denylist patterns across 5 categories (11 topology, 5 identity, 16 content-legal, 6 disclosure, 5 tone), run as one of 7 checks that must all exit 0 before anything leaves the clean-room. | grep -cE '^## ' <policy> → 8 ; grep -oE 'def check_[a-z_]+' <the gate program> | sort -u | wc -l → 7 ; AST count over every pattern list in the gate's pattern module → 11 / 5 / 16 / 6 / 5 = 43 | published |
| The gate was tested before it was trusted: a fixture seeded with deliberate leaks returned 0 pass / 6 fail against the six checks the gate carried that morning, with every seeded item named by category, and a clean fixture returned 6 pass / 0 fail, exit 0. The self-test also re-verified the fix for 2 defects in the gate itself — a silent skip when one scanner was absent, and a skip-not-fail mode — one turned into a hard failure and one forced to run rather than skip, both re-verified. | grep -nE 'RESULT: (PASS|FAIL)' <the gate self-test record> → dirty fixture FAIL 0/6 ; clean fixture PASS 6/0 ; sections 3 and 4 record the two gate defects and their re-verification, section 5 the path that still warns rather than fails | published |
| The verifier failed its own author. On the first case study of the publish week it returned a verdict of FAIL — 6 claim-level mismatches and 2 imprecisions, including a handler count that appeared four times in published copy and was wrong by three, and the finding that the audit stage's own stated counting command did not reproduce the audit stage's own number. | sed -n '1,40p' <the verifier's verdict record> → VERDICT: FAIL ; build PASS ; gate FAIL 4/2 ; identity PASS ; style PASS ; claim-by-claim FAIL — 6 mismatches, 2 imprecisions | published |
| The same standard is applied to the estate's own published packages rather than reporting a clean sheet: the day's end-to-end harness reads 15 pass / 1 fail, and three of those rows are fresh installs of the published releases, each installed from the index and then run — those three pass; the one failure is the harness's check that the version the published site states for one package matches the index, because the live site predates this run, and it is published as it stands. | the end-to-end harness record for 2026-08-23, run of 18:59 → 15 pass / 1 fail, its three fresh-install rows passing against the published releases; the harness keeps one record per date and overwrites it, so the figure quoted is that date's record as it stands, at the timestamp its own header carries | published |
| The recon that produced this week's plan ran as 10 parallel read-only investigations — 7 audit seats plus 3 planning lenses — feeding one orchestrator. | the plan's verified-facts section names the 7 read-only audit seats and the 3 planning lenses | published |
12 claims tested · 8 published · 4 withdrawn before publication. Full evidence record available on request — king.hippopotamus@yahoo.com.
Limitations
This is not a running autonomous organisation, and nothing here claims one. The roster is charter files loaded per session: no scheduler runs a seat, no seat is a daemon, and nothing on the host establishes that two seats ever ran concurrently under their charters. What is shown is that the roles, authorities, escalation paths and write scopes are written down, referenced, and in three places mechanically enforced.
The design is built to stop, not to proceed. Deletion, host change, new exposure, credentials and spend are all human-required by charter, and this week's plan allocates the human exactly one action per day. That is deliberate, and it is also a ceiling on how much of this can be described as automated.
The 16 doctrine rules are written and only partially mechanised. Three carry mechanical enforcement — size-checked gate conditions, the publish gate, the identity denylist. The rest are conventions that depend on being read. Nor are all sixteen incident-derived: most name the run that produced them, but at least two are standing practice rather than a post-mortem — a dated changelog entry at the end of every session, and the expectation that a unit brings its own domain expertise instead of restating the brief.
There is no measured cost and no claim that every published page is verified. The plan declares a token envelope per project and per week, and an envelope is a plan rather than a measurement — no per-run cost or token figure was ever measured. The pipeline's own first verdict was FAIL, so the correct claim is narrower: unverified claims are blocked from publication, shown by that verdict.
Links
No demo — the charters, the pipeline and the gate run inside a private operating environment, so there is nothing to open. The commands that produced every figure are published instead, on the record page.
Authorship
I am the architect and author of record; drafts were produced by agent tooling under my protocol and every sentence was approved by me before publication.
Author approval — 2026-08-23, hash 4ff473a2