When can an agent trust a web search result?

An AI agent should treat a web search result as a lead, not a verified answer. Before using it, the agent needs to find the claim on the linked page, check the source responsible for that fact, and establish its place, date, and scope. A snippet and a prominent rank cannot do that work.

On 24 September 2026, we searched for “UK bank holidays 2026 England Scotland gov.uk” in Brave Search. The results included the official GOV.UK calendar and a third-party 2026 holiday calendar that describes itself as using “Official GOV.UK data.” Its visible text says Scotland has nine bank holidays in 2026. The government's published data lists ten.

The discrepancy would produce an incorrect annual count or an incomplete historical calendar. It did not change the next upcoming holiday as of our September check: the omitted June date had already passed. It illustrates a broader mistake: turning a search hit into a fact without establishing what was searched, who owns the answer, and when the underlying information changed.

This is one observed query and one conflicting page, not a measurement of Brave Search, calendar sites, or search-provider accuracy. The third-party page's text itself still contained the old count when checked; there is no need to speculate that the search engine cached an older version.

Case study: which UK bank holiday is next?

“When is the next UK bank holiday?” lacks an essential detail: where? On the date of our check, the GOV.UK calendar and its machine-readable feed gave the following answers:

Nation or region	2026 bank holidays in GOV.UK's feed	Next bank holiday after 24 September 2026
England and Wales	8	Friday 25 December, Christmas Day
Scotland	10	Monday 30 November, St Andrew's Day
Northern Ireland	10	Friday 25 December, Christmas Day

If the question means a holiday observed across all three lists, the next one was Christmas Day. If the person lives in Scotland, their next listed bank holiday was St Andrew's Day. A single unqualified “UK” date would conceal that difference. And if the question is used after this article's check date, the reader or agent must consult the live calendar again rather than treat these next dates as current.

The count exposes a second failure mode. The third-party calendar's prose and Scottish table omit Monday 15 June 2026. The Scottish Government's own calendar records it as a one-off World Cup bank holiday; its update history says the confirmation was added on 5 February 2026. The GOV.UK JSON feed includes that date too. We checked the page's accessible explanatory text and static table, not whether its interactive “next holiday” widget updates correctly.

Why are search snippets and result dates not enough?

Search results solve a discovery problem. They do not, by themselves, verify the sentence an agent is about to write. Google's description of its own search process distinguishes crawling, indexing, and serving results, and says not every discovered page is crawled or indexed. That description is specific to Google; the holiday search above was conducted in Brave.

Google also says its snippets are automatically selected previews of page content, sometimes informed by a page's meta description, and can differ by query. Its displayed byline date is an estimate based on several signals about when a page was published or significantly updated. Neither is a certificate that every claim in the page is true today. Other search interfaces may construct results differently, but an agent should still check the opened source before citing its contents.

There are three distinct dates in a time-sensitive answer: when the event applies, when the source changed, and when the agent checked it. Here, the special holiday fell on 15 June; the Scottish Government says it updated its page on 5 February; we checked the record on 24 September. Collapsing those into a single “freshness” date makes a stale calendar look safer than it is.

How should an agent verify a web search result?

Locate the exact statement on the opened page, trace it to the publisher responsible for the fact, check its effective date and scope, and cite the supporting passage or data field. If the original record contradicts the result, surface that conflict before giving an answer.

For bank holidays, government calendars are the appropriate starting point because the relevant authorities publish the schedule. For a software release, that might be the project's release record. For a scientific finding, it may be the paper and its underlying data. “Primary source” is a relationship between a particular claim and the party responsible for it, not a badge permanently attached to a domain. Nor does an official page become infallible: if two authoritative records disagree, the agent should name the disagreement and investigate it.

In this case, a reviewable trail looks like this:

1. Define the question. Establish the as-of date and the relevant nation. If the user does not specify a date, use the date of the request; if the nation is unclear, give the region-dependent possibilities or ask rather than silently choosing one.
2. Open the result. Read the calendar's claim on its actual page, not only its search snippet or a generated summary. The third-party page's “nine” was present in its accessible prose.
3. Find the source of record. Open GOV.UK's separate regional lists and JSON events. Count Scotland's entries dated in 2026; there are ten, including the June event.
4. Check the change. The Scottish Government's dated update explains why the June holiday appears. This confirms the event in a second official record; it does not turn two government pages into independent witnesses.
5. Preserve the evidence. Record the exact event and date, regional scope, both URLs, the 24 September retrieval date, and the stale third-party claim. A citation to the top-level domain alone would make the disagreement difficult to inspect.

For a programmatic check, the GOV.UK feed contains separate england-and-wales, scotland, and northern-ireland divisions. Read the events for the chosen division, filter on the year or dates requested, and compare a candidate answer with the event's title and date. The feed supplies event dates; the time the agent fetched it must be recorded separately. A successful HTTP response or a matching page title is not proof that the answer was extracted from the right regional list.

What makes a citation support an answer?

A link can be real, reachable, and still fail to support the claim attached to it. The ALCE research benchmark therefore evaluates answer correctness and citation quality separately. In its ELI5 evaluation, the authors report that even their best evaluated systems lacked complete citation support half the time. That is a finding about that benchmark and those systems, not a general failure rate for web-search agents.

Our holiday example is simpler but has the same structure. Linking to GOV.UK after saying “the next UK bank holiday is 30 November” would not save the sentence: the date applies to Scotland, not England and Wales or Northern Ireland. Linking to the third-party calendar for “Scotland has nine bank holidays in 2026” would accurately attribute a sentence that is nevertheless contradicted by the source of record. Citation, support, and correctness require separate checks.

The answer we could actually defend was: “As of 24 September 2026, in Scotland the next listed bank holiday is St Andrew's Day on 30 November 2026. In England and Wales and in Northern Ireland, it is Christmas Day on 25 December 2026.” That answer names the region, the as-of date, and the official schedule. It should be refreshed before someone relies on it later.

When should the agent stop searching?

More hits are not always better evidence. A sensible stop rule is to answer only after the agent can say:

• What exactly is being claimed? State the place, period, unit, version, or population that makes the claim testable.
• Who can establish it? Prefer the source responsible for that fact; distinguish its record from a copy, commentary, or a search preview.
• Where is the supporting material? Point to the event, passage, or data field, not a loosely related homepage.
• When was it checked? Preserve the retrieval date and the source's relevant effective or update date when available; recheck facts whose value can change.
• What remains unresolved? If authoritative records conflict, the page is inaccessible, or the question omits a decisive condition, give a qualified answer or ask for clarification instead of manufacturing certainty.

These are checks on evidence, not a demand for an arbitrary number of sources. One issuing record may settle a narrow official-date question. A disputed scientific or historical claim may require substantially more work. The editorial methodology explains our source checks; the industry-search case study applies them across different kinds of records.

Research note: This article records a manual Brave Search query and direct checks of the linked pages and GOV.UK's JSON feed on 24 September 2026. Search ordering and third-party page text can change. The dated holiday example is a snapshot, not a live holiday service or a comparative test of search engines.