This is the repository where I learned AI. Not learned about AI — learned how it actually behaves when you put it in charge of real work. The first one I built with agents, the one where I watched an agent plan a change, write it, and then quietly get the same thing wrong for the fourth time. Everything I know about agentic AI, I learned by breaking it here.

And it grew. By the time I looked at it properly, it carried 136 agent role files, 191 skill files, a governance matrix, a rules layer, a policies layer, coding standards, and a CLAUDE.md that had become a changelog. A lot of it was unused. A lot of it was not optimal. Some of it was pure template — 240-byte files with a domain name substituted in.

None of that was visible from inside the repository. The bloat was the context. Every session loaded it, every agent inherited it, and the difference between a carefully written role prompt and a placeholder nobody had noticed was not something I could feel while working in it.

So I did what I had already done once for this website: I asked someone who could not see any of my context to read it.

The method, applied one level up

Google open-sourced the Elephant-Goldfish Model in October 2026, and I had already written a note about it when I used it to review a design document for my own site. The idea in one paragraph: the agent that holds the project context drafts the specification, and separate reviewers with no memory of that conversation read the specification alone and attack it. The context that produced the plan is the context that cannot see the plan's blind spots.

Applied to a design document, that catches a bad assumption in a migration. Applied to the roster itself — the instructions every agent in the workspace reads before it does anything — it asks a different question: are these instructions real?

The plugin only installs for Claude Code, Codex and Antigravity, and this session was running something else. So I built the thing EGM actually is, by hand. Four fresh-context reviewers with no transcript, each with one lens, each pointed at a single file. One had to restate my design in its own words before finding anything, because a reviewer who cannot paraphrase a section has not understood it. One checked structure and arithmetic. One was the skeptic asking whether the smallest change that removes the defect had been found. One was the tech lead applying the zero-decision rule: if you would have to stop and ask "which one did they mean?", the document is not ready.

Isolation was the part I had to work for. EGM leans on a Claude Code frontmatter flag that keeps the author's project memory out of the reviewer's context. My harness had no such flag. So I planted a marker line in the workspace memory file, told the reviewers to read only the design, and afterwards checked that the marker appeared in none of the four reports. It did not.

That proves the instruction held. It does not prove a tooling guarantee, because there was no tooling to guarantee one. I will come back to this, because it turned out to be the most important thing in the whole run.

Three ways my plan was wrong

The headline finding was arithmetic, and three reviewers found it independently. My plan named a target of 109 agent files. The change list in the same document derived 113. The prose in between said 111. Three different numbers, three different retirement plans, and the difference was whether I removed 12 roles, 14, or all 16. A plan whose acceptance metric cannot be computed cannot be signed off — and the article I was about to write would have published those numbers.

The second finding was bigger, and it came from the skeptic. My plan was a rewrite dressed as a cleanup. Deleting twelve to sixteen role files means editing five surfaces per file — the role itself, the router that dispatches to it, the governance matrix, the hard-coded list inside the validator, and the prose in the entry-point documents that every CLI reads. That is forty-five to seventy edit points, for a problem a three-line body per file solves. Worse, deleting a role forces its replacement to become a multi-domain catch-all, or forces the replacement's own description to stop mentioning the scope it just absorbed. Either way I would have manufactured the exact failure I was removing: a router that cannot tell two roles apart.

So the review changed the plan. Sixteen templated roles kept their names and their routing descriptions, and their bodies were rewritten into real ones — scope, the skills they own, an explicit boundary naming the specialist that actually does the work, and what they hand back. Sixteen content-free skills kept their names too, and each got a real checklist sourced from a policy document that already existed, with a line naming its source. The metric did not move: roles sharing a boilerplate body went from sixteen to zero, and so did skills with no content in them.

