Earlier this year, we introduced Microsoft Web IQ, a suite of AI-native web search and grounding APIs that gives LLMs, AI agents, and applications access to current, relevant web information. This post explores why web grounding is becoming a foundational layer of AI, how it helps deliver answers customers can use and verify, and how we’re addressing the quality, speed, and efficiency developers need.
—
When customers ask an AI agent or application for help, the answer may do more than inform them—it may shape a recommendation, trigger a workflow, or guide an action. If that answer relies on stale or incomplete information, the result can be ineffective or wrong. Agents therefore need evidence that reflects the customer’s situation: the latest product update, the relevant regulation, or the technical detail that determines whether a recommendation will work. They also need a way to check the evidence behind it.
Agents cannot act reliably on training-time knowledge alone. They need current, relevant evidence at inference time—when the model is answering the question or deciding what to do next.
Model knowledge has two structural limits
Models carry an enormous amount of knowledge in their weights, but that knowledge has limits in freshness and depth.
The first is temporal. A trained model reflects the information available during training. From its weights alone, it cannot reliably report what happened yesterday, what changed in a newly amended regulation, or what a competitor announced this morning. When its knowledge is outdated, it may still produce a confident answer.
Fine-tuning can incorporate additional information, but it does not provide a continuous connection to a changing world. An internal knowledge base addresses another part of the problem. Many customer questions also depend on information outside the organization: markets, competitors, standards, vendor documentation, public filings, and news.
The second limit is depth. Broad knowledge does not guarantee reliable coverage of every specialized subject. A model may explain a technology well while missing the version-specific documentation, local requirement, or niche industry detail a particular decision depends on.
Grounding helps address both limits by supplying current and specialized evidence at request time. The application can retrieve information relevant to the question and include it in the model’s inference context, rather than relying entirely on what the model learned during training.
That evidence also makes the answer easier to check. When the application preserves source information and connects citations to supported claims, users can inspect the basis for a recommendation. A support engineer can review the vendor advisory; a financial analyst can examine the filing. Grounding does not guarantee correctness, but it gives users a clearer basis for verification and expert review.
Grounding an agent is harder than returning search results
Traditional web search gives a person results to evaluate. Someone clicks, skims, rejects an outdated page, and decides which source is relevant before acting. That human judgment makes an imperfect ranking recoverable: the person can refine the search or disregard a weak result. An agent may use retrieved evidence directly to form an answer or choose its next action, raising the standard for what retrieval must deliver.
Agents can inspect multiple sources, compare evidence, and revise queries, but those behaviors must be deliberately built into the application and evaluated. Unlike human-facing search, agent grounding must consistently supply evidence that is fresh, specific, attributable, and usable within the model’s context window—without assuming a person will repair every retrieval mistake before the answer reaches a customer.
The evidence selected for the context window directly influences what the model generates. Missing context can lead to unsupported conclusions. Stale information can produce outdated recommendations. Excess material can increase processing cost and make relevant details harder to isolate.
For example, finding a page about a software issue is not enough to support a customer recommendation. The agent needs evidence about the right product and version, the conditions under which the issue applies, and any exceptions. It must then connect that evidence to the customer’s environment.
A grounding system must help the application select evidence the model can use, while preserving enough context and attribution for the answer to remain checkable.
Trustworthy agent action depends on quality, speed, freshness, and token efficiency
Once retrieval becomes part of an agent’s workflow, quality, speed, and token efficiency need to be evaluated together.
Quality determines whether the evidence supports a useful answer. It must be specific enough for the task and current enough for the decision. An accurate description of last year’s product may still be the wrong basis for answering today’s support question.
Speed determines how well the answer fits into the workflow. An agent may retrieve information, reason over it, identify another gap, and retrieve again. Delays in sequential steps add to the customer’s wait. Evaluate slow responses as well as typical ones, particularly when a task requires several retrieval calls.
Freshness determines whether evidence reflects the world as it is now. For time-sensitive questions, even accurate information can lead to the wrong answer if it predates a product update, regulatory change, security advisory, or market event. Evaluate both how quickly new information becomes available and whether results clearly indicate when sources were published or updated.
Token efficiency describes how much context the application needs to reach the required quality. A focused passage can supply the relevant detail without the unrelated content of an entire page. But trimming too aggressively can remove a qualification that changes the answer.
These constraints interact. More content may improve coverage while increasing cost and latency. Less content may reduce processing but omit the passage that matters. The engineering goal is to deliver sufficient evidence within the application’s time and cost budget.
The Pareto frontier describes the best achievable combinations: points where improving one dimension requires giving up something in another. Moving that frontier means improving a dimension without worsening the others. For developers, the practical test is whether a retrieval approach can improve answer quality at the same budget, or maintain quality with less time and context.
Web IQ brings external context to AI applications
We built Web IQ to help developers deliver better-grounded answers while managing the latency and cost of retrieving external information. Our AI-native web search and grounding APIs give models, agents, and applications access to relevant web evidence, with an engineering approach that treats quality, speed, and token efficiency as a connected problem. You can read more on our engineering approach here.
Highest grounding satisfaction. On a 3,000 query blind test sampled from production traffic, Web IQ scored 79.05 against 75.70 for the next best service and more than 14 points ahead of the lowest. It gets there by returning more complete, structured context drawn from web, news, images, and video. What your users see is answers that hold up: more accurate, more consistent, and properly attributed. In the domains where source quality, freshness, and attribution drive the decision, that is the difference between an agent people act on and one they quietly double check.
2.5x faster than today’s best alternative. P95 latency measured 164 milliseconds across five datacenter regions, against 406 for the closest competitor and 2,090 for the slowest. Latency compounds in agent workloads, because a multi-step chain pays the retrieval cost at every hop. Cutting it at each step keeps workflows moving and keeps interactive agents feeling interactive instead of batch.
Highest quality answers with the fewest tokens. Web IQ sits on a new Pareto curve of efficiency, reaching peak quality at around 40,000 tokens per query while competing services spend 60,000 to 100,000 to score lower. Prioritizing the most relevant passages and cutting unnecessary context reduces both token spend and reasoning time, and those savings compound across high volume production workloads.
Most web search APIs force a tradeoff — fast or accurate, cost-efficient or complete. Web IQ is delivers across the board: industry-leading quality, fastest performance, and fewest tokens per query — all in an enterprise-ready solution.
For teams evaluating Web IQ, those results provide a starting point. We recommend testing your own questions, sources, models, and end-to-end workflows to understand how retrieval quality and efficiency translate into customer outcomes. Grounding satisfaction is a benchmark score, not an accuracy percentage, and retrieval latency is only one part of the time required to complete a task.
Within Microsoft IQ, Web IQ complements Work IQ’s collaboration context, Fabric IQ’s business context, and Foundry IQ’s institutional knowledge with information from the web.
That combination matters when a question crosses organizational boundaries. An internal runbook can explain the approved response to an incident, while a vendor advisory supplies the new information needed to determine whether that response applies. Bringing them together helps an agent connect what changed outside the organization with what matters inside it.
Five questions to ask before you build
Choosing a grounding service means understanding how it performs on the information and workflows your customers depend on. We recommend starting with these questions.
- How current is the evidence for the questions my users ask? Test queries about recent changes. Distinguish when information was published or updated from when the retrieval system fetched it, and define acceptable freshness for each workflow. A product comparison and an incident response may have very different requirements.
- Does coverage reach the sources and details my domain requires? Broad web coverage and reliable retrieval from the specific sources your users depend on are different requirements. Test specialized terminology, product versions, local information, and hard-to-find documentation. Include questions that a general-purpose explanation would not answer.
- What is the total cost of a successfully completed task? Include retrieval calls, model input and output, retries, orchestration, and maintenance. Compare costs at the same quality threshold and model expected production traffic, not only pilot usage. A lower price per call can be misleading if the application needs more calls or more context to finish the task.
- Can users verify the evidence behind the answer? Check whether results contain usable source links and relevant metadata, whether passages retain necessary qualifications, and whether the generated citations support the claims beside them. Define how the application should respond when evidence is missing or conflicting.
- What will my team need to operate and govern? Identify who owns retrieval failures, freshness checks, source evaluation, and monitoring. Review authentication, data handling, content-use terms, and action permissions against your application’s requirements. Decide which responsibilities belong with your team and which you expect the service to manage.
Start with a question that needs an outside answer
Choose one workflow where external information changes the recommendation. Evaluate whether your agent can retrieve the relevant evidence, apply it to the customer’s situation, and explain the basis for its answer.
Get started with Web IQ knowledge bases:
Additional reading: