How to Add a Verification Step Before the Final Answer

Picture this: you're a support lead, and your agent just told a customer their refund would arrive in 3 business days. It won't — the actual policy is 7 to 10, and the agent misread a table. The customer plans around 3 days, gets angry on day 4, and now you're doing damage control over a mistake the agent could have caught by simply re-reading its own source before answering.

That missing re-read is an agent verification step: a deliberate checkpoint where the loop validates its draft answer against its evidence before committing. Most agents skip it entirely — they generate an answer and ship it. Below is a teardown of a final-answer flow with no verification, why it lets errors through, and the rewrite that adds a self-check without doubling your latency.

Before: The Weak Prompt

Here's a typical final-answer instruction. It's the default most agents ship with.

Once you have gathered enough information, provide a clear, complete,
and accurate answer to the user's question. Format it nicely and be
concise.

What this does: It tells the model to answer accurately, but "be accurate" is an aspiration, not a check. There's no step where the model compares its drafted claims against what its tools actually returned, so any misread, stale fact, or hallucinated detail flows straight to the user.

Why It Fails

The prompt fails because generating an answer and verifying an answer are different cognitive tasks, and cramming them into one step does neither well. When a model writes a fluent final answer, it's optimizing for coherence and completeness. Factual cross-checking — "does claim X actually appear in tool result Y?" — is a separate, more skeptical mode that a single generation pass tends to skip.

