Feedback Loop

Intent

Give the agent a way to check the result, read the failure, and repeat the work until the criterion is met. The agent runs the check in a session or after deployment, and you receive the result together with the evidence.

Also known as

Give the agent a way to verify its work, verification loop, closed verification cycle.

Problem

Without a check, the agent can stop at plausible code. For example, a validator accepts a valid promo code but gets an expired one wrong.

If there is no test, you have to notice the mistake yourself. Until then the agent considers the task done.

The definition of done should describe observable behavior. Then the agent can tell a written implementation from a verified result.

Solution

Before the start, set a check with a clear outcome. It can be a test, a build, or a comparison of the output with a reference. For a UI, provide a design and the criteria for visual comparison. Ask the agent to run the check after its changes, work through the failures, and repeat the cycle.

The agent makes an edit, runs the check, and fixes the failure it finds. You choose the criteria before the work begins and assess the evidence at the end.

The degree of automation of the loop can be chosen per task.

1. An instruction in the prompt asks the agent to run the checks and fix the failures it finds.
2. A session goal sets a condition the agent returns to after every step.
3. A deterministic gate blocks completion until the required check passes.
4. A second opinion adds a review in a fresh context to check completeness and quality (see Writer and Reviewer).

The evidence has to come from the environment, not from the agent's account. Output the agent reprinted in its final message could just as well be made up: 4 passed written without a run, or taken from a run before the last edit. Check against a record the harness kept: the tool call in the session log, the CI log, the exit code in a hook, a screenshot from the browser tool. This data shows what exactly the agent checked and lets you accept the work without reconstructing the whole session.

Structure

In the diagram, the developer hands over the task and the verification criteria.

The agent repeats the cycle of edits and checks until it succeeds, then returns the evidence. A hook can enforce the exit condition, and an independent review can complement the automated checks.

Participants / Components

• Developer sets the criteria and accepts the result by its evidence.
• Agent changes the code, runs the check, and works through the result.
• Check evaluates the specified property of the result.
• Signal tells the agent whether the criterion is met.
• Evidence preserves the command, the output, or an image of the verified state. It is recorded by the environment, not by the agent.

When to use

• The result can be checked in a reproducible way.
• The agent has to run several iterations without constant supervision.
• A UI can be compared with a design against given criteria.
• A bug can be reproduced by a test before the fix begins.

Consequences and trade-offs

• ➕ The agent works through the failures it finds without waiting for a manual check of every step.
• ➕ Some defects are caught before review.
• ➕ The saved results show you how much verification was actually done.
• ➖ If there is no check, preparing one takes separate work.
• ➖ A weak check lets through an implementation that does not fully solve the task.
• ➖ The agent may weaken the check to succeed. Changes to the criteria have to be controlled separately.

Implementation

1. Describe the expected behavior before implementation and state how to check it.
2. If there is no check, start with a reproducing test (see TDD with an Agent).
3. Ask the agent to run the check after its edits, read the result, and fix the failures it finds.
4. Protect the criteria from being fitted. Agree on any change to a test or weakening of a condition separately; if needed, enforce the restriction with a hook.
5. For long autonomous work, add completion control and a review in a fresh context.
6. Accept the work by the environment's records: the tool call log, the CI log, or the hook's result. A retelling of the result in the agent's final message does not count as evidence.
7. Anchor the verification commands in Project Memory so the agent knows them in every session.

In OpenSpec, Superpowers, and Matt Pocock's skills, checks are part of the implementation workflow. The specific mechanism depends on the skill set and the task's criteria.

What doesn't depend on the agent

Verification after deployment

If the task promises lower latency or fewer errors under real traffic, include verification after deployment in the definition of done. This is a plain task for an agent with access to metrics, logs, and deployment history. Before deployment, agree on the intended effect, acceptable deviations, and observation period. Save baseline values for the affected scenario; if a required signal is missing, add instrumentation first.

After deployment, the agent compares data for the new version with the baseline for the relevant endpoint, region, or user group. The result includes the version, observation intervals, and links to queries and logs. With insufficient traffic, the result remains unverified. A metric spike coinciding with a deployment provides a hypothesis for diagnosis that still needs testing.

Agree on the response to a deviation in advance: notify the owner, prepare a fix, or propose a rollback. Executing a rollback requires separately agreed authority. The observation period bounds this check; continuous observation remains the job of monitoring.

Example

You are adding a cache to search and want to reduce response latency without increasing errors. While the agent prepares the change, you give it the following task:

Prepare a check of search performance after deployment

You approve a plan with the baseline p95, acceptable error rate, and a half-hour observation window. After deployment, you run the check. Average latency has fallen, but the agent finds more errors in one region and attaches the query and log examples. You investigate the deviation before accepting the change.

Example

For a promo code validator, you set the cases to check together with the task.

Write validatePromoCode: SUMMER25 is accepted, an expired code is rejected with reason expired, a code from another region with reason region, an empty string is rejected

The agent writes the tests and the implementation. The expired-code check fails because the date comparison ignores the time zone. After the fix, the agent runs the tests again. The session log shows the last test run after the final edit, with the result 4 passed.

You receive an implementation in which the time zone bug has already been found and fixed. Your involvement was needed only to set the scenarios and accept the result.

Anti-patterns and common mistakes

• Taking it at its word. A "done" message does not show what the agent checked. Ask for the run results.
• Retold output. The line 4 passed in the final message is still the agent's words. Check it against the run in the session log or in CI.
• A weak oracle. The check may miss significant cases. Compare it with the task's requirements.
• A check that is never run. Tests in the repository do not mean the agent ran them. Specify the command and the completion condition.
• Fitting the check. A weakened condition hides the defect. Changes to the criterion need a separate decision.
• Unit tests as the finale. For a user-facing feature, also check the end-to-end scenario, otherwise you risk premature success.
• Deployment as proof of impact. A successful deployment does not confirm lower latency or fewer errors. Compare the agreed signals with the baseline.

Known uses

• Claude Code best practices describe framing tasks with criteria and examples of verification.
• Agent tools can support session goals, Stop hooks, and review subagents.
• Anthropic's harness for long-running agents ties feature statuses to checks and runs a smoke test at the start of each session.
• SDD toolkits include acceptance criteria in specifications and tasks, and Superpowers uses the TDD cycle.
• Cursor, in Bots for the last mile, describes a monitoring plan before merge and a comparison of production signals with the baseline after deployment.

Related patterns

• Quality Gates enforce the whole project's standards on every change, not one task's criterion.
• TDD with an Agent starts each iteration with a test before the code changes.
• Writer and Reviewer checks properties that require judgment.
• Reflection helps find flaws through self-critique but needs external confirmation.
• Four Phases sets the checks in the plan and uses them during implementation.
• Premature Success occurs when work is declared done without an end-to-end check of the user scenario.
• One-Shotting describes expecting a finished result from a single pass with no verification cycle.