Reliable Agents Need Gates: Context, Plan, Review, Verify

The mistake most teams make with coding agents is treating the chat as the workflow.

They open an agent, paste a request, answer questions as they come up, approve edits, ask for fixes, run a few checks, and keep going until the agent says it is done. That can work for small personal tasks. It does not become a reliable engineering system because the model is stronger or the context window is larger.

A long chat is a transcript. It is not an operating model.

The difference matters because agent work fails in predictable ways. The agent reads the wrong files. It skips the product constraint that was obvious to the human. It implements before the scope is stable. It fixes the bug and introduces a smaller bug nearby. It reviews its own work at the same level of abstraction that produced the mistake. It claims tests passed when it only ran the convenient subset.

None of these are solved by asking the agent to "be careful."

They are solved by installing gates.

A reliable agent workflow has four gates:

• Context
• Plan
• Review
• Verify

This is the agent workflow loop. Each gate has a job, a failure mode it catches, and an artifact it leaves behind. The loop is not bureaucracy. It is how teams turn agent usage from improvisation into AI Systems Engineering.

Agent Runtime, Workflow System

Modern agent tools already behave like loops. Claude Code describes the basic loop as gathering context, taking action, and verifying results. Codex best practices emphasize setup, instructions, tests, checks, and review. GitHub Copilot code review adds a second-pass review surface inside the pull request flow.

That is the tool layer. The engineering question is different:

What system do you put around the agent so the loop is repeatable across people, repositories, and tasks?

Geist Labs calls this AI Systems Engineering: turning AI tools, agents, and models into reliable, repeatable, cost-efficient engineering systems. Inside that, Agent Context Architecture is the control plane: repo-native instructions, routing files, stage contracts, references, working artifacts, and verification evidence.

The agent is the runtime. The folder, file, and workflow system is the control plane.

That framing changes the question. Instead of asking, "What prompt should I use?" ask, "What gate is this work in, what context is allowed, what artifact should exist, and what evidence proves it can advance?"

Gate 1: Context

The context gate answers one question:

What does the agent need to know for this task, and what should it ignore?

Most agent failures begin before implementation. The agent reads too little, reads too much, or reads the wrong thing. Too little context produces shallow guesses. Too much context produces drift, token waste, and accidental coupling. Wrong context produces confident work that solves a neighboring problem.

Context is not just "give the agent more files." Context is routing.

For a code change, the context gate might include root agent instructions, the nearest directory context file, the issue, relevant source files, nearby tests, review standards, and one or two examples of the local pattern. It should exclude archived notes, unrelated packages, stale drafts, and broad research unless the task needs them.

The context gate catches these failure modes:

• The agent starts in the wrong directory.
• The agent misses local conventions.
• The agent loads old or irrelevant material.
• The agent treats a one-off instruction as durable policy.
• The agent burns tokens rediscovering structure that should have been routed.
• The agent optimizes for the model's generic training instead of the repository's actual patterns.

The artifact from this gate should be a short context brief that a human can scan in under a minute.

For example:

This brief gives the human a chance to catch a bad route before the agent spends an hour implementing the wrong thing.

For teams, the context gate should not rely on memory. Put routing in the repository. Use `AGENTS.md` for global behavior, `CONTEXT.md` files for directory-level routing, and durable references for standards, architecture, test strategy, and review expectations. The more work the repository can do, the less work every chat has to repeat.

Gate 2: Plan

The plan gate answers: what exactly will change, in what order, and how will we know the plan matches the request?

Agents are fast enough that skipping planning feels productive. That is the trap. The cost of a bad plan has dropped in minutes, but the blast radius has grown because agents can touch more files than a human would touch by hand.

A plan gate does not mean a 20-page spec. It means the agent must stop before editing and produce a concrete execution path.

The plan gate catches these failure modes:

• The agent implements a broader feature than requested.
• The agent chooses an architecture that conflicts with local patterns.
• The agent edits shared utilities when a narrow change would do.
• The agent misses migration, data, permission, or rollout concerns.
• The agent plans tests after implementation instead of using tests to define behavior.
• The agent hides uncertainty inside confident prose.

The artifact from this gate should be a plan that names files, behaviors, tests, risks, and open questions.

A useful plan has five parts:

• Scope: what is included and excluded.
• Files: which files are likely to change and why.
• Steps: the smallest sensible sequence of edits.
• Checks: tests, lint, type checks, screenshots, evals, or manual verification.
• Risks: assumptions, unknowns, and places human judgment is required.

The plan should be specific enough that a reviewer can reject it before code exists.

That is the point.

Planning is cheaper than rollback. If the agent says it will refactor the payment abstraction, add a new provider interface, update six packages, and adjust the frontend when the request was "stop retrying expired cards," the team can catch the scope error at the plan gate.

The plan gate is also where teams preserve speed. Without it, humans correct the agent after files have changed and the conversation has accumulated irrelevant context. With it, humans steer once, early.

The best plan is not the most elaborate plan. It is the smallest plan that makes the next action obvious and the wrong action visible.

Gate 3: Review

The review gate answers:

What is wrong, risky, missing, or misaligned in the work so far?

Review is where many agent workflows become fragile. Teams either skip it because the code "looks fine," or they ask the same agent that wrote the change to bless its own work. Self-review is useful, but it is not enough. The review gate needs a fresh angle of attack.