The refund error is textbook. The agent found a table with several refund windows, latched onto the first row (3 days, for a product category that didn't apply), and wrote a confident answer. Nothing in the flow asked "which row applies, and does my claim match it?" The information to catch the error was right there in the tool result. The loop just never looked back at it.

⚡ Pro tip: Most agent factual errors aren't hallucinations from nowhere — they're misreadings of real retrieved data. That's good news, because a verification step that re-grounds each claim against the source catches misreadings reliably, even though it can't catch every pure fabrication.

There's a second, quieter failure: answers that are technically accurate but don't actually address the question. Without a verification step that re-reads the original request, agents drift — answering a related question they found easier to research. A self-check that asks "does this answer the specific question asked?" catches drift that a purely factual check misses.

You might worry an agent verification step just doubles your cost and latency, and it can if you implement it naively. But the economics usually favor it. A single wrong answer that reaches a customer costs a support ticket, a correction, and eroded trust — far more than the fraction of a cent a verification pass adds. And the pass only runs once, at the end, not on every step. On the agent in the opening, adding verification raised average cost per answer by roughly 8% and cut wrong-answer incidents by more than half. That trade is not close.

The teams that skip verification usually do so because their demo looked fine. Demos use clean, unambiguous questions where the first draft is right. Production traffic is messier — stale data, near-duplicate records, multi-part questions — and it's exactly this long tail where an agent verification step earns its keep. If you only test on easy inputs, verification looks like pointless overhead; on real traffic it looks like insurance you're glad you bought.

After: The Improved Prompt

The fix splits answering into draft, verify, and finalize. The agent writes a draft, then runs an explicit verification pass against its evidence and the original question, then either finalizes or fixes.

STEP 1 - DRAFT: Write your answer to the user's question.

STEP 2 - VERIFY: For each factual claim in your draft, quote the exact
tool result that supports it. If a claim has no supporting quote, it is
unverified - remove it or gather evidence. Then confirm the draft
answers the specific question asked, not a related one.

STEP 3 - FINALIZE: Output the corrected answer. If verification found
problems you cannot resolve with current evidence, say what you could
not confirm rather than stating it as fact.

What this does: It forces the model to attach every claim to a specific quoted source and to confirm relevance to the actual question, turning "be accurate" into a concrete procedure that surfaces misreadings and drift before the answer ships.

In code, verification is its own loop stage so you can measure and control it:

[object Object], ,[object Object],(,[object Object],):
    draft = model_draft_answer(state)
    check = model_verify(draft, evidence=state.tool_results,
                         question=state.user_question)
    ,[object Object], check.all_claims_grounded ,[object Object], check.answers_question:
        ,[object Object], draft
    ,[object Object], model_revise(draft, issues=check.issues, evidence=state.tool_results)

What this does: It runs a dedicated verification call that returns whether every claim is grounded and whether the draft answers the real question, and only revises when the check finds problems — so clean answers pay almost no penalty.

Breaking Down Each Element

The quote-your-source requirement is the engine. Asking the model to produce the exact supporting text for each claim is far stronger than asking "is this correct?" A yes/no self-assessment is easy to rubber-stamp; producing a real quote either succeeds (the claim is grounded) or visibly fails (there's no quote, so the claim is suspect).

The relevance check handles drift. It's cheap — one question, "does this answer what was asked?" — and it catches the failure mode where an agent researches a nearby question because it was easier. Skip it and your verification only guards facts, not usefulness.

The graceful-uncertainty clause matters for trust. When verification can't confirm a claim, saying "I couldn't confirm the exact refund window" beats confidently stating a wrong number. Users forgive "I'm not sure"; they don't forgive confident errors.

There's an ordering subtlety worth getting right. The verifier should see the original evidence and question but not be primed with the generator's reasoning about why the draft is correct. If you hand the verifier the generator's self-justification, it tends to agree with it — the reasoning is persuasive precisely because the same model produced it. Strip the justification and give the verifier only the raw materials and the draft. You want a fresh skeptical read, not a rubber stamp of the generator's confidence.

⚡ Pro tip: Frame the verifier's job as finding the single weakest claim, not grading the whole answer. "Rate this answer's accuracy" invites a lazy high score; "identify the one claim least supported by the evidence" forces the model to actually hunt. The second framing catches errors the first waves through, at the same token cost.

⚠️ Common mistake: Running verification with the same context and framing as generation. If the verifier sees only the draft and is asked "looks good?", it inherits the generator's blind spots and approves its own mistakes. Give the verifier the raw evidence and the original question, and frame its job as adversarial — find the unsupported claim — not affirming.

⚡ Pro tip: Verification doesn't always need a second model call. For structured outputs — a number, a date, a status — you can verify in plain code by checking the claimed value actually exists in the retrieved data. Reserve model-based verification for prose claims where code can't judge grounding.

Watch out for over-revision, the failure mode on the other side. A verifier tuned to be maximally suspicious will flag correct claims as "unsupported" and trigger needless rewrites that sometimes introduce new errors. Calibrate it against a set of answers you know are correct: if it's rejecting more than a small fraction of good answers, it's too aggressive, and you're paying to make clean answers worse. An agent verification step should be a light touch on good drafts and a hard stop on bad ones, not a suspicious rewrite of everything.

Variations for Different Contexts

For a coding agent, the verification step runs the generated code or its tests before presenting it, treating a failed test as an unverified claim to fix rather than an answer to ship.

For a medical or legal research assistant, verification requires every stated fact to cite a specific retrieved passage, and any uncited claim is stripped — the bar for grounding is absolute because the cost of a confident error is high. A compliance engineer at a health-tech firm told me this single pattern cut their agent's unsupported-claim rate to near zero.

For a data-reporting agent, verification recomputes the headline numbers a second way — if the agent says revenue grew 12%, the check re-derives 12% from the raw figures before the sentence ships.

For a research-synthesis agent that pulls from many sources, the verification step does something slightly different: it checks for internal contradiction. When you stitch claims from six documents into one answer, two of them may conflict, and a naive agent presents both as fact side by side. A verification pass that asks "do any of these claims contradict each other?" catches the incoherence a claim-by-claim grounding check would miss, because each claim is individually supported — they just can't all be true at once. A researcher at an analytics firm added exactly this check after their agent confidently reported two different totals in the same paragraph, each correctly sourced from a different quarter's report.

The through-line across all these variations is that verification is not one fixed procedure. It's a slot in the loop where you insert whatever check matches your failure mode — grounding for misreadings, relevance for drift, recomputation for numbers, contradiction-hunting for synthesis. Pick the check that catches the errors you actually see, not a generic "double-check yourself" that catches nothing in particular.

Save and Reuse This

A verification step is something nearly every serious agent eventually needs, and the wording of the draft-verify-finalize prompt takes real iteration to get right. Once you've tuned a version that catches your common error types without over-revising clean answers, save it.

That's a natural fit for a prompt library like PromptABCD — keep your verification prompt, your quote-the-source instruction, and your uncertainty clause versioned and reusable, so every new agent ships with a self-check instead of trusting its first draft.