How to Reduce Hallucinations in Tool-Based AI Apps

Coding Liquids blog cover featuring Sagnik Bhattacharya for reducing hallucinations in tool-based AI apps.
Coding Liquids blog cover featuring Sagnik Bhattacharya for reducing hallucinations in tool-based AI apps.

AI hallucinations are not random failures — they follow predictable patterns. In tool-based applications, the model hallucinates when it does not have the information it needs, when it misinterprets tool results, or when the prompt encourages confident answers regardless of evidence.

I teach Flutter and Excel with AI — explore my courses if you want structured learning.

Understanding these patterns lets you design applications that reduce hallucinations systematically, not just hope the model gets it right.

Follow me on Instagram@sagnikteaches

Quick answer

Give the model access to the information it needs (via tools and retrieval), design prompts that encourage 'I don't know' over confident guessing, validate tool results before letting the model use them, and add citation requirements so outputs can be verified.

Connect on LinkedInSagnik Bhattacharya
  • Your AI application produces factual claims that need to be accurate.
  • Users trust the application enough to act on its outputs without independent verification.
  • You are using tool calling or RAG and still seeing incorrect information in outputs.

Why tool-based apps still hallucinate

Tools and retrieval reduce hallucinations by giving the model real data to work with. But they do not eliminate them. The model can still hallucinate when: the tool returns incomplete data, the model misinterprets the result, or the prompt encourages an answer even when the data is insufficient.

Subscribe on YouTube@codingliquids

The most dangerous hallucinations are the ones that look like they came from a tool result but actually did not.

Design patterns that reduce hallucinations

Several design patterns systematically reduce hallucinations in tool-based applications.

  • Require citations — force the model to reference specific tool results for every claim
  • Use structured outputs — constrain the model to return data in a format that can be validated
  • Add verification tools — give the model a tool that checks its own claims against a database
  • Design for 'I don't know' — make it easy and acceptable for the model to say it lacks information
  • Limit generation to tool results — instruct the model to use only information from tool calls

Prompt design for accuracy

The prompt has enormous influence on hallucination rates. A prompt that says 'always provide a helpful answer' encourages hallucination. A prompt that says 'only state what the provided data supports, and say you don't know otherwise' reduces it.

Include explicit instructions about what to do when information is missing or ambiguous. The model needs permission and instructions to be uncertain.

Validating tool results

Sometimes the tool itself returns incorrect or incomplete data. The model cannot know this — it trusts tool results. Add validation layers that check tool results before passing them to the model.

For example, if a database query returns zero results, handle that case explicitly rather than letting the model try to answer without data.

Post-generation verification

After the model generates a response, verify it against the tool results that were used. Check that every factual claim has a supporting tool result and that the model did not add information from its training data.

This can be automated for structured outputs (check that every field maps to a tool result) or semi-automated with an LLM judge for free-text responses.

Worked example: reducing hallucinations in a research assistant

A research assistant searches papers and answers questions. Before: 25% of answers contain facts not found in any retrieved paper. After applying the patterns above (citation requirements, structured outputs with source fields, explicit 'insufficient data' handling), the rate drops to 5%. The remaining 5% are semantic misinterpretations that human review catches.

Common mistakes

  • Treating hallucinations as a model problem rather than a design problem.
  • Encouraging the model to 'always be helpful' without allowing uncertainty.
  • Not validating that tool results are complete and correct before using them.

When to use something else

For testing prompts that are designed to reduce hallucinations, see testing AI prompts. For using structured outputs to constrain model responses, see structured JSON outputs.

Frequently asked questions

Why do tool-based apps still hallucinate?

Tools and retrieval give the model real data but do not guarantee it uses them correctly: the tool can return incomplete data, the model can misread it, or the prompt can push for an answer when the data is insufficient.

What is the single biggest lever?

The prompt. 'Always give a helpful answer' invites hallucination; 'only state what the provided data supports, otherwise say you do not know' measurably reduces it.

How do citations help?

Requiring the model to cite the source chunk or tool result for each claim makes outputs verifiable and discourages invented facts: if it cannot cite it, it should not assert it.

Should I validate tool results before the model uses them?

Yes. Check the completeness and sanity of a tool's output first; feeding the model partial or malformed data is a common cause of confident but wrong answers.

How do I make abstaining an acceptable answer?

Say so explicitly in the prompt and reward it in evaluation. Models default to answering, so you have to give them permission and incentive to abstain when the data is thin.

Can I eliminate hallucinations entirely?

No, you reduce and contain them. Combine grounding through tools and retrieval, abstention prompts, result validation, and citations, then monitor with evals; treat it as risk management, not a one-time fix.

Related guides on this site

These guides cover prompt testing, structured outputs, and quality evaluation for AI applications.