The third finding was the one I could not delegate. Two of my factual claims were about the repository itself, and the reviewers were protocol-bound to the document — they could not check them. I checked them myself, and both were false. I had written that one skill did not exist; it did, owned by a sub-application, three lines above my own claim in the very matrix I was criticising. I had also written that two skills queried the wrong search collection while the other seventy-four used a different one; the real distribution across sixty-six skills was forty, twenty-five and one, and the split did not track what those skills actually query. Forcing one value would have been a guess wearing a fix's clothes.

Both claims are now corrected. The second one became a recorded inconsistency with a follow-up, instead of a change.

What the change actually did

One branch, and the numbers came out of a validator rather than out of my head.

Role files in the workspace root went from 125 to 123, because two documents that had never been roles moved out of the agents directory into the docs tree, where they could finally be read as documents. Skill files went from 187 to 186: one was added for an orphan test script that had a working implementation and no SKILL.md, and two pairs were merged — two query skills that hit the same six endpoints on two different hosts, and two publishing skills that differed only in the output format. All 187 skills now carry a name and a description that says when to use them. All sixteen boilerplate role bodies and all sixteen content-free skills were rewritten. And every one of the 136 rows in the governance matrix now resolves: every role exactly once, every skill reference to a file that exists.

The gate that had to earn its trust

A validator that has never failed is not a validator. So before I trusted the new checks, I ran them against the matrix as it had been before the change. They reported fifty-two errors: both dangling skill references, both malformed rows, one duplicated row, and forty-one roles that had no row at all.

That is the number I would have published if nobody had asked a zero-context reviewer to read my plan. The governance file was not a small inaccuracy. It was a file that had stopped describing the system, and nothing in the repository was looking.

Now the validation checks the matrix rows — three columns, every role exactly once, every skill reference resolvable — and checks that every skill carries frontmatter with a name and a non-empty description. The rule that keeps the two mirrored rule trees in step was already there; that one was worth keeping.

What I did not change

Seventy-six schema-query skills look like duplicates and are not. They share a template, each carries its own Cypher against the schema graph, and none of them is an orphan — every one is reached by a domain navigator role. Merging them would have traded a routing contract for token savings. The fifteen navigators also keep their static table snapshots, even though the skills are the richer front end, because demoting them changes a product-facing contract, and that is a different piece of work with a different risk.

I also left the content of those seventy-six skills alone except for two duplicate queries that were proven, and I left the third search-collection question open rather than guessing. Both are recorded as deliberate non-changes, which is what stops the next reviewer from re-opening them.

The method now lives in the repository

The point of running EGM on the roster was not the cleanup. It was that the next change should not need me to remember to ask for a second opinion. So the method is now part of the workspace itself, not a thing I did once.

A feature-sized change now starts with a design document instead of a code edit, and a zero-context reviewer reads that document before anything is implemented — checked against every rule in the repository's rule set, with the security reviewer added whenever the change touches authentication, credentials, patient data or a new external system. The reviewer gets the document path and nothing else. The reports are saved, the findings are triaged one by one, and each fix is applied to the design rather than to the code.

There are two reviewer roles rather than one, on purpose. The general reviewer works against the rule set; the security reviewer works against the credential and data-handling rules, on a different severity scale, because a security finding and a wording finding should never compete for the same label. Neither is optional on a hospital system.

Caveats

The isolation is instruction, not tooling. The marker probe proved the reviewers did not read my project memory. It would not have caught a reviewer who read a file I had not thought to mark. Under Claude Code, that is a property of the runtime. Everywhere else, it is a promise.

A reviewer cannot check the repository. Two of my factual claims were false and survived four reviewers. Whatever independence a fresh context buys you, it does not buy you access to the truth about the code.

The reviewers are noisy. They graded the same finding as a Blocker in one report and a Major in another, and one of them told me the entire plan was too big — which was right, and which I would not have decided on my own. Roughly a third of what comes back needs triage rather than action.

It costs tokens and time. Four fresh-context reviewers, each reading a document end to end, is not cheap. It is worth it when the document decides what 136 agents do for a hospital system, and not worth it for a one-line fix.

Sources