Can an AI Agent Trust Its Web Search Results? Search, Fetch, Citation Audits, and Real Cost

The expensive failure in agentic web search is not always retrieving nothing. It is retrieving an outdated or inapplicable page, generating a confident answer, and attaching a genuine URL that does not support the claim. An HTTP 200 response with ten search hits establishes retrieval availability, not factual correctness. A production agent needs a verifiable sequence: find candidate pages, fetch supporting text, identify evidence, decide whether the evidence answers the precise question, generate bounded claims, then check each important claim against the cited span. The choice of search provider matters, but the evidence contract survives changes in providers and models.

Two product interfaces, two different responsibilities

Figure 1. Search discovers sources, Fetch obtains evidence, and Answer requires separate citation validation; this is a conceptual diagram, not a measured API run.

DeepSeek introduced its own Search and Fetch APIs on October 17, 2026. Search returns structured web results; Fetch retrieves a single web page as Markdown. The documented endpoints are POST /v1/tools/search and POST /v1/tools/fetch. Search takes query, count (1–50), optional original-question context and content flags, and returns URLs, summaries, optional content and provider-defined authority and rerank scores. Neither authority nor rerank_score is a calibrated cross-provider truth probability. Publication dates may be unavailable and content extraction may fail. It is risky to treat any of those fields as equivalent to a verified source. Official Search & Fetch reference · October 17 changelog

OpenAI’s Responses API web_search offers a more integrated workflow: a model can search and construct an answer, while the response exposes web-search call records and URL citation annotations. Developers can request further source information, and the official guide expects links cited to end users to be visible and clickable. That removes some orchestration work, but does not remove the need to check whether the linked page actually supports the exact sentence. A single DeepSeek Search request and a complete model-generated web_search answer include different units of work; comparing their quoted per-call prices would confuse retrieval with synthesis. OpenAI Web Search guide

The first architectural decision should therefore be whether the application owns Search → Fetch → Evidence Selection or delegates more of the workflow to hosted model search. Research and regulated document workflows may need controllable raw evidence and repeatable provenance. General user-facing Q&A may value an integrated tool. Both need explicit claim validation and a meaningful abstention path.

A URL locates a source; it does not prove a claim

Figure 2. Claim-level citation checks must verify the supporting excerpt, not merely the existence of a URL.

Suppose a user asks whether closing a framework issue proves a bug is fixed. A search provider may surface the GitHub issue with the state “Closed.” A grounded answer must examine the state reason, duplicate links, referenced commits, release notes and exact affected platforms. Closing an issue as a duplicate is not proof that any release contains a fix. Likewise, a vendor announcement might say a filesystem race was addressed on Linux and macOS while Windows remains partly exposed. Citing the release headline and declaring all platforms fixed is still a citation error.

For each material assertion, retain a claim identifier, source URL, final URL after redirects, supporting excerpt, retrieval timestamp, document version where available, content hash, and verification status. The document’s date and the crawler’s fetch date are distinct fields; unknown dates must stay unknown. The audit question is not “Did we include links?” but “Does this specific excerpt support this specific assertion, with its time and platform qualifiers intact?” When reliable evidence is absent, contradictory or blocked, a system should state the uncertainty and explain what would resolve it.

Evaluate retrieval, extraction, and synthesis separately

A modest first-stage evaluation set can contain 30 bilingual questions, five per category: official API parameter facts, issues closed without a verified fix, bilingual entity ambiguity, time-sensitive release information, contradictory sources, and no-answer or access-restricted cases. This is a proposed test design, not a completed 30-question XBSTACK benchmark. Freeze expected evidence, eligible versions, acceptable answer conditions and abstention criteria before running any provider. Do not move the ground truth after inspecting its output.

At the Search stage, track Evidence Recall@5: how often a genuinely supporting source appears in the top five candidates. Include duplicates, language mismatches, broken links and missed official releases. At Fetch, record extraction success, status codes, final redirect destinations, content truncation and blocked sources. At the Answer stage, audit Claim Grounding Precision: the share of factual claims directly supported by their attached evidence spans. Report stale-source errors, unaddressed contradictions, justified abstentions, missing citations and end-to-end p50/p95 latency. With only 30 examples, publish individual failures and sampling limitations rather than declaring a universal champion.

