Why a Second AI Agent Should Review the First One's Plan

AI is genuinely good at writing a plan. Give it a feature and it will hand you steps, files to touch, and an order to do them in, fast.

It is also bad at one specific thing: noticing what its own plan forgot.

That is not a knock on the tools. It is how they work. A plan gets generated in one pass, holding a lot of context at once, and by the time it reaches the end it has quietly dropped some of what it was told to care about at the start. Reusability. Security. The patterns your repo already established. The plan looks complete because it is internally consistent, not because it is actually thorough.

The fix I landed on is simple: have a second agent review the first agent's plan before anyone writes code. Different instance, fresh context, one job, find what the first plan missed. It has become one of the highest-leverage things in my workflow, and it is worth explaining why it works, because the reasoning generalizes well beyond AI.

The obvious objection, and why it is wrong

When I describe this, the first reaction is always the same: "Why not just tell the first agent to consider reusability and security? Why add a second one?"

The answer is that the first agent is told. The instructions are right there. The problem is not that it lacks the instruction; it is that it loses the thread.

Think about what the planning agent is doing. It is holding the feature request, the constraints, the repo conventions, the security considerations, and the actual step-by-step plan all at once, and generating forward. The further it gets, the more its attention is on finishing the plan it has started building. The early instructions about reusability are still technically in context, but they are competing with everything else, and they lose. By the last few steps, it is pattern-matching its way to "done," not auditing its own work against the goals you set at the top.

A second agent does not have that problem, because it is not invested in the plan. It did not write it. It comes in cold, with one instruction: here is a plan, here are the things that matter, what is missing? Fresh context, no momentum to protect, no sunk cost in the approach. It reads the plan the way a good reviewer reads a pull request, looking for the gap, not admiring the work.

This is the same reason we do code review with humans. The author is the worst person to catch their own blind spot, not because they are careless, but because they already convinced themselves. A reviewer who did not write it sees it clean. The AI version is the same principle, applied a step earlier, at the plan stage, before any code exists to throw away.

What the second agent actually catches

In practice, the review agent tends to find two kinds of things.

The first is small discrepancies that quietly raise code quality. A plan that solves a problem in a one-off way when the repo already has a shared utility for it. A step that adds state without saying where it lives. A flow that handles the happy path and never mentions what happens when the request fails. None of these would block the feature from shipping. All of them are the kind of thing that, multiplied across a year of features, is the difference between a codebase that stays clean and one that rots.

The second kind is more interesting: improvements nobody asked for, including things the product owner or QA team had not thought of.

A concrete example. I had a plan for a simple search feature. Search a list, show results, done. The first agent's plan was fine, correct, complete, would have worked. The review agent looked at it and suggested building the search with a save-item capability, so that as a user searches across multiple lists repeatedly, those saved items make future queries faster and more useful. That was not in the ticket. It was not in my plan. It was a genuinely better version of the feature that came out of an agent whose only job was to ask "what is this plan not considering?"

That is the part that surprised me. I expected the review pass to be a safety net, catching mistakes. It is also, sometimes, a product thinker, surfacing the better version of the thing before it is built and expensive to change.

Why "before code" is the whole point

The timing matters more than anything else here.

You can catch a missing security consideration in code review. You can catch it in QA. You can catch it in production, painfully. But every one of those is more expensive than catching it in the plan, because by then the wrong approach is built, and building the right one means throwing work away.

A plan is the cheapest possible artifact to fix. It is words. Changing a plan costs a sentence. Changing the code that implemented the wrong plan costs a rewrite, plus the review, plus the QA, plus whatever depended on it. Putting the review at the plan stage means the discrepancy gets fixed when fixing it is nearly free.

This is the same logic behind every "shift left" idea in software: the earlier you catch a problem, the less it costs. A plan-review agent just shifts it further left than most teams ever bother to, to before the first line of code.

The judgment is in the design, not the tool

I want to be clear about where the actual value is, because it is easy to hear "I use two agents instead of one" and think the trick is the second agent.

It is not. The trick is understanding why one over-loaded agent underperforms two focused ones, and designing the workflow around that. Anyone can spin up a second agent. Knowing that the planning agent loses its early constraints under its own momentum, and that an uninvested reviewer with fresh context is structurally better at finding the gap, is the part that makes it work. Get that wrong and you just have two agents producing twice the confident, incomplete output.

That is true of most good AI tooling. The leverage is rarely in the tool itself. It is in knowing the failure mode well enough to build around it. A second agent reviewing the first one's plan is a small thing to set up and a large thing to get right, and the difference is entirely in understanding what you are actually compensating for.