Before code written by an agent ships, the following have to be true: the test suite passes, lint and type checks pass, the diff is the size and scope the plan asked for, the project builds, a security scan reports nothing new, and a human has read the diff and approved it. Each of these is a verification gate: a check that must pass before the work moves to the next stage. One more gate runs before any code exists: human approval of the plan. It saves the most money, because a rejected plan costs nothing to execute. This article defines gates, lists the ones that matter for agent output, and describes how Ivy Tendril runs them.

What a gate is

A gate is a condition attached to a stage transition. Work in stage N cannot enter stage N+1 until the condition holds. The condition has to be evaluated the same way every time, and the result has to be recorded so someone can look at it later.

Three properties separate a gate from a suggestion:

It blocks. A failing gate stops the transition. A check whose failure is advisory is a report, not a gate.
It is automatic or explicit. Either a program evaluates it (tests, lint, build) or a named person makes a recorded decision (review). "Someone probably looked at it" is neither.
It has a defined failure path. When the gate fails, the work goes somewhere specific: back to the agent, back to the plan, or to a human. Work that fails a gate and sits nowhere is the most common way agent output gets lost.

Human-written code goes through gates too: CI and pull request review. The difference with agent output is volume. When one developer can open twenty pull requests a day, review is the slowest step, and the gates before review have to remove as much as possible before a person reads the diff. Agent orchestration patterns covers how verification fits with queueing, isolation, and cost.

The gates that matter for agent output

Gate	What it checks	What a failure usually means
Plan approval	A human has read the plan and agreed with the approach and scope	The task was underspecified or the approach is wrong
Tests	Existing tests pass; new behavior has tests	The agent broke something or did not cover its change
Lint and type check	Code matches the project's rules and compiles	Rule violations, unused code, type errors introduced while making tests pass
Diff size and scope	Files changed match the plan; the diff is reviewable	The agent changed files outside the plan or refactored unrelated code
Build	The full project builds from the branch	Something works in isolation but not when assembled
Security scan	No new secrets, vulnerable dependencies, or flagged patterns	The agent added a credential, a dependency, or an unsafe call
Diff approval	A human has read the diff and approved it	Anything the automated gates cannot judge: intent, naming, product fit

The first six run before a human is involved; the plan gate runs before execution and the rest run inside the agent's worktree after it. Two deserve comment.

Diff size and scope is the gate teams most often skip, and it matters more for agents than for people. An agent asked to fix a null check will sometimes also reformat the file, rename a variable, and update three call sites. Together those turn a 10-line review into a 300-line one. A scope gate compares the files and modules touched against the plan and reports the difference.

Security scan covers secrets, dependency vulnerabilities, and pattern rules. Agents copy patterns from the surrounding code, so a repository with one unsafe pattern tends to acquire more.

Why the plan checkpoint prevents wasted execution

All the gates after execution share a property: by the time they fail, tokens have been spent. Tests, lint, build, and scan tell you the execution went wrong. Only the plan gate tells you before it goes wrong.

Look at what the later gates catch. A test failure because the agent misunderstood the requirement is a plan problem. A scope failure because the agent touched modules the task did not mention is a plan problem. A build failure because the plan asked for a change in one package without accounting for its dependents is a plan problem. In each case, a reviewer reading a written plan for two minutes would have caught it, at zero execution cost.

This is why the software factory workflow, Ivy's name for a repeatable plan, execute, verify, review sequence, has exactly two human checkpoints and puts one of them before any code exists. The plan checkpoint is where scope, approach, and sequencing are decided. The diff checkpoint is where correctness is confirmed. Everything between them is automatic.

How Ivy Tendril runs verification gates

Ivy Tendril is a local-first desktop application (macOS, Windows, Linux) that takes a task from plan to reviewed pull request. The two human checkpoints and the automatic gates between them are built into its lifecycle. See the Review app docs for the surface.

Plan gate. A plan starts as a draft. A human reads it and can Expand, Split, or Update it, or comment inline on the draft and have the plan rewritten. Execution does not start until the plan is approved.
Execution in isolation. Each plan executes in its own git worktree on its own branch, so verification runs against exactly that plan's changes and nothing else.
Verification tabs. After execution, the Review app shows tests, lint, and diff as separate tabs, so the reviewer sees all three before deciding.
CI import on Pro. Teams whose gates run in CI (build, security scan, integration tests) can import those results into the Review app on the Pro plan, so the reviewer does not have to open a second tool.
Failure path. When a verification fails, the work goes back to the agent with the failing output attached. The agent gets the actual test or lint output, not a summary, and reruns in the same worktree. The Jobs surface streams the agent's output and tool calls while it does.
Diff gate. Only after verification passes and a human approves the diff does Tendril open a pull request. Nothing ships without both sign-offs.

Cost is tracked per plan and per job, so a plan that failed verification three times before passing shows what the retries cost, which is the data for deciding whether the plan gate should have been stricter.

How to start

Write down your current gates. Most teams find they have tests and review, and that lint runs somewhere but nobody knows whether it blocks.
Install Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) or irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). See installation.
Run one plan through the lifecycle and read the tests and lint tabs before you read the diff. Note what you would have missed reading the diff alone.
Add a scope check to your plan review: does the list of files the agent may touch match the plan?

Tendril is free and source-available under the Functional Source License. CI verification import, team features, on-prem hosting, and SSO are on the Pro and Enterprise plans.

Frequently asked questions

Should verification gates block automatically or only inform the reviewer?

Tests, lint, type checks, and build should block; a reviewer should not spend time on a diff that does not compile. Scope and security findings should be shown to the reviewer with the option to accept, because both are sometimes correct to override.

How many retries should an agent get when verification fails?

Set a limit and record it. Repeated verification failure is usually a plan problem, not an execution problem; send the plan back to the plan stage rather than pay for a fifth attempt. Per-job cost tracking makes the retry cost visible.

Does human review of the diff still matter if all automatic gates pass?

Yes. Automatic gates check what can be specified in advance. They do not check whether the change does what the ticket meant, whether the approach will be maintainable, or whether the plan itself was right. That is why the diff checkpoint is one of the two mandatory human gates.

Verification gates: what has to be true before agent code ships