Stop Reviewing the Review: How Agent Workflows Drift Out of Scope

Consider a composite agent-workflow pattern. The task begins with a useful, bounded objective: prove one behavior safely enough to decide whether a small next step is reasonable.

A reviewer found a real gap. The workflow added a validator. The validator needed a schema. The schema needed fixtures. The fixtures needed a receipt. The receipt needed its own parser. Then the next review focused on the proof system rather than the original behavior.

Every local change looked defensible. The overall trajectory was not.

Scope creep becomes hard to see when each extra layer is individually reasonable.

The Failure Mode: Assurance-Boundary Expansion

Ordinary scope creep adds features. Assurance-boundary expansion adds proof obligations. It often follows this sequence:

1. A workflow defines a behavior and a safety boundary.
2. A review finds a gap in the implementation or evidence.
3. The revision adds machinery to prove the gap is closed.
4. The next review evaluates that machinery and finds another gap.
5. The proof boundary expands again while the original user outcome remains unchanged.

This is not proof that review is bad. The first objection may be essential. The dangerous move is allowing every new concern to inherit blocking authority merely because it appeared later in the review chain.

The transition from revision to recursion is the moment to stop and re-anchor.

Freeze a Target That Fits on One Screen

A useful review target should be small enough that a reviewer can tell whether a finding changes the decision. I use a target card with six fields:

Objective: the one user-visible behavior under review
Safety invariant: what must never happen
Permitted delta: files, interfaces, or behaviors allowed to change
Evidence gate: what observation would support the decision
Review budget: initial review plus at most one confirmation
Stop condition: the exact state that ends this cycle

The card is not a magic specification. Its job is to make expansion visible. If a proposed fix needs a new authority model, new proof subsystem, or broader effect surface, that may be a valid next project—but it is not silently the same project.

Classify Objections by Causality

The most useful question is not “is this concern technically valid?” Many concerns are valid. The question is “does this concern causally invalidate the frozen behavior, safety invariant, or evidence gate?”

This causality test prevents a common category error: treating an operational review failure as new evidence that the product behavior is wrong. A timed-out critic, malformed verdict heading, or missing review metadata may invalidate that review result. It does not automatically invalidate the frozen implementation.

Use One Coherent Revision

When an initial review returns several related objections, fix them as one declared delta. Do not open a fresh mini-cycle for each comment.

1. Freeze the accepted objection set.
2. Map each objection to one revision or explicit rationale.
3. Verify the revised artifact deterministically where possible.
4. Ask one confirmation question: did this frozen delta resolve the accepted objections without creating a decision-changing regression?

The confirmation should not redesign the validator, invent a new receipt format, or expand the fixture matrix. If it does, it is no longer confirming the same delta.

Budget Assurance Before the Cycle Starts

Review budgets sound arbitrary until a workflow has spent hours improving its own acceptance machinery. The budget creates a forced decision point:

• Initial review: discover decision-changing defects.
• One coherent revision: address the accepted set.
• One confirmation: verify that frozen delta and check for decision-changing regressions introduced by the revision.
• Then stop: accept, block, or explicitly re-anchor as a new cycle.

A stop does not mean every possible concern is solved. It means the current decision has reached its declared evidence boundary. Remaining hardening becomes backlog with a reopen trigger.

Track Outcome Readiness Separately from Assurance Depth

A workflow can be highly verified and still far from its user outcome. Track both dimensions:

If assurance depth rises while outcome readiness stays flat, investigate scope drift before adding another layer.

When More Assurance Is Worth It

Do not use this pattern to dismiss hard safety work. Additional proof is justified when:

• the next step has irreversible or broad external effects;
• a new finding directly breaks the frozen safety invariant;
• the evidence path cannot distinguish success from a dangerous false positive;
• the workflow will become standing automation rather than a one-time bounded action; or
• the target has explicitly changed and the user approves a re-anchor.

In those cases, expand deliberately. Name the new target, reset the evidence contract, and avoid pretending the old review cycle simply continued.

When Not To Use This Pattern

A review budget is not a shortcut around:

• unresolved evidence that the system can cause harm;
• missing authorization for a protected action;
• unknown rollback behavior for a destructive change;
• current runtime drift that makes the frozen target stale; or
• a reviewer objection that directly falsifies the central claim.

The purpose is to constrain irrelevant expansion, not to cap truth-seeking.

Conclusion

Agent workflows need review. They also need a definition of done for the review itself.

Freeze the target. Classify objections by whether they causally change the behavior, safety invariant, or evidence gate. Repair one coherent delta. Confirm it once. Then accept, block, or re-anchor—without allowing the proof system to quietly become the product.

The right stop rule is not “no reviewer can imagine another concern.” It is “the frozen decision has the evidence it declared.”