Verify

Verify answers a stricter question than “Did the agent finish?” It asks whether the result satisfies the original task, preserves the repository’s required behavior and has enough evidence for a reviewer to trust the handoff.

Verification begins with the proposed change and the evidence produced during implementation.

Build an evidence stack

No single signal proves every kind of software change. A useful Verify stage combines evidence that matches the risk of the task.

Evidence	What it can establish
Repository checks	The change passes tests, type checks, linting and build rules enforced by the project
Pull request state	The branch is current, the expected files changed and required review policies are satisfied
Task-specific checks	The behavior requested in the issue can be observed or reproduced
Agent review	The diff can be inspected for omissions, unintended scope and inconsistency with the request
Human review	A responsible person accepts decisions that require product, security or operational judgment

Choose checks before execution when possible. Verification is strongest when its success condition comes from the task and repository rather than from the agent that wrote the code.

A failed check is feedback

When a deterministic check fails, return the relevant output to implementation. The agent needs the command, failure message and current task context. It should not receive a vague instruction to “try again.”

This creates a bounded correction loop:

Run the required checksCapture the failureReturn focused feedbackRecheck the new result

Limit the loop. Repeated failure can signal a poorly scoped task, a missing dependency or a decision the agent cannot make. At that point the useful action is to ask for attention rather than spend another attempt on the same assumption.

Separate run health from result quality

A workflow step can execute successfully and still produce an unacceptable result. It can also encounter a temporary API failure before the code is evaluated. Keep these cases distinct:

• Execution failure: The component could not complete because an external service, credential or runtime failed.
• Verification failure: The component ran and the change did not meet a required condition.

The first may need an operational retry. The second should change the code or the task. Keeping both visible makes recovery faster and reporting more honest.

Know when to ask a person

Human attention is appropriate when the answer depends on judgment rather than computation. Examples include accepting a user-facing tradeoff, approving a sensitive dependency, interpreting an ambiguous requirement or deciding whether a broader refactor belongs in scope.

Reviewers see the task and implementation context before deciding what happens next.

Exit criteria

A task can leave Verify when the Factory’s required checks have passed and all required decisions are recorded. Depending on the Factory, that may mean the pull request is ready for normal team review or already approved for merge.

Passing verification moves the task to Done. Failing verification returns useful context to the stage that can act on it.