Define Done, Not Effort: Prompts That Make Agents Verify

The highest-leverage line in an agent prompt is not more effort language — it is acceptance criteria: a written definition of done, a check the agent can run, and an explicit instruction to verify the result and keep iterating until the bar is met. Telling a coding agent to try harder changes its tone. Telling it what done looks like changes what it is allowed to call finished.

This is now vendor doctrine, not folklore. Anthropic's Claude Code best-practices documentation carries a section titled "Give Claude a way to verify its work," xAI's Grok Build shipped a goal-directed mode built on the same idea, and the academic self-correction literature explains why the pattern works where "be thorough" does not. The common thread: the feedback has to come from outside the model.

This playbook covers the mechanism, the evidence, the anatomy of a completion bar, four escalating ways to enforce one, the capture-then-critique pattern for outputs that resist description, and a copy-adaptable table of vague asks rewritten with bars that close the loop.

Compare two endings for the same prompt. One closes with effort language: be thorough, don't cut corners, make sure it really works. The other closes with a bar: the three example inputs produce these three outputs, run the tests after implementing, and paste the output. Only the second ending names a condition the agent can check. We offer that as recommended practice rather than a measured finding — and the vendor documentation now says the same thing in mechanism terms.

Anthropic's Claude Code best-practices guide is unusually blunt about why. Claude stops when the work looks done — and without a check it can run, “looks done” is the only signal available, so you become the verification loop. Every review round you personally run is a round the agent could have run against a check you never named. The guide's framing of the payoff is worth quoting in full, because it doubles as the job description for a completion bar.

Note what the fix is not. It is not the harness's effort dial — reasoning-effort tiers set how hard the model thinks, not when it is allowed to stop. And it is not a longer brief, which shapes what gets built rather than when building may end. A completion bar is its own layer: it converts an open-ended generation task into a closed loop with a pass/fail exit. Give the agent something that produces a pass or a fail, and — in the vendor's own phrasing — the loop closes on its own.

A fair question: why should stating a bar beat asking for care? The clearest answer in the academic record comes from Huang et al., published at ICLR 2024 under the title Large Language Models Cannot Self-Correct Reasoning Yet. The paper's central distinction is intrinsic self-correction — asking the model to fix its answer using nothing but its own introspection — versus correction grounded in external feedback. The first largely fails; the second is where the gains live.

The iterate-on-feedback side of the ledger has its own line of research. Reflexion (Shinn et al., NeurIPS 2023) had agents verbally reflect on task feedback and carry those reflections into the next attempt, and reported 91% pass@1 on the HumanEval coding benchmark — against an 80% figure for a contemporaneous GPT-4 result the same paper cites. Both numbers are the authors' own, on a 2023-era model generation that has long since been superseded; we cite them to establish that iterating on feedback is a studied technique with measured effects, not to claim the deltas transfer unchanged to 2026 agent harnesses.

One more result rounds out the picture, mostly as a contrast. Self-consistency decoding (Wang et al., 2022) samples many diverse reasoning paths and takes a majority vote on the final answer. The author-reported gains over standard greedy chain-of-thought were substantial across reasoning benchmarks — but notice what the method is: consistency voting. It improves the guess without checking anything outside the model. It is not verification, and conflating the two is how teams end up believing an agent “checked its work” when it merely agreed with itself.

Read together, the through-line is simple: models improve when the loop contains information they did not already have. A test run, a build log, a rendered screenshot inject exactly that. Asking the model to re-read its own output does not — and per Huang et al., it can make things worse. That is why the completion bar has to name a check that exists outside the model, and why “verify your work” without a named check is just effort language wearing a verification costume.

Anthropic's documentation for goal conditions in Claude Code describes what makes a completion condition durable, and the structure generalises to any prompt on any harness. Four parts: one measurable end state; a stated check; how the agent should prove the check passed; and the constraints that must not change on the way there. Claude Code caps a goal condition at 4,000 characters — a useful discipline even when you write the bar inline, because a bar that needs more space than that is usually several bars pretending to be one.

The vendor's own before/after example makes the shape concrete. The vague version asks for an email validator. The verification-bearing version asks for the same function, supplies example cases — an address like user@example.com should validate, malformed ones should not — and ends with the instruction to run the tests after implementing. Nothing about the ask got longer in any meaningful way; what changed is that the prompt now contains its own exit condition.

The fourth part — evidence — deserves its own emphasis. Anthropic's guidance is to have the agent show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result. An assertion of success is the model grading itself, which is precisely the loop the research says to distrust. Evidence moves the grading outside the model, where you (or a hook, or a reviewer) can check it in seconds. The input-side counterpart of this discipline — writing the brief well in the first place — is a different craft, and we've covered it separately in The Brief Is the Product. The two compose: the brief bounds what gets attempted, the bar decides what gets to call itself finished.

Writing the bar is half the pattern; deciding where enforcement lives is the other half. Anthropic's best-practices documentation describes four escalating mechanisms for binding a stop to a check. They form a ladder: each rung costs more to set up and buys more autonomy in return.

