Inside my multi-agent design operation

The thing I actually built is not the code. It is the way the code gets built, attacked, and verified when the workforce is a set of AI agents that will happily manufacture confidence.

The model has four moving parts and one rule. The orchestrator, which I direct, plans the work and verifies the result. Delegates build in parallel, each against a frozen contract written before any of them starts. Adversarial challengers, running different models than the builders, attack the finished work: the source code, the running server as a black box, and the documentation. A fixer answers every finding in writing, fixing or rejecting each one with a reason. The rule underneath all of it: nothing merges on an agent's word alone. Every line is written by one agent and attacked by a different one, and the orchestrator re-verifies the fixer independently rather than taking its word.

That is the discipline I care about. AI makes it cheap to produce work and cheap to sound sure. The only thing that keeps speed honest is making every claim survive an attack from something that did not write it.

On 2026-08-04 I ran this model end to end to build ds-canon, a small MCP server that serves a design system as a queryable source of truth. I let the numbers below stand as the case study because every one of them is traceable to the public repo and its timestamped factory log. Nothing here is reconstructed after the fact.

It answered all 28 findings individually, each marked FIXED, REJECTED, or DEFERRED with its reasoning, and grew the test suite from 33 to 78 tests in the process. The same attacker also certified the three README demo paths flawless, in writing. Under 48 minutes of wall clock ran from git init to a deployed public GitHub repo, and the package was published to npm the same day. A human team does not hit that number, and the interesting part is not the speed. It is that the speed arrived with more scrutiny, not less.

The reason a challenger produces a real BLOCKER instead of a compliment is that I write the charter before I let one agent review another agent's work. It fixes the stance, the severity language, the evidence a finding has to carry, and the reply the fixer owes in return. This is the spec, paraphrased from the one that ran on 2026-08-04.

CHALLENGER CHARTER

STANCE      Adversarial. You did not write this code.
            Your job is to break it, not to praise it.

SEVERITY    BLOCKER  ship-stopper: crash, freeze, data loss, security
            MAJOR    fix before a hiring engineer sees it
            MINOR    a real defect, not urgent
            NIT      polish

EVIDENCE    Every finding carries, or it does not count:
            - file:line
            - a concrete failure scenario (inputs to wrong output)
            - the fix you would make

VERDICT     A written FIX FIRST list. Nothing merges on it alone.

FIXER REPLY  Every finding answered in writing, exactly one of:
            FIXED     what changed, where, and the new test
            REJECTED  why it is not a defect
            DEFERRED  why, and what it is traded against

This run is one visible instance of how I work every day. The same operating model sits behind the rest of my practice, generically: a persistent memory vault so context survives across sessions, session logs so every decision has a trail, verification loops whose whole job is to catch fabrication before it reaches anyone, and a delegation economics where the cheapest capable model wins the task and the expensive one is spent only on planning, judgment, and synthesis.

The verification loops are the part I trust least by default and lean on most. In separate work the same discipline caught a fabricated quote and pulled it before an executive-bound export. That is the point of all of it. The agents are cheap and fast; the scrutiny is the deliverable.

Memory and logs

A persistent vault carries context between sessions, and append-only logs keep a trail of what was decided and why, so a run can be audited later rather than reconstructed from memory.

Verification over trust

Independent checks re-run the work rather than believing the agent that produced it. Fabrications get caught here, before they ship, because catching them is the loop's only job.

A real finding and its written disposition, excerpted from the factory run. Both documents are committed unedited in the public repo.

Everything above is verifiable because the run left a public trail. The code is on GitHub and on npm, and the factory log, the two challenger reports, and the fixer's line-by-line dispositions are committed inside the repo, unedited. You do not have to take my account of it. You can read the working artifacts of the agents challenging each other, and you can install the result yourself.

• Source and factory log: github.com/jtrainer357/ds-canon, with the run documented in factory/.
• Published package: npmjs.com/package/ds-canon, installable in about a minute.