Why Agents Need Gates

The most instructive agent failure I know is the one where nothing goes wrong for forty minutes. You hand an agent a paragraph of instructions and a repository, it works — competently, confidently, without a single question — and when you return, it has built a beautifully engineered version of something you did not ask for. Every individual decision it made was defensible. The sum of them drifted, one plausible inference at a time, away from what you meant. Nothing errored. Nothing warned. The run was unstructured, and unstructured is exactly how agents fail now: not loudly at minute two, but quietly at minute forty.

The conversation was the safety net

That failure mode is new, and it is worth being precise about why. In the conversational era, the human was present for every step: you caught mistakes as they happened, supplied missing context the moment the model asked, and course-corrected drift within a message or two. The conversation itself was the quality process — informal, unwritten, and completely effective at short range.

Then the range stopped being short. Anthropic's agent-autonomy research found that the 99.9th-percentile turn duration in Claude Code nearly doubled between October 2025 and January 2026, from under 25 minutes to over 45 minutes — a tail-of-the-distribution figure, note, while the median turn stayed around 45 seconds. But it is the tail that tells you where the practice is going: the longest unattended stretches of agent work are growing fast, and every minute added to them is a minute in which nobody is catching mistakes, supplying context or correcting drift. Everything you once relied on the conversation to do must now be encoded before the agent starts, because the moment where you would have said “no, not like that” no longer exists.

Encoded how? Around the same time this pressure was building, the industry converged on part of the answer: write the requirements down first. Thoughtworks named spec-driven development one of 2025's key new AI-assisted engineering practices. But a spec on its own is a document, not a process. It does not tell you when the human looks at the plan, what they are looking for, when the agent may proceed, or how anyone finds out whether what was built matches what was written. For that you need structure with checkpoints in it — which brings me to the workflow this series is about.

Five phases, four gates

PREVC is the five-phase workflow I run agent work through: Planning, Review, Execution, Validation, Confirmation. The design rests on one core insight — agents produce dramatically better output when they work against structured specifications with human oversight at defined gates, rather than receiving instructions ad hoc and running open-loop.

Briefly, since each phase gets its own part of this series:

• Planning — every requirement, specification and constraint is gathered into the agent's context, and the agent produces a hierarchical breakdown of the work, together with an honest grading of its own plan.
• Review — the human arrives, and applies the judgement the agent cannot: sharpening ambiguous items, surfacing what is missing, splitting what is entangled, and encoding intent — which trade-offs win, what gets escalated.
• Execution — the agent implements the refined breakdown, not in one heroic pass but through a tight inner loop with explicit exit conditions.
• Validation — what was built is traced back against what Review approved, item by item, so gaps and drift are found by comparison rather than by luck.
• Confirmation — the cycle examines itself: a retrospective on where the process leaked, and a release step that documents what this work now imposes on the next.

The phases matter, but the gates between them matter more — they are where the checking that used to live in the conversation now lives instead. The gate between Planning and Review is where the agent's self-assessment directs human attention. The gate between Review and Execution is the moment the plan becomes a contract. The gate after Validation is where “it seems done” is replaced by “it demonstrably matches the spec”. A gate is simply a point where the work cannot proceed on the agent's own say-so — and that one property is what separates a directed run from the forty-minute drift I opened with.

A borrowed skeleton, credited

Before this series goes any further, the provenance, stated plainly — because this is a part-one obligation, not a footnote. The PREVC structure is not mine from scratch. The five phases — Planning, Review, Execution, Validation, Confirmation — and the scale-adaptive routing you will meet in a moment come from dotcontext (formerly ai-coders-context), an MIT-licensed open-source agent-harness framework by Vinicius Lana of AI Coders Academy. The project has since evolved — the phases have even been renamed upstream — but the skeleton I adapted is theirs, and credit belongs where the idea started.

What this series adds is my adaptation of that skeleton into a working practice: the plan-readiness metrics, the Code-Review-Simplify loop, the breakout constraints, the hallucination taxonomy and the methodology mappings are my extensions, and their faults are mine. That is also the register for everything that follows — creator voice for the extensions, credited inheritance for the frame — and part 10 will settle the ledger between the two honestly.

Not every task earns five phases

The most practical thing the skeleton got right is that the workflow bends to the size of the work. Running a five-phase ceremony on a one-line fix is how process dies; the routing is scale-adaptive:

Two things about this table repay attention. First, Validation is the phase that never gets dropped — even a QUICK change gets checked against what it was supposed to do, because “too small to verify” is how small changes cause large incidents. Second, the phase that arrives with scale is Review: the moment work is big enough to have a real plan, the human's judgement enters before execution, not after. Confirmation, the most expensive phase, is reserved for work that will impose constraints on everything built after it.

The routing decision itself takes seconds — is this a tweak, a feature, or a product? — and making it explicitly is half its value. Most process failures I have watched were not the wrong process; they were MEDIUM work being waved through on a QUICK ticket.

Where the series goes

Ten parts, one per load-bearing idea:

1. Why Agents Need Gates — this post: the case for structure, and the credit for the skeleton.
2. A Plan You Can Grade — Planning, the agent-generated work breakdown, and the three scores that direct human attention.
3. Review Is the Most Important Handoff — the human's phase: raising clarity and completion, minimising complexity, encoding intent.
4. The Code-Review-Simplify Loop — Execution's inner loop, and why the Simplify step exists.
5. Four Ways Out of an Infinite Loop — the breakout constraints that give the loop an exit.
6. The Mistakes That Compile — the hallucination patterns the Review step is armed against.
7. Every Requirement Gets a Receipt — Validation, gap analysis and requirements traceability.
8. Confirmation Closes the Circle — the retrospective, the release, and why the workflow is circular.
9. PREVC Against the Methodologies — where it sits beside PDCA, Scrum, waterfall and spec-driven development.
10. An Honest Ledger for a Borrowed Skeleton — the retrospective on the workflow itself: what held, what is untested, and what I would change.

If you have ever come back to an agent run and found forty minutes of confident, competent work aimed at the wrong target — or if your team's answer to “how do we use agents” is currently a shared folder of prompts and a shrug — the next nine parts are for you.