Two operational caveats from the same documentation. First, the goal-condition evaluator is deliberately not the model doing the work — Claude Code sends the condition to a configured small fast model, defaulting to Haiku on the Claude API, which answers yes or no with a short reason. It calls no tools, so it can only judge what the agent has already surfaced in the conversation — which is exactly why the evidence habit from section 03 matters. (The feature also assumes a trusted workspace: it is unavailable when hooks are disabled by policy.) Second, the adversarial rung has a documented failure mode of its own: a reviewer prompted to find gaps will usually report some, even when the work is sound. The vendor's fix is to scope the reviewer to correctness and the stated requirements, and treat everything else as optional.

That fourth rung is a within-harness cousin of a technique we've written about before — cross-model review, where the second opinion comes from a different provider's model entirely rather than a fresh context of the same one. And the ladder as a whole is what makes walk-away sessions viable at all: the more enforcement you push into the loop, the less the workflow depends on you watching it. Our companion piece on synchronous versus async agent workflows picks up that thread.

Completion bars are easy to write where the output is text-shaped: tests pass or they don't, builds compile or they don't. Some outputs resist that. Visual polish is the everyday case — “make the dashboard look better” fails not because the agent is lazy but because the bar is unstated, and mostly unstatable, in words. You cannot name the check in advance because you don't know what's wrong yet.

The pattern that works is capture-then-critique: capture the current state, list what is wrong with it, fix only the listed items, then re-capture and compare. The list is the completion bar — generated on demand, from evidence, instead of written up front. Anthropic's own before/after table carries exactly this shape for design work: paste the target design, implement it, take a screenshot of the result, compare it to the original, list the differences, fix them. The vague alternative it contrasts against is, verbatim in spirit, the “make it look better” prompt everyone has typed at least once.

The clause that does the work is fix only the listed items. It pins the iteration to a finite, diffable list — without it, each pass is free to redecorate whatever it touches, and you trade one unverifiable aesthetic state for another. We've covered the full visual technique, vision-model comparisons included, in our screenshot-driven UI development guide, so we won't re-teach it here. The deeper question — which output types an agent can inspect at all, and where you remain the checker no matter how good the prompt is — is the subject of our companion piece on agent self-verification limits by output modality. The short version: a completion bar is only as strong as the check backing it, and where no external check exists, the honest bar is “package the evidence so a human can verify it fast.”

The strongest external signal that the completion bar is the right abstraction: two rival vendors productised it independently, under the same name. Alongside Anthropic's goal conditions, xAI's terminal coding harness Grok Build shipped its own /goal on June 22, 2026.

The two features share a name but differ in evaluator architecture, and the difference is instructive. Grok Build's version plans an approach, breaks the work into a progress checklist, and executes against it — with status, pause, resume, and clear commands, and a panel that flips to Complete when every item is checked. Claude Code's version judges a condition you wrote, using a separate model. Our reading, offered as analysis rather than a measured claim: a checklist the agent derived from its own plan is a weaker external check than a condition a human authored, for exactly the reasons in section 02 — it moves the grading closer to the model's own introspection. Either way, the convergence cuts through vendor noise: both companies looked at how sessions actually fail and concluded that verification, not effort, is what needed a first-class control. And because the practice lives in the prompt, it is portable — a written bar plus an iterate-until instruction works on any competent harness, goal feature or not.

The fastest way to internalise the pattern is to see the same ask before and after. The rows below are our own worked examples from the kinds of delivery we run — CRM automation, ecommerce, paid media, web development — with invented details (any company or domain named is a placeholder on example.com). Thresholds inside the bars are illustrative targets you set for your own stack, not benchmarks we are reporting.

Three of these rows assume test fixtures exist — staged leads, a list of invalid inputs, a baseline capture. That is not an accident. The completion bar rewards teams whose workflows already carry checkable artifacts, which is why our CRM automation builds ship with fixture data and routing tests from day one: the fixtures are what let an agent maintain the system later. The landing-page row is a whole discipline of its own — our companion piece on agentic landing-page QA for paid media runs it end to end.

We've written a lot about prompting, so it's worth placing this piece precisely. Our prompt-engineering anti-patterns guide catalogues what to remove from prompts; the advanced-techniques guide catalogues what to add across the whole prompt surface; and The Brief Is the Product covers the input side — the quality of the spec you hand an agent before it starts. This playbook owns the narrower, later lever those pieces don't: the output side. What may the agent call done, how must it prove it, and what happens when the proof fails. Across our own prompt-engineering catalogue, that seam is the one those pieces leave open — and it is the one the vendors themselves are now building features around.

The trend worth interpreting is that verification is migrating from prompt craft into product surface. Goal conditions evaluated by a separate model, deterministic stop gates, documented adversarial-review patterns, two vendors shipping a /goal command — these are harness features rather than prompt tricks. Our reading is that the vendors converged on the same diagnosis this playbook argues from the literature: sessions end at plausible, not at done, unless something external holds the exit shut.

Looking forward, we expect completion bars to become first-class, versioned artifacts — acceptance-criteria files that live in the repo next to CI config, reused across sessions and harnesses the way test suites already are. Effort language, meanwhile, is likely to keep migrating into harness configuration and out of prompts entirely. The practical move is to start maintaining a bar library now — one per recurring workflow, with fixtures to match — so the review round you currently run by hand has somewhere else to live. Designing that operating model is the core of our AI transformation engagements: not picking a model, but building the checks that let any model prove its work.