Three subagents have each finished a slice of a refactor, and each has reported success. You are about to run a verification pass over the combined result. What has to be true of that pass for it to tell you anything you do not already have?

The principle — a verification pass earns its place by changing who is doing the judging. If the same parties decide again, the pass adds a step and no information.

Why the key is correct — the glossary states the failure the pass is there to prevent: without one, the only thing deciding the agent is finished is the agent itself. Three finished slices and three claims of success are three instances of that, not an escape from it. Anthropic's best-practices page describes what a real pass looks like — a verification subagent or a dynamic workflow that checks its own findings has a fresh model try to refute the result, so the agent doing the work is not the one grading it. That sentence names the property, and the property is separateness.

Why the others are wrong — reports of success are the thing under question, so counting three of them settles nothing; Claude stops when the work looks done. Asking each worker to re-check its own slice keeps the author in the grading seat, and a fresh context is what improves a review precisely because Claude will not be biased toward code it just wrote. And the claim that a late check matters less inverts the guidance: the longer Claude works unattended, the more an independent check matters before you count the work as done.

Remember this — after delegated work, the question is not whether you verified but who did — a pass run by the workers is the workers' opinion again.

Sources — Anthropic's Claude Code glossary and best practices.