The reviewer's chair

(This is a story about Agent Fang, a live app — you can open it here.)

The last three editions were about running Agent Fang, a tool I built and put in front of you. This one goes upstream. I'm fine-tuning a private model (teaching a general one the company's own numbers and house style) to write financial commentary in a CFO's voice, without those numbers leaving the building. The first thing it taught me had nothing to do with finance. In under a day I had the opening slice working — figures in, a draft narrative out. I was pleased, the way you're pleased with a demo. Then I went looking for what was wrong, the way sixteen years of this trains you to. I found bugs in the code the agents had written, so I handed it to a different model and asked that one to break it. It found more than I expected. Building that slice took a day. Building the team that checks it took the better part of a week.

The lesson landed in a single line: you cannot trust one agent to produce the work and tell you the work is good.

The obvious fix is to add a reviewer — a human, standing between the work and the world. I know why that fails, because I have been that human. Vigilance decays as trust builds. You cannot trust a person to catch the one bad row in data they just watched go in correctly forty-nine times. The reviewer gets comfortable. An agent reviewer has exactly one edge over that comfortable human: it never gets comfortable. Every review starts cold. There is no "it's been fine all morning." The standard complaint about these models is that they remember nothing. In the one seat where accumulated trust is a liability, that turns out to be the property you want. So why not hand the work to a fresh copy of the same model? Because comfort and blindness are different failures. A blind spot is baked in, and starting fresh doesn't touch it: two instances of the same model were shaped the same way and cannot see past the same things. Ask one to bless what the other wrote and you get a confident stamp on the same mistake. What works is independence built into the structure: a different model where I can get one, told to break the work, kept blind to the reasoning that produced it. Not a better worker in the same chair — a chair the worker isn't allowed to sit in. So I stopped adding reviewers and redrew the org chart: an architect who specs the work, a developer who builds it, a tester who tries to break it.

I'd been running a larger project this way for months, the build behind Agent Fang, so I counted. A hundred and forty-four pieces of work reached a review gate. The independent review layer sent work back fifty-eight times. Thirty-eight distinct items got bounced at least once: more than one in four of everything reviewed. And it didn't spiral. The worst bounced four times; most bounced once and moved on. The catches weren't typos. The one I keep pointing to: a developer turned in its work with its own tests green. "28 passed," it reported, and it was telling the truth. The independent tester agreed and still caught a real design flaw the green checks were blind to. The same three roles are now pointed at the finance build I opened with: when the first real training run failed, the diagnosis, the fix, and the check on the fix each passed through a different agent before any of it reached me.

Let me be straight about what this does and doesn't prove. I've shown the review layer fires — it returns about one item in four and catches real defects. I have not run the other arm: I can't prove a human reviewer would have missed these same things. I think the developer's own "all green" is the tell, and that a busy person nods it through — but that's an argument, not a measurement. I'd rather tell you where my proof stops than pretend it goes further.

The instinct, once a machine produces the work, is to drop it in someone's review queue and move on. In a working paper this July, Emma Wiles and three co-authors gave more than eight hundred managers documents with planted errors, changing only who they were told wrote them. At firms that had already put AI agents on the org chart as employees, work labeled an AI employee's rather than an AI tool's got eighteen percent fewer of its errors caught. In that same subgroup, that work was also reviewed worse overall than a human colleague's. Those managers escalated more and moved the blame to the system. Same lever, opposite result: I redrew the org chart to build the reviewer's independence in; where the chart already carried AI, a label was enough to dissolve it. Which is why this is mostly org design, not code: redrawing who checks what doesn't require building anything. So the question to ask a vendor, or yourself, is whether the reviewer is able to disagree — a different set of eyes, cold, allowed to say no. The presence of a reviewer is theater. Their independence is the thing. In a domain where being wrong is expensive, what does trustworthy output even look like?