That can be a human reviewer, a separate agent session, an automated code review tool, a PR review agent, or a review checklist embedded in the repository. The key is that review must be pointed at risks, not vibes.

The review gate catches these failure modes:

• The implementation satisfies the prompt but violates the architecture.
• The agent edits generated, archived, or ownership-sensitive files.
• The tests assert the implementation instead of the intended behavior.
• The change handles the happy path but misses edge cases.
• The agent introduces naming, permission, logging, or observability regressions.
• The diff is larger than the plan justified.
• The code works locally but creates review debt for the team.

The artifact from this gate should be a review report.

It should lead with findings. Each finding should include severity, location, why it matters, and what needs to change. If no issues are found, say that clearly and name the residual risk.

For example:

The review gate should also compare the implementation against the plan. This prevents a common agent pattern: the agent makes a reasonable plan, discovers friction, silently changes direction, and finishes with a diff that no longer matches the approved path.

Good review asks:

• Did the diff stay inside the approved scope?
• Did the code follow local patterns?
• Are the tests meaningful?
• Did the agent touch files it should not own?
• Are there hidden operational effects?
• Is there evidence for any claim the agent makes?

This is where AI code review becomes powerful. Not because a review agent is always right, but because it creates a repeatable second pass. Codex best practices call out review, tests, lint, formatting, type checks, and custom review instructions. GitHub Copilot code review brings a similar idea into pull requests. The systems lesson is broader than any one tool: review behavior should be reusable.

Do not make every engineer invent review standards in chat. Put them in `code_review.md`, link it from `AGENTS.md`, and update it when defects slip through.

Gate 4: Verify

The verify gate answers:

What evidence proves the work is complete?

This gate is where agent workflows often collapse into theater. The agent says "all tests pass" after running one targeted test. It says "verified" when it only type-checked one package. It says "ready" without screenshots, migrations, or integration behavior.

Verification must be concrete.

The verify gate catches these failure modes:

• The agent claims completion without command output.
• The wrong test suite ran.
• The relevant check failed but was summarized away.
• The change works in isolation but fails in the full workflow.
• Visual or product behavior is unverified.
• The final answer hides skipped checks.
• The team accepts agent confidence instead of evidence.

The artifact from this gate should be a verification receipt.

It should include commands run, results, output summaries, skipped checks, and why any skipped check is acceptable. For UI work, include screenshots. For data changes, include migration dry runs. For AI behavior, include eval results.

Example:

This receipt should travel with the work. In a pull request, it can become part of the PR description. In a local task, it can be the final agent response.

The point is simple: the agent is not done when it says it is done. It is done when the stage contract has evidence.

The Loop Is Not Linear

The four gates are often presented as a sequence:

Context, Plan, Review, Verify.

In practice, they form a loop.

Verification can send work back to review. Review can expose missing context. Planning can reveal an open question. A failed test can force a narrower plan. A human review comment can become new context for the next run.

That loop is a feature. It turns failure into source-level improvement.

When the same context mistake happens twice, fix the routing file. When the same review finding appears across PRs, fix the checklist. When agents skip the same verification step, make it part of the stage contract. When every run needs the same pasted instruction, turn it into a skill, command, template, or reference.

This is how teams move from prompt use to operating system.

How To Install The Loop Without Slowing Down Delivery

The usual objection is that gates sound slow.

They are slow if they become meetings. They are fast if they become lightweight artifacts in the normal development path.

Start with four small templates.

• `context-brief.md`
• `implementation-plan.md`
• `review-report.md`
• `verification-receipt.md`

Each template should fit on one screen. The goal is not paperwork. The goal is making the agent externalize the state that otherwise lives invisibly inside the chat.

Next, route them through the repository.

At the root, `AGENTS.md` defines global behavior: read routing first, protect user changes, follow local style, produce evidence. Directory-level `CONTEXT.md` files define what to read. Review standards live in a reference file. Verification commands live near the code or in a workflow guide.

Then make the loop proportional to risk.

For a small doc edit, the gates can be tiny:

• Context: target file and voice guide.
• Plan: one sentence.
• Review: self-review for accuracy and formatting.
• Verify: Markdown lint or manual scan.

For a production change, the gates should be stronger:

• Context: issue, architecture notes, source files, tests, operational constraints.
• Plan: files, behavior, rollout, test strategy, risks.
• Review: fresh agent or human review against a checklist.
• Verify: unit tests, integration tests, type checks, lint, migration checks, screenshots, logs, or evals.

Do not make the loop heavy by default. Make it explicit by default and heavier when risk demands it.

The most important team habit is to reject un-gated completion. If an agent finishes with a summary but no context brief, plan, review result, or verification receipt, the work may be useful, but it is not yet an engineering artifact.

What Good Looks Like

A good agent workflow leaves a trail.

You can see what the agent read, what it skipped, the plan before the diff, review findings before merge, and the checks that prove the outcome. You can trace a failure back to a missing instruction, weak route, vague plan, incomplete review checklist, or insufficient verification command.

That traceability is what separates a useful agent session from a repeatable engineering system.

The future is not better prompts. The future is engineered AI workflows.

The teams that win will not be the teams with the longest chats or the cleverest one-off instructions. They will be the teams that package context, planning, review, and verification into the way work moves through the repository.

Reliable agents need gates because reliable engineering needs gates.

Context routes the work.

Plan bounds the work.

Review challenges the work.

Verify proves the work.

That is the loop.