Integrated Answer APIs need two tracks. Track A grades each provider’s end-to-end output. Track B feeds evidence from different search providers into the same answer model, so retrieval quality is less confounded with generation. Fix locale, query count, timeout, page budget and retry behavior; rotate provider order for fast-changing topics and preserve test timestamps. Third-party studies such as Artificial Analysis Search API Index and Parallel’s benchmark methodology are useful candidate-discovery evidence, but differ in datasets, judges, synthesis models and run dates. Their scores must not be represented as XBSTACK’s own numbers.

Cost per verified answer is the meaningful denominator

As documented on October 27, DeepSeek charges US $0.75 per 1,000 billable successful Search requests and US$0.75 per 1,000 billable successful Fetch requests. A Search qualifies only when HTTP 200 returns nonempty results; Fetch needs retrievable page content. The documentation notes a temporary no-charge policy for specified server-side harness tool calls with per-request billing scheduled to start November 1 Beijing time. Those are dated provider terms, not guaranteed future prices. DeepSeek billing documentation

For a clearly labeled hypothetical workflow with exactly one billable Search and three billable Fetch operations, the API-only arithmetic is (1 + 3) × $0.75 / 1000 = **$0.003 per answer**. That is not a measured invoice. It excludes model tokens, caching, retries, extraction failures, evaluation overhead and the business cost of incorrect answers. A better production metric is total actual spend divided by the number of answers independently verified as correct and grounded. A cheaper search result that repeatedly requires manual correction may cost more per useful outcome.

Failure types require separate operational accounting. Authentication failure, insufficient balance, fetching blocked by policy, inaccessible documents, rate limits and downstream timeouts are not a single “bad search” category. Do not blindly retry permanent 4xx errors. Bound retries for temporary faults, give each tenant an independent budget, and stop fetching once sufficient independent evidence has been found.

Source content remains untrusted data

Figure 4. Handle 403, 404 and 429 according to their cause; fetched pages must never grant tool permissions.

Fetched Markdown is third-party material. It can contain prompt injection, deceptive instructions to call tools, forged roles, URLs that redirect toward private networks, or a request to leak secrets. Even a legitimate-looking documentation page cannot authorize access to application environment variables. Tools accepting arbitrary URLs need enforced egress controls, scheme restrictions, credential-in-URL rejection, destination IP checks and revalidation after redirects and at connection time. For a multi-tenant agent, enforce user identity and resource authorization outside the model; provider relevance scores are not permission gates.

An auditable minimum pipeline is: sensitivity classification → query planning → Search → URL safety and deduplication → capped Fetch → evidence selection → answer generation → claim/citation audit → versioned caching and revocation. Logs should record source IDs, hashes, statuses, versions and counts without publishing user keys, private documents or sensitive raw queries. Cache records need fetch timestamps and expiration rules; stale evidence should be revalidated when official pricing, vulnerabilities, API schemas or release information changes. Otherwise a caching optimization becomes a persistent source of incorrect advice.

Debugging an unsupported citation: a repeatable evidence contract

A practical content advantage comes from explaining how an engineer can reproduce and classify a failed answer. Consider the question, “The upstream issue is closed; was the bug fixed?” It contains at least two claims: the issue’s current state and the version in which an actual code fix shipped. GitHub’s state_reason may support the first. The second normally requires a related pull request, release note and applicable platform/version information. If the ticket was closed as a duplicate, the evidence auditor should report the closure as verified while labeling the purported product fix unverified. Treating those statements as a single conclusion would manufacture certainty that the source does not provide.

A minimum proposed data contract, not a measured API result, is a ClaimRecord containing claim_id, source_id, final_url, retrieved_at, document_version, excerpt_hash, supported (true, false or unknown) and review_reason. Keep unknown as unknown rather than accepting confident model language as proof. Recheck the record when an authoritative source publishes a new version or its referenced URL changes; record the final redirect target and content hash so reviewers can distinguish a stale cache from a changed document. Low-trust source text must never be allowed to rewrite the tool authorization policy or the audit fields themselves.

