Adding a search tool to an agent takes an afternoon. Making the agent trustworthy after you add it takes a design decision: what is it allowed to assert, and what happens when the search returns nothing.
Most mistakes happen in the second half. The tool works, the agent calls it, and the output gets summarised into a confident paragraph that cites a page nobody opened.
The short answer
Give the agent one search tool and one fetch tool. Require a URL for every factual claim, cache pages within a session, and treat an empty result as a failure to report rather than as evidence. Those four rules remove most of the failure modes.
One tool, not five
An agent with five search backends will choose badly, because the descriptions overlap and the model picks by phrasing rather than by strategy. Start with one — Tavily or Exa both return content with results — and add a second only when a measured failure demands it.
The fetch tool matters separately: search snippets are partial, and a claim about a number usually needs the page. Firecrawl exists for the step where a raw fetch returns a JavaScript shell or a cookie banner instead of the article.
The citation contract
State it in the tool description and in the prompt: every factual sentence must reference a URL that was returned by a tool in this session. If the agent cannot point at a source, it says it could not verify the claim.
This is checkable in code: scan the output for sentences with numbers or names and no URL nearby. It will not be perfect, and it will catch the confident paragraph that cites nothing.
Treat empty results as errors
The most damaging pattern in agent search is not a wrong answer; it is the summarisation of an empty result. The API returns zero hits, the agent writes "there is no evidence that X", and the user believes a search happened.
Make the tool return an explicit error on zero results, and make the prompt say what to do: report the failure, suggest a broader query, and do not conclude absence from one attempt.
Cache and budget
A session that searches the same query twice is paying twice and reading twice. Cache results by query for the session, and cap the number of searches per task so a loop cannot spend an unbounded budget.
The cap also improves answers: an agent that can search fifty times tends to keep searching instead of synthesising. Five is usually enough for a single question.
The verification pass
After the agent writes, run one cheap check: for each cited URL, confirm it existed in this session and that the page contains the claim's key term. This is a string match, not an LLM judgement, and it catches the majority of fabricated citations.
The check does not prove the claim is right. It proves the claim is grounded, which is the part an automated system can verify.
What this looks like as a tool
| Tool | Input | Output | Failure behaviour |
|---|---|---|---|
| search | query | results + URLs + snippets | error on zero |
| fetch | URL | extracted text | error on block/timeout |
| verify | URLs + claim | grounded / not grounded | reports missing |
Three tools, one session, and a rule that no answer is written until the verify step passes. Compared with a single "answer this" tool, the extra step is small and the failure mode it removes is the expensive one.
When to skip the workflow
If the agent is writing a first draft for a human who will check it, the full pipeline is overhead. If the output goes to a customer, a dashboard, or another system, the verify step is not optional.
Frequently asked questions
Should the agent read or fetch pages itself? Prefer tools that return extracted text, and keep the fetch step explicit so failures are visible.
How many sources per answer? One to three for a direct question. More sources usually means the agent is hedging, not researching.
Does this work in MCP? Yes — search, fetch, and verify are natural tool boundaries. See search APIs for agents and the search directory.
Last checked: 9 November 2026.
Related: answer engines vs search engines, guardrails, and the curriculum.