We didn’t build a smart AI agent.
We built four layers that can’t trust each other.
That’s what makes it work.
When you hit your first agent reliability problem, the obvious answer is more context. Give the agents better information: what was done before, what decisions were made, what the others found. Coordination means shared knowledge. More shared knowledge means fewer mistakes.
That’s true for most tasks. For a review sequence, it’s the wrong trade.
I know it’s the wrong trade because I built the other version first.
The first architecture had a dedicated Code Reviewer agent. A peer to the Developer: one writes, one reviews, clean separation of duties. It’s how the org chart looks on paper, and it’s the design most people reach for.
It didn’t last long.
The reviewer shared context with the work it was reviewing. And a reviewer that already knows what the developer intended is not reviewing the code. It’s confirming a story it was told. The review came back agreeable, thorough, and structurally unable to disagree. Every finding traced back to something the Developer had already flagged itself.
So the review moved up a level, to the Manager that was orchestrating the batch. Which, on reflection, is where it sits on every engineering team I’ve worked on. The lead or the manager owns code review. Not because they’re a better engineer than the person who wrote it. Because they’re the one accountable for what ships, and their read isn’t anchored to the reasoning that produced it.
The fix wasn’t a better reviewer. It was a reviewer standing somewhere else.
The Manager reads artifacts, not reports.
That distinction is the whole design. When the Developer finishes, it produces a review document: a complete account of what was changed, what was validated, what decisions were made. The Manager reads that document and checks the code itself. It never asks the Developer how it went. An agent saying “everything looks good” is not a gate. The reviewed file is.
Here’s what that bought. The Developer ran Batches 6 and 7 with clean context, no memory of prior DAGs, no carryover from run to run. It applied a correct transformation. Inconsistently, across both batches, because its context window didn’t span the work it had already done.
The Manager’s did.
The Manager reviewed Batch 7 independently and flagged the config pattern inconsistency introduced across both runs. One read. One catch. One fix, before any of it left the sandbox.
The agent doing the work could not see the shape of its own output. The layer above it could.
Four layers. Four failure modes. No overlap.
Developer transforms fast, documents everything, doesn’t approve its own work. Its context is the skill document and the current DAG. Nothing from the run before. Blind spot: it can’t see across its own batches.
Manager reads the artifact and reviews the code against the transformation rules. Static analysis: what the code says it does. Doesn’t run it. Blind spot: errors that only appear under execution.
QA doesn’t read the Manager’s review before testing. Runs the output. Imports the DAG. Checks the task graph. What fails at runtime doesn’t care what the review said. Blind spot: it can only judge what runs, not whether the transformation logic was sound.
The human gate sees all of it and none of it in advance. After every DAG the batch stops and waits. Blind spot: attention, and the fact that a person reviewing the twentieth diff is not the person who reviewed the first.
Each layer is designed to be wrong in a way the others can’t be.
What makes the handoffs work without shared context is the artifacts.
The Developer writes the review document. The Manager reads it directly. QA can reference it if something fails, but it doesn’t read it before running the tests. It runs first, then consults the record if something breaks.
The artifacts serve the record. The clean contexts serve the integrity.
Give QA the Developer’s report in advance and the review changes. It starts from “everything looks right” and works backward from approval. The YAML duplicate key, the one that passed two rounds of static analysis, gets caught precisely because QA doesn’t know it was already approved. It runs the command. The parser rejects it. Ninety seconds.
When QA fails, the Manager decides what happens next. Small problems it fixes itself. Larger ones get a Bug-Fix agent spawned with a narrow brief: here is what failed, here is what was already done, change only what’s needed. It never re-migrates the DAG and it never reads the original source. And there’s a ceiling. Three QA runs on one DAG and the batch stops for a human, because an agent looping on the same error is not making progress, it’s producing motion. Across the whole migration that ceiling was never reached. One DAG needed a second iteration. That was the worst of it.
The common instinct when something breaks is to add context. Give agents more information about what each other found. Tighter coordination. Better handoffs.
For a review sequence, the fix runs the other direction.
The independence is what gives each gate real teeth. Any process that validates its own work is a single point of failure. The distrust is the load-bearing wall. Not a design quirk to optimize away, but the mechanism that closes the gap between what code says and what systems do.
Static analysis shows intent. Runtime shows truth. When only one runs, there’s a guaranteed gap. Not in the model. In the structure.
That structure holds for three DAGs. What it looks like across 43, and what the human layer actually produced over that distance, is Episode 3.
One question before then: what does your review process take on trust?
Comment with where it shows up. I read every one.