Classify production search failures before retrying. An empty result set is different from a Fetch 403 access denial, a 404 missing source, a 429 rate limit, an unsafe redirect, a partial excerpt missing a qualifier, a stale release version or a genuine contradiction across primary sources. Respect access restrictions on 403 rather than seeking an unauthorized workaround. Retry 429 only within quota and a bounded backoff budget. For 404, locate the authoritative moved document rather than using an unrelated snippet. For contradictions, preserve source dates, applicability and unresolved claims instead of forcing the answer model to choose the smoothest explanation.

This focus is intentionally narrower than existing Chinese search-API comparison and how-to articles, or an evolving provider leaderboard. SourceBench illustrates why cited-source quality is a distinct assessment problem; 2026 research on AI-search citations examines how citation selection can be affected by content published on low-barrier platforms. These are external research results. XBSTACK has not independently reproduced their measured effects; the contribution of this draft is the actionable evidence contract and failure-classification protocol.

What this adds beyond existing tutorials and papers. Chinese developer guides already describe deduplicating pages, fetching body text and checking source references; academic work has also established that source credibility and answer support require separate assessments. An EACL 2026 paper evaluates search assistants’ source credibility and grounding, while Cited but Not Verified evaluates link accessibility, content relevance and actual factual support as distinct stages. Neither paper’s metrics are XBSTACK measurements. The defensible contribution of this guide is a developer-facing persistent ClaimRecord, linking each claim to excerpts, versions, retrieval timestamps, retry decisions and human review states. A worked synthetic case should be added before any headline suggesting tested end-to-end accuracy; until then this remains an engineering blueprint, not an independent performance benchmark.

What to choose, and what is still untested

For casual public Q&A, pilot an integrated Web Search service with visible citations and verify whether its cited spans support each important claim. For news verification, procurement, regulated analysis or enterprise research, owning Search → Fetch → Evidence offers finer control of provenance, contradictions and abstention. For a local-first personal knowledge app, external search should be a deliberate, permissioned option, not a reason to silently upload private source documents.

XBSTACK has not used paid keys to run matched DeepSeek, Brave, Exa, Tavily or OpenAI web-search calls in this review. There are no measured accuracy, p95 latency, retry or provider-cost results to report. Our contribution at this stage is a sourced technical architecture and a reproducible evaluation protocol. A future hands-on article must retain anonymized request/response artifacts, a frozen question set, exact SDK versions, judges and actual cost receipts before its title claims “tested,” “benchmark” or “best.”

FAQ

Can authority and rerank_score establish that a page is true? No. They are provider-specific retrieval signals, not a common calibrated probability that a claim is correct.

Does need_content=true eliminate Fetch? Not necessarily. Content may be empty, incomplete, inaccessible or stale. Verify important facts against an identifiable source span and its current version.

Why can a real citation still be wrong? The URL may be real, while the claim omits conditions, cites the wrong version or asserts something not present in the linked document.

Is DeepSeek necessarily cheaper than OpenAI web_search? Not from unit prices alone. Compare the full workflow cost per verified, correctly grounded answer under matched tasks.

Are 30 questions enough to name the best provider? No. Thirty cases are a practical error-discovery and regression starting point, not a generalizable product ranking.

Primary documents and prior XBSTACK content

• DeepSeek Search & Fetch official documentation
• DeepSeek October 2026 release notes
• OpenAI Web Search
• Artificial Analysis Search Index
• Parallel Search API evaluation method
• Related XBSTACK articles: Building an AI Research Agent, Tool Authorization Policy Gate, MCP Security

Topic path / AI Agents

Continue from one agent pattern to the complete production system

The AI Agent hub organizes architecture, memory, tool use, evaluation, security, deployment and multi-agent coordination into a single learning path.

Open AI Agent hub → Review the architecture guide Subscribe