"Hallucination" is the industry term for a model stating something false as if it were fact — an invented clause number, a plausible-but-fake statistic, a confident summary of a section that doesn't exist. No prompt makes it impossible. But a handful of prompt-level patterns reliably reduce how often it happens and, just as importantly, make the failures that remain visible instead of fluent. Anthropic's own best-practices documentation includes minimizing hallucinations as a named topic, and the patterns below follow its general prompting principles.
Pattern 1: Fence the model inside supplied context
The single biggest lever for document-based work is an explicit boundary instruction: answer only from the provided material, and say so when the material doesn't contain the answer. Vague versions ("use the document") underperform explicit ones. A workable system-prompt fragment:
Answer using ONLY the documents inside <documents> tags.
If the documents do not contain the information needed,
reply exactly: "The provided documents do not answer this."
Never fill gaps from general knowledge. This output goes
into a compliance record, so an unsupported claim is worse
than no answer.Two details of that fragment come straight from official guidance. Wrapping inputs in XML tags gives Claude an unambiguous boundary between "trusted source material" and everything else. And the final sentence — explaining why the rule exists — matters: Anthropic's docs note that Claude generalizes better when instructions come with their reason, not just the rule.
Pattern 2: Give the model permission to say "I don't know"
Models hallucinate more when the prompt implies an answer must exist. Counter that by making uncertainty an explicitly sanctioned output: define the fallback phrase, show it in an example, and treat it as a success case in your evaluations rather than a failure. The golden rule from Anthropic's best-practices page applies here — if a new colleague reading your prompt would feel pressured to guess, Claude will too. Pair the refusal fallback with calibrated hedging for partial knowledge: instruct Claude to prefix uncertain statements with "based on the provided text" or to flag inference versus quotation. (There's a full article on confidence and hedging instructions.)
Pattern 3: Demand quotes, or use the citations feature
Asking for supporting quotes turns silent errors into checkable ones: a fabricated claim usually can't produce a verbatim quote, and a reviewer can string-search the quote in seconds. Better still, on document workloads you can skip prompt-level quoting and enable the API's built-in citations feature — set "citations": {"enabled": true} on the document block and responses come back with structured references to the exact source passage. Anthropic's docs note this is also more token-efficient than prompting for quotes. See asking Claude to cite its sources for the full treatment.
Pattern 4: Reasoning before conclusions
For judgment-heavy tasks, instruct Claude to work through the evidence before stating the answer — extract the relevant passages first, then conclude. Forcing the evidence-gathering step ahead of the conclusion gives the model a chance to notice that the evidence isn't there. On current models, adaptive thinking does deliberate internal reasoning by default; you can also nudge it per request ("Please think hard before responding") when a task warrants extra care.
What prompts can't fix
Be honest about limits. If users ask questions your supplied context can't answer, no instruction stops every gap-fill — fix retrieval or the knowledge base instead. If the task genuinely requires world knowledge (open-ended market questions, say), context-fencing doesn't apply, and your defense shifts to hedging language, human review, and scoping the feature honestly. And Anthropic's prompt-engineering overview makes a point worth repeating: not every failing evaluation is a prompting problem. If a smaller model hallucinates on your workload after serious prompt effort, testing a more capable model tier is a legitimate next step — see prompting differences across model tiers.
Finally, measure. Build a small evaluation set of questions whose answers you know — including questions the context deliberately cannot answer — and track how often each prompt version invents rather than declines. Without that number, "we reduced hallucinations" is itself an unsupported claim.
Where to go next
Grounding instructions for retrieval pipelines get their own article at grounding prompts for RAG, and building a prompt evaluation framework covers turning the measurement habit into a system.