Who gets paid when AI assistants search the web

A procurement analyst wants to know whether a supplier has revised its delivery terms. The analyst asks an office assistant to check, and the assistant breaks the assignment into searches for a public announcement, the current terms and any notices that apply only to the analyst’s market. It may open several pages before producing a single answer. The organization buying the retrieval service can be entirely different from the person asking the question. The analyst sees an answer inside a workplace tool. The search company may see only an API request. The supplier that published the terms may see a crawler visit, or it may see nothing on the day the question was asked because an index already held a copy.

The company behind the answer

The example is hypothetical, but the buying arrangement is already recognizable. On November 5, 2026, 36Kr published an article by Qingyun that treated the opening of Tencent’s Yuanbao Search to developers, alongside moves by other Chinese technology companies, as evidence of a new commercial contest. The article describes an application that knows the full assignment and a retrieval service that may receive only a small piece of it. That separation changes who controls distribution. The application can choose where to search and which material to show. The retrieval supplier has to persuade a developer, procurement team or platform operator that its results earn a place in the application’s workflow.

For a person opening a search engine, the page can combine editorially ranked links, maps, other search features and paid placements. Google’s advertising help separates its organic results from advertising and describes ad placement in terms of bids and relevance. The same person can scan several titles before deciding what to open. A search API sells a different unit of service. Its immediate output goes to software, which may turn ranked documents into passages for a model, pass only a few through, or use an initial batch to formulate a more precise query. The API customer can be buying evidence for a business process that has no results page to monetize.

The distinction is easy to see when something goes wrong. Imagine that the office assistant finds a reseller’s copy of the supplier’s terms and attributes it to the supplier. A person seeing a list of results might notice the reseller’s domain before opening it. In a generated brief, the office application chooses whether to retain that signal and where to put it. If the citation is attached to a paragraph with several factual claims, the employee may struggle to see what the reseller’s copy actually establishes. The user-facing system is responsible for preserving the route back to the evidence. A retrieval provider can supply provenance fields, but the application decides how much of that provenance survives.

Buyers in this market can occupy several roles. An enterprise may pay for an assistant with search included. A software vendor may contract with a specialist and charge its own customers by seat. A cloud company may offer grounding alongside the model and calculate the return across its wider product. An application can also run an internal search service for company documents and buy external retrieval separately. The market consists of overlapping contracts, with the model acting as a tool user inside them. The phrase “selling to AI models” captures the change in the interface. The cash still moves between people and organizations with budgets, contracts and reasons to prefer one arrangement over another.

Those reasons start with the surface where the assignment begins. A browser tab leaves the original request visible to the search engine, subject to whatever the user types. In an assistant, a request can include a prior thread, uploaded material, or the prospect of a follow-up action. A deliberate application design can send the outside provider a short question stripped of that extra context. The retrieval provider can be commercially essential while seeing less of the customer’s intention. Its loss of context has a cost as well as a privacy benefit. If the application strips a country or date that determines which version applies, a good search engine can faithfully solve the wrong problem.

Aggregate usage figures offer an imperfect view of the change. Qingyun’s account pointed to close year-on-year movements in monthly time spent in two Chinese industry categories, search engines and generative AI. QuestMobile’s 2026 autumn research also distinguished use across AI-native apps, device-maker offerings and desktop clients. Time spent in a user-facing category and requests sent to a retrieval endpoint are different measures. One tells us where people spent time under the survey’s classification. An API invoice records a supplier’s billing unit. An application log can count assignments, and even that figure depends on what the developer calls an assignment. Similar-looking movements across categories cannot by themselves establish where an individual user went or how many background searches occurred.

The best evidence for multiple requests per question comes from systems that describe what they do. In its 2025 announcement about AI Mode, Google explained that the product can divide a question into subtopics and issue several searches in parallel. That is evidence of a product mechanism. A separate observation would be needed to estimate how often it runs, and a separate financial disclosure would be needed to assign revenue to it. One user interaction can represent several retrieval operations without creating several advertising impressions. The distinction matters to anyone who wants to infer a new market’s size from the popularity of a chat interface or from the price of a search package.

The office scenario also shows how earlier design choices shape the final bill. If the task is merely to locate a document the analyst already knows by name, one request might be sufficient. If the assignment asks whether the new conditions contradict a regional agreement, the application may need a separate internal lookup, a direct fetch of the new document and a way to reconcile versions. A model can attempt all of that in one run or put difficult cases into a human queue. The completed assignment becomes a better commercial reference point than the search box. A buyer needs to know how often the evidence was good enough to use and how much work remained at the end.

There is still a place for the search results page in this arrangement. The analyst may want to investigate an unexpected finding directly, and a consumer may prefer to scan options with prices or map locations visible at once. The interesting boundary falls within the same person’s day. A person can choose an assistant for a tedious comparison and a search engine for a quick visit to a known destination. Demand for delegated retrieval can grow alongside direct search. A provider may earn money from both while facing different competitive pressures in each. It can defend one position with a familiar destination and the other with fast access to material the buyer would struggle to assemble elsewhere.

An assistant can also create searches nobody would have performed manually. Picture a small research team that follows a handful of providers and reads their updates when time allows. A scheduled job could compare public release notes every morning and put an alert in a queue only when it finds a change the team cares about. Whether the team pays for this depends on the importance of those alerts and the reliability of the evidence, neither of which follows from the popularity of chat. The new demand is easiest to see in recurring work with a clear decision at the end. It is harder to defend when the output is a disposable answer that any of several products could generate.

The opening question for the search supplier, then, concerns the value of its particular contribution. Finding a public press release is cheap to imitate if every competing provider already has it. Finding a versioned document in an overlooked language, preserving the passage that defines an exception and returning it soon enough to prevent the wrong action is a different proposition. The provider that can prove this advantage may command a budget even without an audience of its own. Distribution, retrieval and evidence ownership now have separate prices to discover. China’s search companies offer an unusually clear place to watch that negotiation because the same groups can be content owners, model providers, search suppliers and distributors of the applications where people work.

Tencent brings public search into the office

A project manager preparing for a supplier review may have the last meeting transcript, a working document, and a new product bulletin issued overnight. The first two belong to the team’s workspace. The third may be available only on the supplier’s site. If an assistant can assemble those materials and revise the agenda in one pass, its value shows up in the finished work. Tencent can sell that finished experience and the retrieval behind it. As 36Kr reported, Tencent Cloud opened Yuanbao Search to outside developers in October, then Tencent introduced Buddy One to bring together several of its office applications around WorkBuddy.

The announcement came with concrete examples of what Tencent had tried internally. In a launch post on Tencent Cloud’s developer community, WorkBuddy used Yuanbao Search to locate technical documentation and official API material, which Tencent said reduced tool calls and model turns. The same post reported that combining knowledge base material with public web information in ima increased retrieval of useful sources by around 10 percent. The examples describe different outcomes, and the post gives too little detail to reproduce either comparison. They offer a glimpse of what an office vendor would measure, though. Extra results are only helpful if they contribute to work the user was already trying to do.

The public cloud product has a different shape from the assistant. Tencent Cloud describes a service that draws on public web resources and Tencent’s content ecosystem and sends ranked results back in structured form. It lists ¥14, ¥20, and ¥26 per 1,000 calls for its Fast, Standard, and Flagship versions. The higher tiers offer options such as more results and vertical search. The extra money buys a different set of retrieval controls and returned fields. Tencent can quote that product to a team with its own assistant while reserving the commercial benefits of a more capable WorkBuddy for its application business. A price for either product tells us little about the margin on the other.

Buddy One adds another piece that a search vendor cannot supply through an index. WorkBuddy’s product site describes a common identity for connecting applications and a membership with benefits across WorkBuddy, Tencent Meeting and Tencent Docs. Its support documentation explains which applications share an AI credit balance. Those links put retrieval in the path of an existing task, such as drafting an agenda from a meeting record. The initial Buddy One announcement was aimed at individual users. That distinction matters when extrapolating to companywide deployments, where access, retention, and audit requirements would depend on the organization’s setup. Even among individual users, an account link can make a large difference in how often the assistant gets used.

Suppose the project manager’s assistant finds two versions of the same supplier bulletin, one older and one current, alongside a meeting transcript accessible only to the procurement team. A good workflow has to resolve the dates, use the right version, and carry the answer into a document with the right audience. It may also have to leave some material out of the shared document. The search result and the permission to use it are separate facts. Tencent’s place in both retrieval and the office interface gives it an opportunity to handle those steps together. The scenario illustrates what deeper integration could accomplish. The launch material alone does not establish that Buddy One makes each of those decisions.

The office interface can also see results a retrieval API would have difficulty observing by itself. An assistant may have returned three sources for a technical question, but the workspace can potentially see that the user kept one citation, corrected a specification, and sent the resulting brief. Those actions give the application owner a way to distinguish a credible source from a result the model happened to rank first. Making use of that feedback would require appropriate access and a way to evaluate it without exposing private material. As a business advantage, the possibility comes from operating where the work is reviewed and completed.

Tencent can benefit when retrieval lowers the cost of delivering a completed task. A stronger result at the first attempt might spare a model another round of searching and reading. That could bring down the delivery cost even when the first call is more expensive. It might also make the task fast enough for a user to trust it with tomorrow’s work. The savings and retention effects remain hypotheses unless measured. They nevertheless explain why the owner of the workflow and an outside supplier can reach different conclusions about the same query. The workflow owner can evaluate it alongside generation cost and subscription renewal. The supplier mainly has its call revenue and the cost of delivering the result.

Tencent has a potential distribution advantage outside office work, too. Its own Yuanbao app listing advertises results from sources such as WeChat Official Accounts and Video Accounts, along with integrations across several Tencent services. That makes the coverage question more concrete than a comparison of index size. A research assistant tracking a Chinese industry may care whether it can find the relevant publisher in the venue where that publisher actually posts. The consumer assistant and the cloud API need to be evaluated separately. The app’s description is evidence about its consumer offering, and Tencent Cloud’s documentation is evidence about the API. A developer would still need to test which of the sources they need the API can actually return, and under what conditions.

For a supplier integrating the API into an unrelated product, that means assembling test cases around missing sources as well as obvious queries. A monitoring tool may have no difficulty finding the Chinese or English name of a well known company. It could still miss a niche supplier whose notices are posted under an abbreviated local name, or choose a widely copied summary over the publisher’s original. A useful benchmark would include documents that have moved, regional versions published at different times, and a handful of citations that the user should be able to open. Those cases would reveal whether a claimed coverage advantage survives contact with a real task.

A common credit pool could change the customer’s view of cost, too. If an employee pays for a membership that covers several applications, they might choose WorkBuddy for the next research task because their access and credits are already set up. Within the bundle, the vendor still has to decide how much work a credit buys and which costs belong to each application. A bundle makes the next task easier to start while moving cost allocation inside the vendor. That is commercially useful even if some of the work could be done with another assistant. A user who already stores notes, meets clients, and edits files in the same system has several reasons to give the assistant the next job.

The independent API still has a role even if Tencent succeeds with office distribution. A third party may want Yuanbao’s retrieval for a specific Chinese source set and use an entirely different application for the final task. Tencent can win that business without moving the end user to WorkBuddy. The interests of the two channels may diverge over time. The cloud team gains from encouraging easy integration by a wide variety of developers, while the office team gains from having an experience rivals struggle to reproduce. Whether Yuanbao becomes a common input outside Tencent, or mainly strengthens its own applications, will turn on what customers can verify about the API and what they can accomplish inside the bundle.

Baidu and DeepSeek put separate prices on evidence

Baidu is selling a trial big enough to reveal the shape of a workload. Baidu AI Cloud’s offer, running from October 30 through December 31, lists the Enhanced search API at ¥4.90 per 1,000 calls, against a stated list price of ¥40. The campaign caps discounted Enhanced usage at a cumulative one million calls and applies list pricing above the offer. Its Flagship price is ¥9.90 per 1,000 calls against ¥72, through an invitation channel. The price after the cap belongs in the buying decision from the first test. At one million Enhanced calls, the promotional price works out to ¥4,900, while a million at the listed rate costs ¥40,000.

A lab test with that many calls can look different from a launch. Consider an assistant that collects fresh public notices for customers every business day. During a trial the team may run the same tasks against two suppliers, record which results overlap, and add extra searches to understand gaps. Once it has customers, it may be able to reuse a verified notice across several accounts. It may also discover that checking for corrections uses more calls than expected. Raw test volume would then be a poor estimate of steady demand in either direction. The team needs to know how many retrieval calls turn into accepted work and how variable that ratio is.

Take a hypothetical monthly workload of 200,000 completed monitoring tasks that each need five Enhanced calls. The result is one million calls, so at Baidu’s posted rates the search cost for a task would be ¥0.0245 during a qualifying promotion and ¥0.20 at list price. Neither figure includes the model, document extraction, failed work, or a person’s review. The task is the unit the customer can compare with a subscription or an employee’s time. If a more capable service gets each task done with two calls instead of five, the comparison can flip even when the sticker price per call is higher. The numbers are illustrative and say nothing about the search pattern of Baidu’s actual customers.

Baidu’s pitch also reaches beyond fetching a single web result. The campaign describes retrieval across web pages, images, and video, with options for summarization and knowledge base access. A developer might use broad web results to find a distributor’s latest manual and then use its own document tools to verify which product revisions the manual covers. Another customer might want a managed service that prepares more of the answer. The two customers are buying different amounts of the job. Vendors can use tiering to distinguish a plain result feed from better control or assistance with synthesis. A low first price can be rational if it prompts testing of additional features that the eventual buyer actually values.

Baidu’s own financial disclosures help explain the incentive to try. For the second quarter of 2026, it reported ¥13.1 billion in online marketing services revenue for Baidu General Business, down 19 percent from a year earlier, and ¥7.3 billion in AI cloud infrastructure revenue, up 50 percent. The company uses different groupings for those lines, and they cannot be treated as a clean transfer between the two activities. It did not break out search API revenue there. Still, the company has a substantial advertising business under pressure and a cloud business with a reason to offer more tools. The API provides a way to sell something drawn from its search work to applications that might never send a user to a Baidu page.

A promotional purchase could also uncover demand that an advertising business has never served. An agent tasked with following hundreds of permits, public procurement notices, or product amendments can query while a person is asleep, then ask for help only when something changes. If many queries return no relevant change, the buyer still values the monitoring service as long as it reliably catches the events that matter. That kind of demand pays for dependable checking over time. It does not require the end user to be in the market to click on a result each morning. Its commercial viability depends on how efficiently the agent can narrow the monitored sources and schedule the checks.

DeepSeek shows that a model company can make a similar move from the other direction. In its October 17 model release announcement, it opened Search and Fetch APIs that it says use its own engine. The pricing page lists each at $0.75 per 1,000 successful requests. Search finds candidate results and Fetch retrieves content from a specified URL. The release also said billing for Search and Fetch through its server-side tools in DeepSeek Harness, Claude Code, and Codex would begin at 4 p.m. UTC on October 31. A model company now has a price for supplying evidence separately, and the separate endpoints allow a developer to integrate retrieval without treating it as an inseparable part of model inference.

This puts pressure on simple comparisons. DeepSeek’s prices are denominated in dollars, Baidu’s in yuan, and their published units give different information about the scope of a call. An agent that searches once and opens three pages has made four billable operations at DeepSeek’s rates, or $0.003 per task for those successful requests. The bill rises again if it reformulates the query or fetches additional pages. Search results that already carry enough evidence may require fewer page opens, but verifying a precise statement can still require the original page. A comparison that counts search and omits page access leaves part of the workflow unpriced. Differences in source coverage, return fields, and success criteria matter as much as conversion between currencies.

DeepSeek’s own pricing highlights another feature of buying search from a model platform. Its Flash and Pro model prices are billed by token and differ between peak and off-peak hours, while its two standalone retrieval APIs carry published rates per successful request. A business might schedule a daily monitoring run for off-peak hours and reduce the model portion of its bill. Search would then make up a larger share of that bill for the same work, even if the retrieval price never moved. For an interactive assistant the customer may have little tolerance for deferring a query. The weight of search in the bill depends on the timing and design of the application.

Even a clean price per successful request can hide a useful distinction. A technically successful search may return nothing a customer can cite. A response may also include a result that appears relevant but comes from a mirror that missed the latest correction. The API bill describes the success of the request as the provider defines it. The buyer needs a separate measure for the success of the research. A trial can track how often the system delivers a usable source on the first attempt, how often it catches a known correction, and how much it spends looking for material that goes unused.

For a large buyer, the decision after testing might be to route requests across multiple engines. A service could use a lower cost provider for routine checks, a second engine to cover hard to find Chinese sources, and direct page fetching to confirm evidence before issuing an alert. Doing that well requires an evaluation set and careful handling of errors. Firing requests at both engines all the time might erode any savings and add duplicate context for the model to read. Baidu’s promotion makes it cheaper to gather the evidence needed for such a decision. DeepSeek’s standalone rates give the buyer another benchmark. The longer test is whether either can win repeat work at a rate that covers the service and leaves a sustainable margin.

Alibaba and ByteDance make search easy to buy with a model

A developer putting together an assistant often chooses a model platform before testing a search supplier. The first version needs an account, an endpoint, and a reliable way to turn a prompt into a response. If current web information can be added in that same environment, a team can get a working prototype with fewer new decisions. The first working integration can become the benchmark for every other supplier. Alibaba Cloud’s Model Studio gives developers ways to enable web search for supported models. ByteDance’s Volcengine documents ways to add Doubao Search to model requests in its Ark platform. Their advantage starts with being available where the developer is already working.

Alibaba’s documentation describes several levels of integration. For applicable models and interfaces, developers can enable web search and choose among strategies that trade off speed, depth, and cost. One documented strategy has the model and search tool run in multiple rounds. Alibaba also describes a search tool on its Responses API for models that use that route for agent-style retrieval. The feature and its controls depend on the selected protocol and model. DashScope, for example, documents options for returning search sources that do not carry over identically to every compatible interface. A developer may be able to move an ordinary prompt between providers with small changes and still face work moving the evidence trail.

The difference between a configured default and an automatic action matters here. A team using Model Studio can choose its supported model and tool, and the request can then delegate decisions to the model according to the interface and search strategy. Qwen Code’s documentation also describes conditions under which its built-in web tool is registered by default with supported Alibaba-backed credentials. Its default permission mode asks for confirmation on the first search. Availability and permission govern different steps. The tool can be conveniently available while the user or developer still controls whether it runs. A buyer comparing adoption across products needs to know what has actually been activated, invoked, and billed.

Volcengine’s Ark documentation presents Doubao Search Custom and an online content plugin as separate choices. Custom can be used through several interfaces, including Responses, Chat, and Messages, while the plugin is documented for Responses. Developers are told to activate the relevant component first. In the Chat API, the documentation says that with a supported model and appropriate configuration the model can choose to search and then continue generating. It also describes a rule where custom tools take priority over built-in search if both are supplied. That detail matters to anyone building an alternative route. Whether a fallback can coexist with a built-in tool depends on the actual request path and tool policy.

ByteDance also has a route through the buyer’s existing budget. Volcengine documents an enterprise Agent Plan in which administrators can enable Doubao Search to draw against the plan’s included allowance under the applicable rules. A search provider that fits an approved budget can get used before a separate purchase is even considered. The integration advantage can persist after a prototype ships. The platform’s familiar credentials, billing view, and access controls may save the organization an integration review for an additional vendor. Those advantages have a limit. A shared invoice or an included allowance says little about whether a service finds the authoritative source for the task, and different products can still carry separate fees or limits.

Consider a product team building an assistant that updates internal release notes when a major software dependency changes. In a first version, built-in search can be good enough to find an official blog post for the best known libraries. Later the team may need to recover version-specific changes from a documentation site, notice edits to a changelog, and show which lines support the proposed update. It may also need the assistant to report that the source is inaccessible or that two sources disagree. The threshold for keeping a built-in tool rises as the cost of a wrong update rises. Moving search out of the model platform can then give the team a way to recover the necessary sources and handle uncertainty.

A developer testing that change needs a record of the work that each service performs. One platform might collect several search results in a managed tool call, another might expose each query and page fetch, and another might hand the model a summarized result. The engineer cannot assume that the call count describes the same amount of work. Comparing elapsed time and per-task spend is useful, but a high consequence workflow also needs a way to replay an answer. That could mean retaining which URLs were seen, which document versions they resolved to, and how the system handled results it was unable to open. A usable evidence trail can justify a separate supplier even with a higher invoice.

The incentives for the model platforms follow from this ordering. A platform that helps a customer get the first version working can sell more inference as the application grows. It can also earn separately from tool use and from the services the customer adds around it. A company selling only retrieval needs its own invoices to support the cost of acquiring and serving that business. Still, it can earn a place by solving a problem that the general model platform only partly addresses. Imagine a buyer whose agent needs to find regional standards and regulatory publications, retain stable citations across model changes, and trace evidence to a particular release. Those requirements make the quality of retrieval easier to define and price.

A technically portable model endpoint can still leave a team dependent on its provider for evidence. Prompt syntax and response objects are only part of the integration. Switching may affect whether a response includes source identifiers, how domains and dates are filtered, and how the service records that the model searched. Conversely, a developer that adds a search provider at the application layer can preserve its own policy across model changes, at the cost of operating the routing, access checks, and evidence store. The tradeoff is easiest to see when an enterprise regularly moves tasks between models for reasons of quality or cost. The cost of owning the extra layer can pay off if each model switch would otherwise mean rebuilding it.

Tencent’s office bundle, Baidu’s campaign, DeepSeek’s separate endpoints, and the Alibaba and ByteDance tools are different ways of competing for the first purchase. Once the agent is in use, the next purchase depends on who has the information to judge it. The office platform may see whether an answer makes it into a document. The application developer may know whether a check avoided a costly error. The search provider sees the requests, their results, and the pricing it can sustain. The bargaining power sits with whoever can connect evidence quality to completed work and change the route when the numbers move. Chinese suppliers are already selling several distinct ways to make that connection.

The search begins with a plan

A question about whether a city will close its river crossing next weekend looks like one lookup. A search system may have to identify the crossing, turn the relative date into a calendar range, locate an official notice, and find out whether that notice has been superseded. A useful answer also has to separate a closure of the bridge from a restriction on the streets that feed it. In a system that delegates searches to a model, the first decision is which evidence to seek. A model that searches the city name and the phrase “bridge closure” may find excellent coverage of the wrong event. The rest of its work will then look orderly while proceeding from a mistaken premise.

Google describes a version of this process in its documentation for AI Overviews and AI Mode. It says these features may use query fan-out, issuing related searches across subtopics and data sources to develop an answer. The qualification matters. The documentation gives an account of a technique that can be used, with room for different models, different methods, and different links across the two features. It gives publishers no fixed list of subqueries to target. Even for a broad question, a screen capture of the final answer cannot establish the searches behind it. An answer may cite sources from several branches of the research, compress one branch into a single sentence, and show no sign of other branches at all.

It helps to distinguish independent searches from follow-up searches. In the crossing example, checking a transport agency and a city works department can proceed in parallel. Searching by the project number, once a notice supplies that number, depends on the earlier result. A useful follow-up often trades the vocabulary of the question for the vocabulary of the source. A resident might describe a bridge “closing for the weekend” while the official notice calls it a temporary suspension of vehicular access and identifies the affected stretch by endpoints. The first document can supply the words that find the second. A planner that never revisits the wording of its query misses that chance even when it opens a relevant page.

The OpenAI API documentation makes some of these operations visible. Its web search response can report a search action and usually supplies the queries for that action. It also documents page opening and within-page search for reasoning models, separately from the annotations attached to the generated text. These are different observations about a run. A query shows what was sought. An open action shows that a page was opened. An annotation associates a source with an answer. The reader who sees only the annotation knows little about where the investigation started, and the developer who sees the search query still has to check what the final sentence says about the source.

Microsoft gives its own account in the web grounding tools overview for Foundry Agent Service. The agent identifies gaps and formulates queries, the tool submits searches, and the model works with the retrieved information to write a response with attribution. That description applies to the documented Foundry tools. It offers a useful comparison with the OpenAI API because both explain the handoff from a user’s request to a search, while the interfaces expose different evidence about the process. Product documentation is strongest at the boundary it names. The behavior of a developer tool gives only limited grounds for an inference about a consumer product carrying the same vendor’s name, especially when the consumer interface leaves its tool actions hidden.

Query decomposition brings a danger of its own. The imaginary resident who asks about “the crossing next weekend” may be referring to a ferry because of something said in an earlier turn. Searching for bridge, traffic, construction, and parking simultaneously can create a deep investigation of an entity the user never meant. One way to assess a planner is to ask whether its branches inherit the same binding constraints, including the location, intended entity, and dates. Breadth is useful after the scope is established. Where the identity remains ambiguous, testing alternative interpretations or asking for a place name may be more informative than spending the same search budget on variations of one guess.

Search selection is also a question of which uncertainties are worth resolving. Suppose a comparison asks which of several software editions supports a particular export format for unattended use. A branch for each edition makes intuitive sense. The decisive evidence, however, might be a permissions matrix applying across editions. A second distinction might turn on the difference between a button in the browser and access through an API. A planner that breaks the question down only by edition can assemble three versions of the same incomplete fact. A useful branch carries a reason for existing. It resolves a different condition, checks an independent authority, or seeks evidence capable of changing the answer already taking shape.

The 2020 paper by Patrick Lewis and colleagues on retrieval-augmented generation offers a way to understand what happens when external material enters a response. Its architecture combined a trained language generator with a separately accessible Wikipedia passage index. The paper distinguished information represented in learned parameters from information found through external retrieval. That distinction remains helpful even when a contemporary web tool uses a different architecture. Grounding at response time supplies evidence for that run. A live document can inform the text an assistant produces without implying a change to the model’s learned parameters. The original experiment describes one architecture, and the fact that a product cites web sources leaves plenty of its own architecture undisclosed.

The inverse problem is just as revealing. A model may give the correct answer to a familiar question without having fetched a source. It might also produce a current and correct answer in the presence of a browsing tool even if the tool contributes nothing decisive. From output alone, the investigator can often establish that an answer is correct and that a cited source backs it. The causal role of the source is a separate question. A run that succeeds without tools, a run that succeeds with tools, and a run that receives a known passage can expose differences under controlled conditions. One correct response leaves those explanations open. That is especially relevant to claims that a publisher’s page taught a system a fact.

Stopping is the least glamorous part of search planning. A broad search has to end while potentially useful evidence still exists. In the crossing example, a dated transport notice and an explicit update that confirms its status can justify ending the search, while two articles that merely repeat a preliminary announcement may justify another lookup. A system that treats both cases alike either spends effort repeating itself or ends before obtaining the deciding evidence. The stopping rule should follow the burden of the claim. A small factual lookup can close once the source is sufficiently specific. A comparison that depends on an exception or on a recent change deserves time to inspect the document where that exception or change would appear.

The practical difference between a good plan and a large plan is visible when searches disagree. A city calendar might list the closure as an event, an agency notice might identify the affected lanes, and a transit bulletin might give a shorter period for rerouted buses. Those are compatible pieces of evidence with different scopes. In a plausible poor run, the planner reads each as an independent estimate of the same timetable and commissions more searches to settle the apparent discrepancy. In a better run, the distinctions in the source determine the next query. Resolving disagreement starts by identifying the claim each document actually makes. The next task is to make sure those documents and their qualifications can reach the model in the first place.

The index and the page can tell different stories

A publisher can correct a figure on a page at breakfast and still encounter the earlier figure in a search-assisted answer that afternoon. That is a scenario, and the answer itself gives too little evidence to identify the failing stage. The older value might survive in an index, a cached response, a syndicated copy, or the material selected for the model. The assistant could also have found the corrected value and copied the wrong one from the surrounding text. Availability, ranking, and use are separate events. Treating the generated answer as a direct view of the publisher’s current page obscures the steps between publishing a correction and seeing it reflected in a response.

Google’s Search Central guide distinguishes crawling, indexing, and serving results. A crawler can discover a URL without visiting it. After a visit, the page can be processed without being included in the index. A page that reaches the index can still fail to appear for a particular query. Google also describes grouping substantially similar pages and choosing a canonical representative. That process matters when an investigator tries to trace a discrepancy across a page, a print view, and a near duplicate. Finding a live URL establishes public availability at the moment of inspection. Establishing which version appeared in a result requires evidence from the retrieval surface or a record of the version that surface exposed.

Candidate selection has another consequence that publishers rarely get to see directly. A ranking stage can reorder the items it receives, and the quality of that list depends on which candidates survived earlier choices. Microsoft’s Azure AI Search documentation supplies a worked architecture. It describes a hybrid setup in which text and vector queries produce separate rankings, and reciprocal rank fusion combines results using their positions in those lists. An optional semantic stage can rerank eligible results. A reranker works inside the pool passed to it. When a document disappears from that pool, a better judgment about its relevance at the later stage cannot bring it back. The Azure example explains the mechanics without implying that public answer engines share its implementation.

Lexical and semantic retrieval are useful in different ways. A search for an exact version identifier is a case where a rare string does much of the work. A search for a plain description of a problem may benefit from finding text that uses an unfamiliar synonym. In their BEIR evaluation, Nandan Thakur and colleagues tested retrieval approaches across eighteen public datasets and found that BM25, a lexical method, remained a strong baseline. In that comparison, reranking and late interaction performed best on average at greater computational cost. There is a cost to evaluating candidates more closely. The paper is evidence about the systems and collections it tested. It gives no basis for a universal ranking of modern web search products.

Search can return a useful extract even when more reading is necessary. Google’s Search Central snippet documentation says that search snippets are created automatically, primarily from page content, and can vary with the query. A snippet is useful for deciding which result to inspect. It may surface a direct phrase and leave the condition that follows it outside the visible text. Consider a page that gives an old figure in an account of a correction and the new figure in the next paragraph. An extract showing the former is perfectly capable of locating the page. Evidence sufficient to find a document may be insufficient to quote its finding. The distinction becomes critical when a short passage is the only text an assistant has been given.

Anthropic’s documentation draws a helpful line between its web search and web fetch tools. Web search brings back search results, and web fetch can retrieve content from a specified web page or PDF subject to its access and size rules. Both guides describe tool versions that can filter material before it enters the model’s context. A web address in a tool trace therefore invites further questions about what was requested, what was retrieved, and what was passed along for synthesis. Opening a document and exposing its decisive passage are distinct steps. The difference is easy to overlook when a source link makes both the search result and the full document accessible to the human reader.

There are costs on both sides of the extract decision. A narrow extract can strand a figure away from its year, unit, or population. Sending the whole document can surround the same figure with prior estimates, repeated headers, and appendices, all competing for the model’s attention. For a report with a table, the useful unit of evidence may include a row, its column headers, and a footnote qualifying the population. For a revised bulletin, the useful unit may include the revised paragraph and the note identifying which version it replaces. The smallest sufficient passage is defined by the claim. A phrase that looks easy to copy can still require its surrounding structure to mean the right thing.

Google’s recrawl documentation says that crawling after an update can take days or weeks and that inclusion in results remains uncertain after a request. That guidance concerns Google Search. It is a reason to keep several clocks separate when discussing freshness. Publication time, crawl time, retrieval time, and effective time answer different questions. A notice issued on Tuesday may govern a change that starts on Saturday. A source retrieved on Friday might still reflect Monday’s earlier notice. For a reader asking what applies on Wednesday, even the Tuesday document needs to be read with care. A date printed near the title establishes only the date it actually describes.

Live access is best understood as a property of a retrieval mode. OpenAI’s API guide documents a web search option that can use cached or indexed results without live access, alongside the default behavior of permitting live access for the documented tool. The two settings give evaluators a way to ask whether an answer needs a current fetch or can be derived from the available index. A run with permission to fetch live can still miss an update. The planner has to discover the relevant address and the retrieval path has to expose the changed passage. Distinguishing an as-of request from a generic question makes the test sharper. It also makes the expected answer easier to reconstruct after the page has changed again.

Language coverage has several layers as well. A model that replies in fluent English might have found and interpreted a source written in Polish. It might instead have relied on an English summary that left out a local distinction. Google lists language and location among the factors that can shape results in Search. The MIRACL project led by Xinyu Zhang provides a research example of evaluating retrieval across eighteen languages, with native speakers making relevance judgments over Wikipedia. Its design pairs questions and collections within the same language. Multilingual evaluation and cross-language retrieval test different abilities. A benchmark that covers many languages in separate same-language tasks leaves open whether an English query retrieves the best Polish primary source.

A multilingual audit can make that difference visible by asking comparable questions in each language and separately marking the language of the authoritative source. Imagine a municipal notice whose local name differs from the English name used in a travel guide. A query in English might retrieve that guide, a query in the local language might retrieve the notice, and an English query preserving the local place name might produce a third result. The facts of this hypothetical case depend on the same office and date throughout. Language, script, and entity naming deserve their own observations. A single score for translated answers can hide a systematic failure to reach the official text that users in one language can find easily.

Retrieval and answer quality need separate scores

A correct answer can come with the wrong citation. A wrong answer can sit next to a document that contains the correction. Either case becomes hard to diagnose when an audit records only whether a favored domain appeared. Give retrieval, use of evidence, and answer correctness their own scores. In a test of an effective date, the first score asks whether the decisive notice or passage was observable in the material returned. The second asks whether the answer attributes the date to evidence that supports it. The third asks whether the date and the conditions attached to it are right. A single number can describe success across all three, but it cannot tell a team where a miss began.

BEIR and BrowseComp illustrate different ways to define success. BEIR compares document retrieval across collections with relevance judgments. OpenAI’s BrowseComp asks browsing agents to find hard-to-locate facts and uses short, stable answers that can be graded comparatively easily. OpenAI explicitly notes the uncertainty about whether the scores carry over to the open-ended questions people ask. These tests measure different pieces of the job. Ranked retrieval can succeed when the answer generator misreads the best document. A final answer can match the expected string without establishing that the system reached the most authoritative source. An evaluation should borrow the design that fits its question before borrowing the prestige of the benchmark’s name.

Where candidate lists are visible, report both coverage and position. For a known reference set, recall at a specified depth measures the share of expected relevant items recovered among the first results examined. A rank-sensitive measure can also reward placing the most useful evidence early. Keep the depth and the definition of relevance explicit. A relevant document can still lack the decisive passage. A test about a software entitlement can mark the product overview relevant while separately checking for the edition and permissions text needed to settle the answer. In an open web test, the reference set is usually bounded by what reviewers have found. A newly surfaced primary source deserves adjudication, even if it was missing from the initial list.

The work of Nelson Liu, Tianyi Zhang, and Percy Liang on generative search separates two questions about citations. One is whether the answer’s claims are covered by supporting citations. The other is whether individual citations support the statements they accompany. Their audit of four systems belongs to the time and products studied, while the distinction travels well. Count unsupported claims as well as misattached sources. An answer can attach an impeccable source to one sentence and leave its most consequential assertion unsubstantiated. It can also place several citations after one assertion, with only one doing real evidentiary work. Counting links per response gives the second answer an apparent advantage even if the extra links make it harder to check.

A practical test starts with a modest set of questions whose correct answers reviewers can justify in writing. Draw cases from different tasks, such as a direct factual lookup, a comparison with an exception, a recently revised value, and a question whose premise the source contradicts. For each, save the exact evidence, the date or version that governs, and acceptable alternate sources. Decide in advance whether a partial answer deserves credit. Write the judgment rule before running the prompt. If the source says a service is available only to administrators, an answer that gives the correct service name but promises it to every user should receive less credit than a complete answer. That rule should apply across the systems being tested.

Comparability depends on the details of the run. Record the prompt and earlier turns, the product or API, the exposed model and search mode, the date and time, and the locale when available. A reply to a standalone question and a reply that inherits a product name from the previous turn belong in different conditions. A freshness claim needs a recorded clock and a saved source state, particularly when the page can change during testing. Repeat the same conditions before interpreting a change as a pattern. A second round in a fresh conversation can reveal whether the visible answer or sources vary, while a run after a documented update tests a different question about the timing of the evidence.

Observability should be scored too. A developer using an interface that returns search actions and source annotations can compare several stages of a run. An outside observer testing a consumer product may see only the answer and the links the interface displays. In that case, record the source as absent from the visible answer or present in its citation panel. An unobserved stage stays unobserved. It cannot be assigned a zero because the surface withheld the data. A third party may still score answer correctness and citation support from public output. It has fewer grounds to explain why a source was missing or to claim that the tool never considered it.

Controlled comparisons offer more traction when the interface permits them. Try the same question with search disabled, with ordinary search, and with an authoritative passage supplied directly. Success only with the passage makes the ordinary retrieval path worth examining. Failure even with the passage points attention toward interpretation, context, or prompt design. A supplied passage can still change the task enough to affect the model’s behavior for reasons unrelated to ranking, so treat the comparison as diagnostic evidence. Preserve the original conditions and vary one factor at a time where feasible. A test that replaces the source, adds instructions, and switches models in the same run has little power to identify which change mattered.

The hardest cases deserve separate reporting. A system may handle stable facts well yet miss effective dates in revisions, translate a headline correctly while misreading an exception in the original language, or give a strong direct answer while failing on a question with a false premise. Mixing these cases into one average makes it difficult to decide whether an improvement addresses the original failure. Show results by failure type and keep the denominators. Record ties, uncertainty, and cases that independent reviewers judge differently. The variation is useful evidence about both the system and the test. A dispute about whether a source sufficiently supports a claim can reveal that the rubric needs a clearer rule about scope.

A final report should let another reviewer reconstruct an important judgment from the answer, the evidence, and the conditions of the run. Preserve an example where the right material was retrieved and used, one where a relevant source was displayed without supporting the answer, and one where the output leaves the retrieval stage indeterminate. The distinction between failure and uncertainty is part of the finding. That record has more explanatory value than an assertion that one engine sees a publisher and another ignores it. It tells the next investigator what has already been measured and where new evidence would make a difference.

The Bing retirement changed what developers could buy

Microsoft set August 11, 2025, as the retirement date for Bing Search APIs. Its lifecycle notice said existing instances would be decommissioned and directed customers toward Grounding with Bing Search in Azure AI Agents. The distinction mattered even to a developer who intended to stay with Bing. A search integration could ask for results and decide where to send them, which ones to display, and how to use them. Microsoft’s recommended destination was a feature of an agent service that uses public web information to generate responses. A team with a search box or an evidence pipeline had a different migration on its hands from a team building a question answering assistant.

The grounding service puts some important decisions on Microsoft’s side of the boundary. Microsoft Learn says developers and users do not receive the raw content returned by Grounding with Bing Search. The documented response includes citations to the websites used and a link to the Bing query, with requirements for displaying both. A citation lets a user visit a source. It gives the developer much less to work with if the application needs to examine every candidate, resolve two conflicting passages, or apply a separate ranking policy before the answer is written. A migration estimate that counts only the time to replace an endpoint will miss the work of replacing those decisions.

Microsoft now points Foundry users starting out with web grounding toward the Web Search tool. Its documentation still identifies Bing grounding services underneath that tool. For the named Grounding with Bing tools, Microsoft documents that the query, tool parameters and resource key are sent to Bing and that the query and key pass outside the Azure compliance boundary. The guide also says the Microsoft Data Protection Addendum does not apply to data sent to the two named services. For a buyer, the relevant review is the actual journey of search data and the terms attached to that journey. The fact that the application already runs in Azure is only the starting point.

Consider an internal procurement assistant. The prompt might contain a project name and draft supplier terms alongside a request to check a vendor’s publicly announced shipping window. The project details belong in the internal workflow. The public lookup may need only the vendor and product names. If the platform makes the decision to search inside an answer generation step, the team should establish what information that step is allowed to turn into a query. With a separately invoked endpoint, the application can construct the permitted query before it sends anything. Both designs involve a handoff. Who controls the handoff determines where that policy can be tested and enforced.

Google has its own answer to the same commercial problem. Google Cloud documents Grounding with Google Search for Gemini Enterprise Agent Platform and describes the search suggestions that accompany grounded responses. When those suggestions are returned, Google requires them to be displayed in production. The same page says applications can offer alternatives and even make another search engine the default, while requiring non-Google results to appear separately from Google’s grounded results and suggestions. The product interface is part of the integration contract. A team designing a single blended comparison panel should review that requirement before it builds the panel around data that happens to be easy to merge in a test environment.

OpenAI’s web search guide illustrates a different boundary. In the Responses API, the developer can ask for the list of URLs that the model consulted, which can include more sources than the inline references selected for the answer. OpenAI also requires that citations be visible and clickable in interfaces that display web results or information derived from them. Access to that fuller source list helps a team investigate a response. A list of consulted URLs is still a particular form of access. A buyer should ask whether it meets the investigation requirement or whether the application also needs passage text, search candidates that the model passed over, or a record that can be reused by a different system.

Anthropic’s Messages API exposes domain allowlists or blocklists and lets the caller cap the number of searches through the web search tool. Its documentation distinguishes those controls from the settings in Claude Managed Agents, where the same search cap is unavailable. There is a practical difference between nudging the model in a prompt and imposing a ceiling on the number of searches at the tool boundary. The first is useful for intent, the second for budgeting or keeping a step within an interactive time limit. The comparison also makes it risky to buy on the strength of a product family name alone. The exact surface and deployment path can change the controls on offer.

The platforms also sell different combinations of work. OpenAI’s pricing documentation distinguishes web search calls from the search content supplied to the model, with the treatment of that content depending on the search option. Anthropic documents a separate search fee alongside standard token charges, and says retrieved results can count as input in later turns of a conversation. Microsoft’s Bing tools documentation counts grounding transactions by the number of tool calls in a run. The user sees one answer while the service may count several events. The difference matters when the buyer is comparing hosted search inside a model with a service that hands evidence back to the application.

The ease of buying search and generation from one platform has a commercial appeal beyond a quick demo. A support team that needs a grounded answer with working references might value a single product integration, a standard way to show sources and a clear owner for routine service issues. Paying separately for retrieval may mean another credential to rotate, another service to monitor and another support queue when a customer asks why a result changed. At the same time, coupling search with the model changes what a migration touches. A switch can affect the way citations render, which sources are eligible, how often the application searches, and what the finance team sees as a billable event.

That coupling becomes expensive if the same evidence is meant to serve several products. Imagine a price change that needs to appear in a live assistant, a dated monitoring record and a summary for account managers. A response written for the assistant may include a link and the right price but leave the other two products without the piece of evidence their workflow requires. A procurement team should distinguish permission and ability to reuse evidence from permission to show the answer once. Sometimes the right purchase is still the managed answer for the assistant, paired with separately approved retrieval for monitoring. Those two jobs have different owners and different definitions of done.

The lesson of the Bing retirement is narrower than a claim that standalone search is disappearing. Microsoft replaced the route it recommended to Bing developers with an agent grounding route. Other platforms likewise sell search inside a larger product, with different controls and display terms. The purchase decision starts with the service the application needs to survive a change of model, terms or endpoint. Keep that dependency visible in the contract and in the application design. A team that buys an answer should be able to evaluate the answer. A team that buys evidence should have enough access to judge the evidence before deciding which model will see it.

Independent suppliers sell different pieces of the work

An independent supplier gives a buyer the chance to put the retrieval contract beside the model contract. That separation makes it possible to test a search vendor against two models, replace one part of the stack, or send the same set of references into more than one workflow where the terms allow it. But independence is a description of the relationship between products. It says little by itself about who owns the index, where a supplier gets data for a given request, or who controls the final response. The supplier market is easiest to understand by asking what each endpoint hands over and where it stops.

Brave provides a useful case because it makes a specific, checkable assertion about its general search service. It says the results come from its own crawled and ranked index, with no fallback to another search engine. Its API offering spans familiar search results, an LLM Context endpoint and an Answers product. The company describes Goggles as a way to change ranking and choose domains. For a buyer, the value of owning the index is the possibility of a retrieval route that differs from the usual sources. Quality and coverage remain empirical questions. The company also says storage rights depend on the plan, a distinction with consequences for retained evidence and evaluations.

Exa’s packaging makes the depth of work visible in its price list. Its pricing page separates search modes, page contents, answers and agent work. It also lists web, people, company and scholarly works indexes, alongside Exa Connect access to specialist third-party data providers. Those are distinct propositions. A sales operations team looking for a company’s product pages has a different job from a research assistant looking for a paper, even if both begin with a short string. Specialist data access can be the reason to buy a service, especially where a general web result would leave the team to find and reconcile identifiers itself. The documented data offerings do not establish that every Exa result comes from a single corpus or collection method.

Tavily makes its billing unit a credit and sets different costs for search depths. The search endpoint also offers optional content and an answer, while Tavily documents extraction separately. A team can call the search endpoint to find candidate pages and reserve extraction for a small subset selected by the application. The same team might use a deeper search to avoid a separate step on harder questions. The commercial point is that the setting on the request can alter the quantity purchased even with an unchanged number of calls. Two teams with identical traffic charts can produce different credit bills if one regularly requests deeper work.

Parallel separates search and page extraction from deeper research in an asynchronous Task API. Its price page describes Search as returning pages and excerpts, Extract as retrieving page content, and Task as charging per successful run at rates tied to the processor chosen. It also lists a Responses API compatible with OpenAI’s interface. The handoff makes a difference in a job such as collecting evidence for hundreds of vendor profiles. A search endpoint gives the application material to process as it goes. A task product shifts more of the work into a run the application can collect later. The service’s successful run and the buyer’s accepted profile are separate events and should be measured separately.

Perplexity illustrates a similar separation and an unusually clear reminder that packaging changes. The documentation for its Search API describes ranked, structured results and gives examples for using the results with other model SDKs. It directs developers who want a generated answer with citations to its Agent API. In August 2026, Perplexity announced that the separate Sonar endpoints would retire on September 27 as it moved grounded generation to Agent API. The continuing distinction in the documentation is between search results for the developer’s own processing and a platform generated answer. A proposal that simply lists Perplexity without specifying which of those products it relies on conceals a decision the application will have to make.

The handoff each supplier documents

The table compares documented handoffs, without scoring quality or coverage. Two products described as search can return different amounts of material to the application. The amount of work the application still has to do may depend more on that difference than on the number of results.

Interoperability has at least two practical layers. A compatible interface reduces the work of sending a request. Parallel advertises an OpenAI-compatible Responses product, and Perplexity demonstrates its retrieval results with other model providers’ SDKs. Neither fact tells the buyer whether two services will return the same sort of evidence under the same conditions. A published date may describe the page, a last fetch may describe the crawler, and a recency filter may operate on information the supplier could infer. When a decision turns on whether a source is new enough, flattening all such fields into one date will remove a distinction that an evaluator needs.

A modest internal result format makes a substitute more practical. The application can carry the original source URL, a title, a passage if provided, the supplier and the time the application collected it. More specific fields, such as the date asserted by a publisher or the time the supplier reports fetching a page, can be preserved with their names and meanings intact. Mark missing information as missing. If a replacement returns only snippets where the primary supplier returned longer passages, the application can send that answer for review or fetch the page through an approved route. Silently filling fields from guesswork defeats the portability the adapter was supposed to buy.

Commercial differences remain after both APIs are made to fit the same interface. A replacement may accept the same query but offer a lower rate limit or reserve access to particular data for a different plan. The application may also depend on the right to store a result longer than the vendor’s ordinary plan permits. A sensible fallback test should therefore start before a service fails. Run the substitute through the whole task, including retention, output rendering and review, and check how it behaves at the traffic the failover is meant to absorb. A second API key is useful only to the extent that the alternate path actually works under those conditions. Also test how the application explains an incomplete result if neither service can supply the evidence. Leaving a field empty may be acceptable in a profile draft, while making a recommendation on the same incomplete record may require a different response.

Index ownership deserves the same precision. A company can expose a search API under its own name, provide a specialised index for one product, obtain data under license in another, and offer page extraction at request time. Those are different claims and can all be true of one supplier. Buyers evaluating a second source should ask which corpus or acquisition route serves the endpoint and mode they intend to use. It is reasonable to report Brave’s own statement about its general search index. A similar statement about every result from another vendor would require corresponding evidence. Useful output alone tells an evaluator little about whether two vendors share a dependency.

That matters when a fallback is purchased specifically to cover blind spots. In a trial, queries should include ordinary terms that both services are likely to answer and cases where independent coverage might pay for itself. A useful set would include newly published source pages, niche sites, and material from regions or languages that matter to the business. Compare the evidence each service contributes after removing obvious duplicates and copies of the same underlying announcement. A second route earns its keep when it changes the evidence available for the task. High overlap on easy requests says little about that benefit, while a handful of unusual results is insufficient to establish broad coverage.

The useful price is the cost per accepted task

A price per thousand searches is a sound unit for part of an invoice. Cost per accepted task is the more useful unit for deciding whether an application can make money or fit its budget. An accepted task might be a support response that cites the right version of a policy, a supplier record with enough evidence for a buyer to verify it, or an alert that reaches a customer while there is still time to act. Write that definition before collecting the cost data. Otherwise one service can appear to do more work because its API returns a response even when the application cannot use it.

Consider two fictional retrieval setups serving the same thousand support questions during a trial. The figures are invented for the example and are not vendor prices or performance measurements. Setup A sends two thousand billable search requests at a hypothetical five dollars per thousand, producing a ten dollar search bill. Setup B sends a thousand requests at a hypothetical eight dollars per thousand, producing an eight dollar search bill. The more expensive request produced the smaller search bill in this example because the application sent half as many requests. The volume is something to measure at the boundary where the vendor charges, since a single user question can trigger several billable events.

Now include model and extraction costs of thirty dollars for A and twenty-four dollars for B, with seven hundred and eight hundred accepted answers respectively. The measured variable costs in the example are forty and thirty-two dollars. Dividing each full bill by the corresponding accepted output gives about 5.7 cents per accepted answer for A and 4 cents for B. Those are costs for the items that met the shared quality bar. Both numerators include spending on the questions that failed. The example excludes staff time and standing costs to make the arithmetic legible. Add those where they influence the operating decision, and specify how shared costs were assigned.

The arithmetic can also favour the cheaper endpoint. If A’s two searches find the necessary document and B’s one returns long, loosely relevant passages that increase model spend, B’s apparent savings could disappear. Or B could pass a general accuracy check while missing a rule that tells the assistant to cite the policy in force on the date of a customer’s purchase. Success needs a test the business can defend, and the most useful test often turns on the weakest claim in the response. Adding new passages is helpful only when they improve that test enough to cover the cost of fetching, reading and checking them.

Terms such as request, query, call, credit and run should stay in their native units until the buyer knows what triggers each one. Tavily documents credit consumption by search depth. Parallel lists different billing units for search, extraction and research runs. OpenAI and Anthropic distinguish search activity from token charges in the relevant documentation. These examples explain why a buyer cannot convert every advertised unit into a uniform request cost by dividing by a thousand. Reconcile the application’s task log with the vendor’s usage record. Make sure a retry, an extraction request, and a call made during a subsequent turn end up where the price sheet says they belong.

Count labour with the same care. A hard case might go to a reviewer, who spends a few minutes locating the passage the search layer missed. An early invoice comparison will rarely include those minutes unless the application records the referral and its reason. A reporting team can assign an internal cost to review or record time alongside the cash figure where an allocation would create false precision. Escalations need a cost and an outcome. A case rescued by a human may count as accepted for the end customer, while still revealing a weakness in the automated route. If the reviewer remains essential as volume grows, the cost of that capacity belongs in the purchase decision.

Timing makes the same numbers look different to different products. A background research job can wait for a second retrieval pass if the evidence will be used tomorrow. A live assistant that keeps a customer waiting may have less room for extra requests, even if the extra calls add little direct spend. Define a delivery window with the success measure and record the slower end of the response time distribution alongside the average. An answer that arrives after the decision has passed is a failed task for a time-sensitive workflow. The appropriate window is a product choice, and should stay the same when comparing two implementations.

A trial should also isolate the work that each service adds or removes. Keep the question set, acceptance rules and available evidence reasonably stable. Compare search suppliers through the same model when the aim is to understand differences in retrieval. Then test the whole managed product if the buyer is considering a bundle that changes the model or how it searches. A component comparison and a purchase comparison answer different questions. Running both exposes a useful possibility. One retrieval supplier can be a strong component for an existing application even when another supplier’s bundled product wins the comparison for a new workflow with no integration already in place.

Bundles make the marginal price and the long term commitment worth separating. An existing contract may include unused volume, making the next thousand requests cheap to an application team. Renewal may be priced differently if that feature becomes the reason for a larger commitment. A pay-as-you-go pilot might be easy to leave but require separate systems for billing, access and incident reporting. Compare the incremental cost of the pilot with the cost of normal operation at the expected mix of workloads. If the purchase relies on credits or a volume tier, test a slower month and a busy one before interpreting the effective rate as a stable property of the service. Give engineering time its own line in that comparison. Paying a team to maintain two integrations can be worthwhile for a workflow that must remain available, but the cost should appear in the estimate.

Cache assumptions can also create imaginary savings. A help article may be safe to reuse for a short interval after the application has checked its version and confirmed permission to retain the material. A current availability question may depend on the minute, while a policy question could turn on the date at which the policy applied. Savings from reuse depend on freshness and rights, so a cost model should state which outputs can be retained and when they must be checked again. A cache that omits those rules can reduce measured search spend while quietly replacing fresh evidence with an old answer. The apparent savings then belong on the same ledger as failures.

There is a place for a simple price check once the task has been measured. A team can set a maximum price for a standard answer, define the cases that qualify for a more expensive route, and watch how often the application uses that route. It can also renegotiate capacity once the mix of calls, extracts and completions is visible. Buy the amount of search that changes the result, and keep the evidence of that change close to the bill. The invoice tells a buyer what the supplier charged for. The acceptance record tells the buyer whether the work was worth buying.

A publisher can supply the answer and lose the visit

A reader looking for the outcome of a council vote can leave a search page with a correct answer, while the reporter who attended the meeting sees no corresponding visit. A search service can retrieve the news story and an assistant can credit it. The sequence has worked for both companies and the reader. The publisher has supplied an input without necessarily acquiring a reader. That distinction is easy to miss when the word referral gets used for both a visible link and a person following it. The separation matters most when a search intermediary earns money for finding the story, while the publication relies on what happens after a human arrives.

Pew Research Center put numbers around one version of that gap in July 2025. It analyzed the March browsing histories of 900 U.S. adults on tracked devices, using 68,879 unique Google searches in the analysis. Traditional results received a click on 8% of visits to pages classified as having an AI summary, compared with 15% of visits to pages without one. Links in the AI summary received a click in just 1% of visits to pages classified as having a summary. The 1% denominator is visits to pages with summaries. It does not represent the share of readers who clicked any Google result, the share of AI traffic going to news or the traffic loss of the typical publisher.

The researchers determined which searches showed summaries by rerunning queries in April, several days or weeks after recording the March browsing. That means the search page observed by researchers could differ from what an individual saw, including whether an overview appeared and which links were in it. They captured up to three source URLs from each summary and attributed a destination appearing in both the summary and ordinary results to the summary. The study inferred clicks by matching the next visited address to the reconstructed results. The figures describe observed browsing with a reconstructed result page, a useful but bounded way to investigate a product that can change between two visits.

The two classes of searches also differed before anyone clicked. Pew found a summary for 8% of searches with one or two words, compared with 53% of searches with ten or more. A short search naming a newspaper often expresses a different intention from a longer question about a city ordinance. Some of the gap could reflect that difference in intent, and some could reflect how well the result page settles the question. Even a stronger causal estimate for one product would need a new test before it could be applied to conversational AI search or to an autonomous agent. A March Google browsing panel cannot describe every form of machine search.

Three measures of publisher exposure

The measures observe different parts of distribution. Pew follows people from a results page, Chartbeat counts traffic publishers received, and the Tow Center checks whether a test answer can name the source. Their findings can all hold even if the number of citations shown to users increases.

By October 2026 the Reuters Institute for the Study of Journalism was reporting a 40% decline in Google Search referrals from July 2025 to July 2026 across hundreds of publishers, citing Chartbeat’s annual playbook. Chartbeat’s public preview separately gives a two year change in the share of pageviews coming from Google Search, from roughly 9% in July 2024 to 5% in July 2026. A referral volume and a share of pageviews can move differently when traffic from other channels changes. The figures also cover different periods. Read both as evidence about a measured publisher cohort. Neither observation isolates the effects of an answer box from ranking changes, differences in news demand or shifts in the composition of the search audience.

Google offered a different view in August 2025. Its head of Search, Liz Reid, said aggregate organic clicks from Google Search to websites had been relatively stable year over year and described clicks as higher quality when users were less likely to return quickly to Search. The statement concerned the wider web and an earlier period. A gain for product pages, forums or videos could offset a loss for news in the aggregate. A lower rate of outbound clicks per search can also coexist with stable volume if the number of searches rises enough. A click that satisfies a platform’s quality measure still needs to earn its keep on the destination site. A subscriber signup, ad impression and repeat visit each have a different value to a newsroom.

Attribution introduces a second break in the chain. In a March 2025 report for Columbia Journalism Review, the Tow Center for Digital Journalism tested eight tools with live search using excerpts from ten articles at each of twenty publishers. The researchers chose excerpts for which a traditional Google query put the original article in the first three results. They asked the AI tools to identify the story and assessed the article, publisher and URL in each response. The tools gave incorrect answers to more than 60% of the 1,600 queries. The study documented fabricated links and instances where tools cited a syndicated or copied version. These were tests of source identification on a deliberately chosen task, so their error rate cannot be read as a current universal rate for AI citations.

Even a faithful citation can direct a person to the wrong page for the job at hand. Suppose a city housing story cites a budget table, a tenant’s account and a specialist’s interpretation. An assistant may link to the budget while drawing on the reporting to identify which entries deserve attention. A user can verify the dollar figure at that link, but the publisher whose work put the figure in context gets no credit there. A citation to the story alone can have the opposite shortcoming if the question calls for the primary document. Attribution quality depends on the claim the citation is meant to support. A publication should care about both where credit goes and whether the link allows someone to test what the answer says.

An agent widens that separation. A person scanning a search page can decide a source looks interesting and open it. A procurement agent asked to update a private spreadsheet may extract evidence, store a source reference and finish without ever displaying a link to a person. Its caller may pay for both search and page retrieval. The origin server might log a request, and a human session might never begin. Machine retrieval can carry economic value even when it produces no measurable audience acquisition. The benefit to the reader or company commissioning the work can coexist with a loss of advertising inventory or subscriber opportunities at the source. The measurement challenge is assigning each event to the party it actually benefits.

Traffic patterns still matter to a publisher weighing its options. A local outlet should examine whether civic explainers previously led readers into a newsletter or whether its homepage and direct relationships already account for most membership. A publisher with highly seasonal traffic should compare election weeks with corresponding election weeks and keep an eye on a few recurring topics whose timing and appeal are easier to compare. Without those comparisons, an ordinary change in the news cycle can look like a platform effect. The traffic worth defending is the traffic that funds or advances the publication’s work. Once an outlet knows which visits do that, it has a better basis for deciding which forms of machine access it should permit, test or sell.

Publishers can set terms on some routes into their work

A newsroom that wants its reporting discoverable while limiting some reuse has several decisions to make. It can choose which crawlers it asks to stay away, which requests its servers actually reject, and which uses it permits in a commercial agreement. A crawler preference, a technical barrier and a licence do different jobs. The Robots Exclusion Protocol, specified in RFC 9309, describes how operators communicate crawling rules through robots.txt. The specification distinguishes those rules from access authorization. A publisher can give different instructions to different named crawlers, while genuinely restricted material belongs behind a control that checks who is asking and whether the request is allowed.

OpenAI’s documentation illustrates how those distinctions show up in practice. It describes independent settings for OAI-SearchBot and GPTBot, allowing a publisher to permit crawling for ChatGPT search while disallowing the crawler OpenAI associates with foundation model training. OpenAI says that an outlet opting out of OAI-SearchBot will be left out of ChatGPT search answers, although navigational links may still appear. It also says it may use a single crawl for both purposes when both bots are permitted. The product distinction depends on permission and use, even when a site sees a single request. Operators assessing compliance need to know what each request represents and what the recipient says it will do with the contents.

The documentation describes ChatGPT-User separately. That user agent may visit a page in response to a user action, and OpenAI says robots.txt rules may not apply to such requests. It points publishers to OAI-SearchBot for managing the search opt out and automatic crawling. A request on a user’s behalf is a separate access path. A publication checking whether its subscription gate works should test what a request can actually retrieve under different access conditions. The presence of a familiar crawler name in a log offers only one piece of evidence. The platform publishes IP ranges for the agents it documents, giving operators another signal to use when checking who sent a request.

Google’s documentation distinguishes crawling by Googlebot from the appearance and reuse of material in search features. Search Central lists snippet and indexing directives for limiting what Search shows from a page. A separate control in Search Console, which Google says became available worldwide by August 31, 2026, manages whether the site’s links and content appear in or help ground responses in AI Overviews, AI Mode and generative AI features in Discover. The Search Console setting preserves eligibility for other parts of Google Search. Google says the control does not affect AI training and points publishers to Google-Extended for limiting training of models that generate the relevant responses. Publishers should consult the applicable help pages before assuming an older description of Google’s options still applies.

A preference about the original page also leaves distribution elsewhere to consider. A publisher may authorize a partner to reprint the story, release some information in a public newsletter or supply a feed to an aggregator. A search system may encounter another copy or a public page discussing the reporting. The Tow Center found instances where tools identified excerpts associated with publications that disallowed the relevant crawlers, but its researchers also acknowledged possible access through other sources. A correct answer about a restricted article does not identify its retrieval route. For the publisher, the distinction matters when investigating an apparent policy breach. Inspect the copy cited, check agreements and records for that copy, and separate evidence about the source text from evidence about how it was obtained.

Cloudflare offers a more literal way to bargain at the point of access. Its Pay Per Crawl documentation describes a closed beta under which site owners can set a price per Cloudflare zone. A participating crawler can signal payment intent in its request headers and receive the page, or get an HTTP 402 response that specifies pricing. Cloudflare acts as merchant of record. Its documentation also says a block imposed by its web application firewall or Bot Management overrides the charge setting. The mechanism puts a price on a request at a participating site. The documentation establishes the product’s rules and status. It supplies no basis for treating the arrangement as a market-wide rate or projecting how many customers will pay.

The economics depend on what the buyer wants and what the publisher can supply. A buyer that needs a frequent refresh of an archive may value a controlled feed and clear terms over processing many individual requests. A buyer trying to settle a question can switch to another source if the available answer is equivalent. A publisher with unique evidence about a narrow market can have more power over that particular query than an outlet with a larger audience but interchangeable coverage. The relevant scarcity is the work needed for a specific answer. Pay per request makes the unit legible. A contract can address the commercial value of timely access, the scope of downstream use and the reporting the publisher needs to monitor that use.

Two licensing announcements that OpenAI published in 2024 describe different bundles. The News Corp announcement described a multi-year agreement providing access to current and archived material from named publications, permission to display material in responses, and use of content to improve OpenAI products. The Financial Times announcement described a licensing and product collaboration under which ChatGPT users could see selected attributed summaries, quotations and links to FT journalism. Access to an archive and attribution in a user interface are separately negotiable. The public announcements do not specify deal prices, how often a story will be cited or how many visits the links will deliver. They give smaller publishers examples of rights and features to discuss, with limited evidence for pricing those rights.

The same negotiation should establish the treatment of the work around the main text. An investigation might combine original reporting, a photograph available for a limited purpose and a table that incorporates records obtained from a third party. Give each of those materials its own entry in a feed or archive inventory. The right to deliver a page may differ from the rights the buyer wants in every item on it. A publisher can make the licence easier to use by supplying clear fields for the materials included, the version delivered and the origin of each attachment. The buyer can then build those distinctions into retrieval and storage, while the publisher has something concrete to check if a dispute arises.

Any proposed deal should put the intended uses into concrete sentences. Is the buyer asking to collect pages for an internal index, display a passage to paying subscribers, send parts of an article to another model or train a model on an archive? Those choices matter even where the same page supplies the text. Require the agreement to say who can receive which version of the content. An outlet can ask how revisions and retractions propagate, whether links must point to its own article, what happens when an archive licence expires, and whether the reporting it receives lets it check the arrangement. A guarantee about prominent placement, for example, does little for the publisher if nobody can observe when placement occurs.

Tighter controls can carry an opportunity cost before anyone proposes a deal. A free publication with a service mission might choose open discovery for its daily resources and charge for bulk access to a specialized historical collection. A membership outlet might welcome references to public summaries while reserving detailed databases for registered users. Both choices depend on making different kinds of content available on different terms and taking responsibility for how those terms are implemented. The useful inventory lists what lives on each host or path, where copies travel and which team can change the rules. A publisher that understands its distribution can choose where it has room to test access and where a lost referral would be especially costly.

Editorial teams need evidence they can follow to the reader

A newsroom should be able to look at an assistant’s answer and distinguish four events. The brand appeared, the answer linked to the publication, a reader arrived at the publication, or the visit led to something the newsroom values. Visibility, attribution, referral and conversion belong on separate lines of the report. An assistant can name an outlet without a link, link to an outlet without sending a visitor, or send a visitor who leaves before reading. If the organisation also has licensed content or paid crawl access, record the proceeds separately. That income may help fund the reporting, and it tells the newsroom little about whether readers discovered or came to trust the publication.

Google’s 2026 Search Console rollout provides a concrete example of the dividing line. The dedicated generative AI performance report shows impressions from supported Search features, with breakdowns for pages, countries, devices and dates. A page impression records that a link appeared under Google’s counting rules, while the chart can aggregate several links to one property within a result into a single impression. An AI impression is evidence of exposure under the platform’s definition. The report does not give the publisher a corresponding count of AI feature clicks. Existing web search performance data includes activity from the AI features in its broader total. The publisher can use the new view to learn which pages appear, while treating a join to site traffic as an imperfect comparison.

For surfaces without an equivalent report, use a small set of repeatable queries from beats the newsroom covers. A city desk might look at how a new renter asks about a municipal programme, how a long-time resident checks a change and how a volunteer tries to locate the official form. Include questions where the correct result is already known and keep wording and dates with the outputs. Prompt tests reveal specific behaviours under test conditions. Record the assistant and feature, search settings when visible, source link, relevant answer passage and whether it matches the evidence. Repeat a subset across days and clearly label geography or account conditions. An editor should be able to reproduce an error report without mistaking the sample for an estimate of real audience demand.

Traffic measurement starts where the publication can see a landing or a conversion. A publisher can compare sessions carrying a recognizable referrer or campaign tag with what its own logs show, and check whether bots, previews or automated fetches explain apparent arrivals. Some visits arrive with no usable source information, and returning readers may remember an outlet they encountered in an assistant without leaving a trace of that first exposure. Count attributable sessions as observed sessions and keep unattributed traffic visible. Treat uncertain exposure as a research question. Ask new members where they first heard of the outlet and record the answer alongside the observed path to signup, with room for either record to be incomplete. This provides more context without pretending that recollection and a tracking tag measure the same thing.

The visits that do arrive should be evaluated against the page’s purpose. A benefits guide might be doing valuable work when someone follows a link to the right official form. A trade publication might care whether a company sets up an account or requests access to a regularly updated dataset. A newsroom studying AI referrals should look at volume alongside the rate of those actions and how reliably those visits turn into return readership. A promising conversion rate on a small cohort is a reason to examine the cohort. Before building a financial forecast around it, compare similar pages, intent and devices and consider whether a single distinctive story accounts for most of the results.

Editorial investment should begin with work an answer service would have difficulty substituting. Imagine a reporter tracking zoning cases across a city. The public record establishes meeting dates and decisions, but a newsroom can build a consistent case history, link each decision to the underlying record and show when the status changed. A short assistant reply can relay the latest disposition while the underlying page still offers comparison, verification and alerts about subsequent hearings. A maintained record gives readers a reason to return after the immediate question is answered. Before commissioning it, estimate the cost of maintaining it, identify the readers who would come back and decide which parts are best published as open evidence, a member service or a separate licensed dataset.

The same approach changes the way a newsroom handles the materials that go into an investigation. Archive source documents where permitted, preserve the extraction steps for a dataset, and give a central finding a stable page with a date, scope and method. If a number applies only to one year or excludes a category, put that condition beside the number. Keep qualifications attached to the facts an assistant is likely to extract. The reader who arrives through a direct link also benefits when the link lands at the relevant evidence with a clear path to the full piece. Where a source needs protection, build the public trail from the material the newsroom can safely show and describe the limits without exposing private records.

The reporting pipeline needs a way to publish revisions. A guide about a transport strike can become inaccurate when a union announces a tentative agreement. Add a conspicuous update to the canonical page, retain the chronology where it matters, and update any feeds or extracts the newsroom provides to outside partners. Give time-sensitive reporting an explicit owner and a visible timestamp for substantive changes. Record when the correction went live and check whether the wrong claim still appears in a few relevant assistant outputs. Some external copies may lag the correction. A partner’s update channel matters here because it gives the publication someone to notify and a way to follow up when the old claim persists.

An audience team can spend much of a week testing which title is most often cited, while a newsroom has only so many hours to document a story worth citing. The Reuters Institute’s October 2026 interviews described teams at Axios, the Guardian and The Athletic trying to understand their standing in AI search and reporting uncertainty about which tactics work. The sensible experiment connects a change to an editorial reason and an observable result. Track errors and useful outcomes alongside appearances. If making the official source easier to find helps people verify a guide and improves the references in sample answers, the work serves the newsroom in two ways. A rewrite that only changes a vendor’s reported visibility score offers a thinner case for newsroom time.

A publication with this evidence has more to bring to an access negotiation than a screenshot showing a brand name in an answer. It can explain which work appears, where attribution fails, which users reach the site, what readers do when they get there and how much the underlying reporting costs to keep current. Some of those measurements will remain incomplete. They can still reveal whether a proposal supplies a needed route to readers, pays for a useful dataset or asks the newsroom to accept an exposure it has no way to check. An access strategy earns its place when it supports the reporting and the people who use it. The publication can make that judgment even if an assistant supplies the answer to most readers.

A search result has no authority over the agent

Imagine an agent comparing suppliers. One website offers precisely the warranty details it is looking for. Below the warranty sits a message styled as a system notice telling automated visitors to send their internal comparison sheet to a verification address. The warranty might be genuine. The website still has no authority to order a transfer. A human reader can usually see who is asking and decide whether to comply. An agent has to maintain that distinction as it takes in natural language from multiple sources and decides which tools to call. The risk enters at retrieval, but the consequences depend on what the surrounding application has given the agent permission to do.

Kai Greshake and colleagues described this mechanism in their 2023 research on indirect prompt injection. An attacker places instructions where an application is likely to retrieve them, with no need to type directly into the victim’s chat. The researchers tested the idea against applications built with GPT models, including the version of Bing Chat available to them, and demonstrated ways retrieved text could influence whether or how an application called other tools. Those historical demonstrations establish a mechanism. They give no success rate for present search products or any specific deployment. Their relevance to a search market is that the path into the agent may begin on a server neither the model vendor nor its customer operates.

Search vendors and their customers see different portions of the same risk. A retrieval provider can make it easier to identify where a text fragment came from. The application knows which user initiated the request, which confidential documents are in the session and which actions its credentials can perform. The party that can see the page and the party that can prevent a payment are often different. For a developer buying search as an API, that division argues for testing the integrated workflow. A provider’s successful inspection of a snippet says little about a later fetch of the full page or the permissions available to the next model call.

Format checks deal with part of the problem. A result object with separate fields for the source address, title and extracted passage lets an application display the source consistently and apply policies to the address. The passage remains untrusted even inside a well formed object. Text can imitate a reviewer, a software update or a correction to the user’s request while occupying the expected field and meeting every length limit. Removing scripts and hidden markup is sensible when the application wants readable text, and ordinary visible paragraphs can carry the same instruction. Treat provenance and format as inputs to a decision about exposure. Authority for any subsequent action should come from a separately enforced policy.

OWASP recommends separating and identifying external content, restricting privileges and requiring approval for high risk operations in its guidance on prompt injection. The pieces matter together. A label on incoming text gives the model a cue. Narrow privileges reduce what happens if it misses the cue. A separate approval step can give the user control over the decisions with the greatest consequences. In the supplier example, the model could extract a warranty, explain a discrepancy and draft questions for a colleague. The application could independently refuse to upload a file to the address on the page. That refusal would depend on the destination and the user’s authority, even if the model had supplied a flawless explanation for the proposed upload.

The same reasoning applies to a tool conventionally called read only. A model might be allowed to search, and a search query is itself an outbound transmission. If it can read a confidential spreadsheet and construct arbitrary queries, it can disclose information while using only that read tool. Likewise, a page preview might fetch a link containing sensitive text encoded in the address. Whether these paths exist depends on the application. A useful boundary for a mixed workflow is to give the public researcher only the material it needs, screen its outbound calls and join the public findings with private information inside the customer’s system. The network operation deserves the same scrutiny as the visible action.

Evaluation gets harder when the test measures both safety and usefulness. AgentDojo, a research framework introduced by Edoardo Debenedetti and colleagues in 2024, reports 97 tasks and 629 security test cases in the reviewed paper version. The authors found that the models under test struggled with some ordinary tasks even in the absence of attacks and that existing attacks compromised some security properties while leaving others intact. An application that simply declines to touch unfamiliar pages can look safe while failing the assignment. An application that completes a task can still have violated a constraint on the way there. An evaluation should score both outcomes. Its job is to show what the agent accomplished and which boundaries held while it did so.

Tests for an actual deployment can use a controlled site carrying a normal policy, an instruction to visit a second address and a request to repeat a unique fake secret. Run the same cases through the result snippet and full page paths, because the text the model sees can differ. Inspect the attempted calls as well as the final answer. A clean summary can follow a rejected attempt to disclose data, an event security teams would still want to investigate. Include benign pages with language that resembles commands, such as product manuals. Otherwise a control that blocks the attack could quietly deprive the agent of sources it needs to answer a real customer.

The record of a security event should help an operator distinguish a malicious instruction from an ordinary misunderstanding. An application can log a decision code when a destination fails a policy check and retain a restricted sample of the retrieved passage for incident review. Avoid turning the investigation log into another copy of the data the control was meant to protect. For an alert that caught an attempted leak, routine monitoring might need the destination and the type of material withheld, while an investigator with the right permissions may need the exact excerpt. If an agent later reviews those records, the stored passage remains outside its authority. Copying it into a trusted database changes its location and its retention obligations, while leaving its origin intact.

Deciding which sources to trust for a particular fact is a related judgment with different consequences. A manufacturer’s warranty is a primary source for what the company promises, and a third party might still be needed to establish whether a defect actually occurred. Neither source can authorize changes to a purchase order. Evidence can be authoritative within a narrow factual claim while carrying zero operational authority. That distinction allows a product to preserve a rich reading experience without extending the privileges of every party it reads. It also makes clearer what the customer is buying from the search service. The service returns evidence and leads. The buyer’s application has to decide where those leads may take the agent.

A capable agent also needs a useful way to fail that preserves the work it has already done. If a search result attempts to redirect the task, the application might keep the original comparison, obtain the warranty directly from another approved location and record that one result was excluded. A separate review can decide whether the source was compromised or merely contained unusually phrased instructions. The customer sees a usable comparison and an honest indication of the missing evidence. Recovery is part of search safety. If the only alternatives are complete obedience or wholesale abandonment, a hostile page can disrupt an assignment without persuading the agent to leak a single byte.

Enterprise search is a data and operations purchase

The decisive privacy question for an enterprise is which words cross its boundary when the agent looks something up. A lawyer might ask for public precedents concerning a hypothetical acquisition while consulting a restricted memo. A search for a legal concept is one kind of disclosure. A search for that concept plus the two companies and a proposed transaction date is another. A handful of words can reveal what the whole document was meant to keep confidential. Buyers should ask to see the generated query, the destination and the controls that apply before it goes out. The familiar labels on a chat product tell them little about how a separate search service will handle that request.

Microsoft’s documentation for Microsoft Copilot and Microsoft Copilot Chat offers a concrete example. Microsoft explains that the products can generate a query for Bing using words drawn from the user’s request and, in specified Microsoft Copilot scenarios, information from a Microsoft 365 document. Its example uses a theme from an internal strategy document as a search term. The document itself stays inside. Microsoft also says the request sends the user’s client IP address to Bing for localization. The query and the conversation have different data handling terms. Microsoft says its enterprise protections and Data Protection Addendum apply to the prompts and responses described there, while that addendum and the EU Data Boundary do not apply to the generated web queries. Its documentation describes separate commitments for those queries, including a commitment against their use for training generative AI foundation models.

The example makes it possible to ask precise questions about a vendor with a very different product. Who receives a query, which organization can access it, for what purpose and for how long? A platform may distinguish a hosted search feature from a third party search integration, and a provider may process a search request differently from a fetch of a specific page. Check each destination where the agent sends information. A real procurement test should cover optional fallbacks, debugging exports and paths used when a request fails. A buying team can then match each stage to the vendor’s current terms and its own acceptable disclosures without asking one promise about training to stand in for the entire privacy review.

A short query can still be made safer by forming it from approved inputs. In an illustrative product recall workflow, a team might allow public product codes, model names and jurisdiction names while excluding customer records. A medical device model number may be essential to matching a public notice, while a customer’s name adds exposure and little retrieval value. Minimization needs to preserve the facts that make search work. An excessively broad filter can strip identifiers that distinguish a current recall from a notice for an older device. Review requests the agent blocks and cases where it produces a plausible but wrong match. Good policy makes room for an authorized public identifier without allowing the system to freely rewrite confidential material into queries.

Enterprise authority should also survive changes in the agent’s interface. Microsoft documents a tenant administration policy that can enable or disable web search for users or groups in the Copilot experiences it describes. A user toggle cannot override an administrator’s decision to turn that search off. A team building its own agent can apply the same principle when a model runs on a schedule, hands a task to a second agent or uses another product surface with separate settings. The permission should be checked at the point that sends the request, with the right tenant and user or service identity attached. Otherwise a setting in the chat interface may govern interactive runs while leaving batch jobs with broader access.

Logs make these boundaries testable. Microsoft describes audit and eDiscovery access to generated search queries in the covered Copilot services, including the ability to inspect search terms alongside other interaction details using Microsoft Purview. An enterprise with its own agent can decide which details are necessary to explain a disputed decision. For example, an operations team might require the identity of the search route, time of the call, policy result, returned source addresses and indications of which sources the model used. A restricted audit store could retain exact query text when warranted. The goal is to distinguish a bad query from bad retrieval and from bad use of good evidence, while limiting the number of people who can reconstruct the confidential request.

A trace can also expose a quality failure that looks like a normal day on the vendor dashboard. In a hypothetical compliance monitor, a call returns successfully, but the pages retrieved are unofficial summaries and the official bulletin is missing. Another run times out and uses yesterday’s archived bulletin. Both might produce fluent text. A successful response is weaker evidence than a successful check of the required source. A team evaluating an agent should define what counts as fresh or complete for the specific task, then capture the distinctions in a form that a human supervisor can interpret. That record has operational value well beyond an aggregate uptime figure or a model’s assertion that it has checked the web.

OpenAI’s incident archive records elevated errors in the Responses API’s web search tools on September 5, 2025 and reports recovery that day. It is a documented failure of a named feature on a specific date, with no basis for ranking its reliability against other providers. The example shows why a team must pick a response to failed retrieval before a workflow depends on it. A company might let an internal draft proceed with a conspicuous note that recent information could not be checked, while pausing automated changes that require a current source. A retry can address a transient error if there is time left. It still consumes time and may duplicate work unless the application tracks which calls have already completed.

A second provider can make recovery more useful, provided the team can explain its behavior under failure. In procurement, two contracts are weak evidence of independent retrieval. Providers could rely on overlapping indexes, the same upstream syndication arrangement or a shared infrastructure component. Even two independent indexes can both miss a government page during an outage at the publisher. An acceptance test can disable one provider, compare the source coverage the second one returns, and verify that the fallback has permission to receive the same data. There should also be an exit test. Change suppliers in a sandbox and see whether policy checks, source records and earlier decisions remain intelligible after the new result format arrives.

Commercial terms become more concrete when tied to failures that users recognize. A broad uptime commitment may have little value to an agent that needs a particular tool at a deadline. If the search vendor rate limits a scheduled workload every weekday at opening time, the contract’s overall availability measure may miss the recurring interruption. Ask which service objectives cover the purchased search route and what alerts, escalation channels and incident records the customer receives. Workload tests should include realistic bursts and quotas as well as normal traffic. They should also account for how delayed calls affect the whole job. A five minute delay means something different to a weekly intelligence memo than to an agent deciding whether a public warning has just changed.

The handover from procurement to operations should name someone who can disable web search and someone who can decide that a narrower fallback is sufficient. These can be different roles. A security administrator may be able to stop all outbound calls at once, while the service owner knows which customer commitments will need manual checks. An outage plan becomes credible when people rehearse the decision and see its consequences. In an exercise, operators could compare the effects of turning off one provider, disabling only live retrieval and quarantining a class of requests. If none of those actions leaves an honest and understandable user experience, the business has purchased an availability dependency it has yet to manage.

Competition depends on which search inputs rivals can reach

A fluent interface can be built on somebody else’s view of the web. Two assistants may look independent to the buyer while both see a similar ranked pool of pages from a common upstream service. Meanwhile, an independent index can retrieve a page that a second assistant declines to cite. Distribution, search data and the published answer are separate points of control. Competition depends on where a rival can bring its own judgment and where it must accept an upstream choice. The distinction is visible in recent interventions in the United States, the European Union and the United Kingdom, which address different parts of the chain under their respective legal frameworks.

The United States District Court for the District of Columbia entered its final judgment in the Google search litigation on December 5, 2025. The judgment records the court’s finding that Google had unlawfully maintained monopolies in general search services and general search text advertising. It imposes distribution restrictions covering specified arrangements, including ones involving Google’s generative AI products, and provides for licensing certain search data and syndicating search results and search text ads to qualified competitors. The search syndication provisions contemplate delivery by API and specify conditions on access. The Justice Department’s case record also lists later activity concerning the preparation of license templates and appellate briefing. The remedy’s text and its implementation are distinct facts.

Search syndication and access to data for developing a rival engine address different costs. A syndication customer gets results from an existing system in response to eligible queries. A recipient of data for improving retrieval might use it to change how its own system understands and ranks a query. An engine can enter with help from somebody else’s results and still face the cost of building its own view of the web. That makes technical terms central to the commercial question. Limits on query types, use and eligibility can determine which businesses have a practical route to entry, and comparable latency and reliability can matter at least as much as list price to a service that has to keep a user’s wait short.

In the European Union, the Commission adopted its final decision specifying Alphabet’s Google Search data sharing measures under Article 6(11) of the Digital Markets Act on July 16, 2026. The Commission’s explanation says the measures cover eligible online search services, including qualifying AI chatbots that provide search functionality. They allow use of the data to develop and improve online search services, with restrictions including a bar on training general purpose AI models using the shared data. Its published explanation also describes eligibility and independent auditing. For a developer of an assistant, the decision is relevant to a particular search function and business. Reading it as blanket access to Google’s ranked results or as a general model training license would overstate what the Commission describes.

The Commission’s privacy explanation illustrates a difficult tradeoff in opening an input market. Rare searches can be useful for improving retrieval and can also carry clues about the person who made them. The published measures describe removal of direct identifiers, suppression of certain queries and generalization of metadata, together with contractual protections and independent review. The Commission also distinguishes protecting the searcher from handling personal data about someone named in a query. The resulting dataset is a product of these choices. Competitors need enough useful information to improve search, and sharing terms must account for what other parties could learn from the surviving records. A headline about data access tells the buyer little about what a particular recipient will actually be able to do.

Publisher bargaining enters at another point. The UK Competition and Markets Authority imposed a publisher conduct requirement on Google on June 3, 2026, following its designation of Google in general search services. The authority says the requirement includes publisher controls over use of content in AI search features such as AI Overviews, as well as measures concerning attribution and fine tuning. The announcement gives Google time to implement changes and describes reporting on compliance. The case therefore supplies a targeted example of a regulator addressing the terms on which content appears inside a search experience. The announcement gives no basis for treating those provisions as rules covering every company that sells a web search API.

Attribution and control over reuse solve different problems for a publisher. A clear reference allows a reader to follow a claim back to the reporting, discover what was left out and check for a correction. An ability to decline particular uses gives the publisher a decision before its work enters the answer. A citation alone says little about the value that came back to the source. The answer may satisfy a reader without any visit or may introduce a publisher to a reader who would have missed it. An assessment should look at placement, whether the answer depends on the source’s reporting and whether readers who do follow the reference reach the original work. Counting links gives only part of that picture.

Regulation can also open up a practical purchasing question about independence. An application that promises to compare providers can measure overlap in the underlying evidence alongside how often answers agree. If two search services both surface republications of a single press release, three displayed links may reflect one account of the event. A local agency record or direct reporting can add evidence that changes the result. To test for that, select questions for which original sources are known and look across languages, regions and newly published records. Observing differences in results cannot prove who owns which index. It can show whether the ability to switch providers widens what the application sees for the work its users do.

Transparency presents its own design choice. A consumer does not need an inventory of every backend involved in a restaurant search. A public interest researcher may need to know whether the application queried an open web index, a curated partner collection or one domain that pays for prominent treatment. Disclose the choices that could change the interpretation of the answer. For a policy question, a reference to the original source plus a visible date may carry more value than a lengthy account of routing. A commercial placement raises a different concern and calls for a clear indication at the point where it affects the recommendation. These are design judgments about the agent interface, distinct from claims about what any particular jurisdiction currently requires.

A public interest test extends beyond the number of firms able to sell access. If opening access to an incumbent’s data leads competing services to return the same pages, users may gain choice among interfaces while seeing little additional evidence. If the new services use the data to improve how they find sources the incumbent misses, the same intervention could support more diverse answers. Both are scenarios, and the regulator sources do not establish either outcome. Track whether a change widens the sources an agent actually consults. For an assistant serving a town or an industry, that could mean finding the local minutes, the current safety notice or the first report of an event, with the original publisher still visible to the person whose decision depends on it.

Search belongs at the point of decision

A useful way to buy retrieval is to start with a document someone can recognize and work backward. Consider a hypothetical distributor that wants to find newly revised installation manuals for the products it supports. A purchasing committee could specify that it needs general web search, then leave the problem of finding manuals to whichever team integrates the API. It could instead say what a support technician needs to see in the morning. The deliverable is a short list of revisions with the affected products, dates and source documents. This immediately narrows the supplier question. Wide coverage helps only insofar as it reaches the manufacturers, distributors and regional sites where these manuals actually appear.

The same company might also want an assistant that answers a technician’s questions during a site visit. That job has a different clock. A daily document watch can wait for a slow page to become available and benefit from a deeper lookup. The assistant used while a customer is standing nearby needs a fast way to identify the model and check the relevant instructions. A watch service and an interactive assistant can use the same evidence with different retrieval policies. A watch can store an approved copy of a manual if its terms permit it, whereas the interactive system can refer to that copy and reserve fresh web requests for gaps. The buyer can choose separately where speed and breadth belong.

A document archive also changes the fallback a customer is prepared to accept. If a supplier endpoint is temporarily unreachable, a timestamped local copy may answer a question about a manual identified by revision. A query about whether that revision remains the latest needs access to a current publisher source. An assistant that treats both questions as ordinary lookups may silently substitute an old copy for live evidence. An application can preserve usefulness during an outage by saying exactly what its evidence establishes. Its product can show the last verified revision, the date of that verification and which check has been postponed. That is a more useful failure mode than returning a polished answer with an undated quotation.

That separation also gives the company a way to decide what to build. The manufacturer directory, equipment identifiers and descriptions of what a technician calls each product may already exist inside the organization. The knowledge that a local distributor mirrors an older version might be held by a few employees. A company can own its rules for selecting evidence while renting general web discovery. A specialist search supplier could become part of this design without being asked to know the company’s internal inventory or the order in which employees consult documents. If the supplier later changes, the company can still recognize the sources it trusts and compare new results against previous revisions.

An integration team can make switching easier by preserving the results that matter to the application. For the manual watch, those might include a canonical document identity, a version label, the language, the time at which the evidence was seen and the passage that changed. A provider response may supply some fields directly, while other fields have to come from a document or be left unknown. A useful common record preserves uncertainty and provenance. Storing everything under a generic field called “result” makes later comparisons cheap to implement and hard to trust. One provider’s inferred publication date can look indistinguishable from another’s document timestamp unless the record captures where the value came from.

The Model Context Protocol illustrates both the promise and the limits of a common interface. Its tools specification describes named tools with a schema for their inputs and support for structured results. An application can use that machinery to discover and call a search tool. A common calling convention says little about which material the search tool will find. Two services can accept the same query and return the same output shape while disagreeing about which version of a document deserves the highest position. The difference matters precisely where a purchasing team hopes to substitute one provider for another. Changing the connector may be simple. Establishing the equivalence of the evidence still takes work.

This is also a reason to preserve some output outside the answer interface. Imagine an internal assistant that helps produce weekly supplier briefs. The brief can retain its narrative form while the application writes a separate evidence record for each material update. When an employee challenges an assertion, the reviewer can inspect the passage and resolve the disagreement without rebuilding the model’s entire chain of work. The ability to reopen a decision has practical value long after the answer was generated. If a source later disappears, the record can indicate which part of the original judgment survives and which part needs a fresh check. That benefit depends on what the application is allowed to retain and what it chose to retain when the evidence was available.

Search can also be routed according to the cost of a mistake. For an ordinary request to locate a company page, the default source may suffice. A claim that triggers a customer notification can require a direct check against a maintained source. A difficult request spanning local-language trade sources may need a second provider that reaches material the first seldom returns. Escalation is most useful when a specific uncertainty tells the application where to look next. Paying for two independent queries on every request can improve redundancy, but two services can both return copies of the same weak document. The test for independence lies with the underlying evidence and the way it was obtained.

Over time, some jobs may settle into subscriptions that report changes to known sources. In the manuals example, the team might follow a known set of manufacturers and care about anything that changes an installation procedure. Discovering a new publisher still calls for broad search, but following familiar sources can depend on direct feeds, notifications or structured documents if publishers offer them. Once a workflow knows where good evidence comes from, it has a reason to visit those sources directly. A general search supplier may still earn money by identifying new evidence or recovering material when a known channel fails. Its role can shift as the buyer learns the territory.

A monitoring application can make an additional mistake when it treats silence as a finding. Suppose the distributor expects to hear from the manual watch only when something changes. On a normal day a blank queue means the sources were checked and nothing relevant appeared. On another day it could mean the crawler reached a consent screen or a provider quietly lost access to a regional catalog. A negative result needs a record of coverage. The application can report how many of its known sources were actually inspected and flag important gaps separately from confirmed changes. Otherwise the absence of an alert can give employees more confidence on precisely the days when evidence is weakest.

Coverage itself can be defined in terms the buyer can use. A claim to search an entire industry is difficult to assess. A watch list that includes the original source, the market it covers, the document types expected and the normal update rhythm is much more concrete. For sources that publish infrequently, an application can test whether it still retrieves a known recent item before drawing conclusions from a quiet period. The buyer can distinguish an uneventful day from a broken line of sight. This also gives search vendors better feedback than a generic complaint about recall. A named source and a dated item establish what the application expected to find and whether a competitor actually found it.

The same logic applies when an assistant changes how it describes an old item. Imagine that an equipment maker silently updates a product page to point to a revised PDF. A downstream analyst may see an apparent disagreement between last week’s brief and the current answer. Both could have accurately described the material available when they were written. A correction process needs to separate changes in the world from mistakes in reading the evidence. A system that attaches retrieval dates and document versions can make that distinction at least visible. A team can then correct the earlier brief when warranted or publish an update that acknowledges the source itself changed.

An organization can attach these distinctions to service ownership. Support employees can identify authoritative instructions, operations staff can decide which incidents require escalation, and engineering can make the application report failures honestly. The search supplier can explain which sources its product was able to reach, subject to the detail its contract and product provide. Responsibility for the final claim stays with the organization that puts the answer into use. Giving the vendor a clear description of the work makes it possible to judge its contribution without expecting a ranked list to solve the rest of the organization’s job.

That possibility puts a premium on making the result useful at the moment of handoff. The technician who receives an updated manual wants to know which instructions changed. The buyer who decides whether to renew a retrieval contract wants to know whether those changes were found reliably. A search provider that can explain which revision it retrieved and where it came from has a more persuasive case than a provider selling a vague promise of breadth. Search enters an existing chain of accountability when it serves work. The strongest application designs preserve enough evidence for the next person in that chain to disagree, confirm or act.

The next negotiation over search revenue

Retrieval APIs and consumer advertising can grow side by side. Google Ads Help documents placements inside or alongside AI Overviews and AI Mode for commercially relevant interactions. It describes those placements as sponsored and distinguishes them from the organic response. A company that owns the answer surface can sell advertising there and still earn money by offering search to developers elsewhere. The two opportunities rely on different relationships. In the first, the search company can choose how to present ads and sell access to user attention. In the second, another company may own the user interface and negotiate what it pays for retrieval behind it.

That difference becomes sharper in a scenario where a user compares industrial equipment. An assistant operated by the search company might show paid options alongside its answer if the interaction and market are eligible. A neutral internal procurement assistant could instead block promotional placements and require the use of manufacturer specifications and verified prices. Both applications need documents. The party controlling the interface decides which commercial signals belong in the answer. That decision affects advertisers, developers and end users in different ways. It also explains why a company can gain retrieval customers without gaining any direct right to place advertising in the products those customers build.

Sponsored visibility will therefore sit alongside another purchase that is easy to mistake for it. An advertiser pays for a placement that can bring customers. A developer pays for the ability to find information needed to finish a job. A publisher licensing access may get paid for supplying material that helps either of those transactions happen. The value of a source can exceed the traffic it receives from any single answer. Consider a small industry publication that maintains the only public chronology of product withdrawals across a local market. If an assistant relies on that chronology for a recurring task, the publication’s contribution becomes apparent in a way that a visit count might barely register.

The opposite scenario is just as plausible for undifferentiated material. If most suppliers return the same syndicated announcement and the question needs only its release date, buyers may have little reason to pay a premium for any one of them. More copies can even slow the application if it has to remove duplicate passages before reading the underlying source. The price of retrieval depends partly on how easy it is to replace the underlying evidence. A provider can try to earn a premium through fresher access, better extraction or stronger regional coverage. A general index that relies on widely available documents has to prove the difference at the level of the work people actually do.

From the perspective of an independent supplier, the difficult customer is a platform that wants broad coverage, a low price and freedom to route each request elsewhere. The supplier may still find business in specialist tasks that a default service handles poorly. A provider might excel at locating regulatory notices in a particular country or at preserving table headers in the results it serves. A difficult subset can sustain demand even when a bundled tool handles ordinary queries. The independent company would have to decide whether to offer that competence to many applications or license it more deeply to one distributor. The buyer would have to decide how much control it needs over the fallback.

Search also changes hands at a pace determined by where the work already lives. A newsroom may prefer its own evidence collection system because it needs permanent references and a way to preserve corrections. A small business that asks occasional public questions may use the retrieval offered with its existing assistant because it has little reason to maintain a separate contract. A software company that sells an answer to thousands of customers may give itself room to choose providers by language or subject. The expected cost of changing suppliers is part of the value of the default. That cost can stay low for lightweight uses and become substantial once internal workflows depend on one provider’s particular output.

The market could grow quickly in search requests without yielding similar growth in standalone search revenue. A model platform can add calls as part of a subscription, improve routing to avoid work that repeats or pass only the hardest tasks to an outside provider. A publisher can move a recurring customer to a direct feed. An enterprise can automate far more document checks while controlling the number of calls it makes across the open web. The decisive observation is where buyers continue to pay when they have alternatives. Public prices tell us the terms of an offer. Long-term contracts, repeated purchasing and the work that buyers refuse to run without a particular source would tell us more about the distribution of power.

At the same time, retrieval can outlast the product that made its use fashionable. An office assistant may be replaced or renamed. The person tasked with checking a supplier’s current terms will still need a source and a way to establish which version applies. The historical analogy to a search results page only takes the analysis so far. The paid service is increasingly judged by the evidence it delivers into another company’s decision. For some suppliers that evidence will remain easy to find elsewhere. Others will be able to show that their coverage or rights made a difference in a specific task. The distinction is worth far more to a buyer than a generic count of how many pages sit in an index.

The analyst at the start of this story has no reason to care how many endpoints the office assistant contacted. The new terms are useful if their date can be confirmed and the regional exception appears beside them. If the application can show where each came from, the analyst can open the original document and challenge an incorrect reading before it reaches an order. That moment is where the providers’ claims meet the work they are paid to support. The assistant may own the relationship, the search company may invoice the developer, and the publisher may own the only authoritative copy. Which of them gets paid for the next request depends on which part of that chain the buyer can afford to lose.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

搜索的第二次战争：买家从人变成了模型
Qingyun’s November 2026 analysis for Emphasize Next, published by 36Kr, introduces the Chinese platform examples and the distinction between user attention and demand for retrieval.

QuestMobile 2026中国移动互联网秋季大报告：用户结构银发化趋势+AI应用加深，双轮驱动行业格局变化，用户时长加速向微短剧和AI迁移……
QuestMobile’s autumn report distinguishes AI-native apps, device-maker offerings and desktop clients in its analysis of Chinese internet usage.

How Google search results differ from ads
Google Ads Help describes organic results and advertising as distinct and explains the role of bids and relevance in ad ordering.

AI Mode in Google Search: Updates from Google I/O 2025
Google’s May 2025 announcement explains parallel query fan-out in AI Mode and distinguishes the user’s question from the searches run behind it.

元宝搜索，正式开放
Tencent Cloud’s developer community launch post describes the outside opening of Yuanbao Search and reports its internal use in WorkBuddy and ima.

元宝搜索
Tencent Cloud’s product page lists the three Yuanbao Search tiers, their prices, and their respective search and result features.

Buddy One · 联接 AI 好伙伴，办公尽在 Buddy One
WorkBuddy’s Buddy One product page describes its common account, membership, application benefits, and credit sharing.

Buddy One 积分使用说明
WorkBuddy’s support guide identifies which applications draw from a common Buddy One credit balance and explains the distinct treatment of product-specific credits.

腾讯推出跨应用 AI 协同体系 Buddy One：打通腾讯多款办公产品，共享 WorkBuddy Agent 底座
IT Home’s October 29 report details the original rollout to individual users and how linked apps contribute authorized sources.

元宝
Tencent’s own app listing describes the consumer assistant’s WeChat Official Accounts and Video Accounts sources and its Tencent service integrations.

百度AI搜索
Baidu AI Cloud’s campaign page gives the eligibility and timing of the Enhanced and Flagship search API offers, plus the list rates and eligible capabilities.

Baidu Announces Second Quarter 2026 Results
Baidu’s earnings release provides the online marketing and AI cloud infrastructure revenue figures and their reporting definitions.

DeepSeek-V4.1-Flash-1017: Wish-Driven Programming Made Real
DeepSeek’s October release announces its Search and Fetch APIs and specifies the start of billing in its supported server-side integrations.

Models & Pricing
DeepSeek’s API documentation lists peak and off-peak model token rates and separate charges for successful Search and Fetch requests.

Search & Fetch
DeepSeek’s API guide explains the different roles of the Search and Fetch endpoints and describes their billing rules.

Web search with large models
Alibaba Cloud documents Model Studio’s search settings, available strategies, and differences among model interfaces.

Web Search
Qwen Code documents which Alibaba-backed configurations register the built-in search tool by default and how permission to use it works.

联网搜索工具
Volcengine’s Ark guide compares Doubao Search Custom with its online content plugin and describes interface and activation requirements.

Chat API
Volcengine’s reference documents when a model can invoke built-in web search and the precedence of custom tools on its Chat API.

豆包搜索
Volcengine’s Ark enterprise Agent Plan guide describes the conditions for using the plan allowance toward Doubao Search.

AI features and your website
Google explains when AI Overviews and AI Mode may use related searches across subtopics and data sources and says the two features can use different techniques. Google Search Central describes Googlebot, page preview and indexing directives, and inclusion of AI feature activity in the broader Web search reporting.

Web search
The OpenAI API guide distinguishes search, page opening, within-page search, and answer annotations. It also documents live access and cached or indexed operation in the Responses API. OpenAI documents built-in web search, the distinction between inline citations and the full list of consulted URLs, and display requirements for cited results.

Web grounding tools overview
Microsoft describes how a Foundry agent formulates queries, how the grounding tool retrieves Bing results, and how the agent synthesizes and attributes the resulting information.

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
Patrick Lewis and colleagues describe a trained language generator combined with a separately accessible index of Wikipedia passages.

In-depth guide to how Google Search works
Google Search Central separates discovery, crawling, indexing, and serving and explains how duplicate clustering, language, and location can matter.

Relevance scoring in hybrid search using Reciprocal Rank Fusion (RRF)
Microsoft explains how Azure AI Search merges ranked results from separate queries and can apply semantic reranking after fusion.

BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models
Nandan Thakur and colleagues compare retrieval approaches across eighteen datasets, report the strength of the BM25 baseline, and discuss ranking quality and computational trade-offs.

Control your snippets in search results
Google Search Central explains how Google generates query-dependent previews primarily from page content and may also use the meta description.

Web search tool
Anthropic documents Claude’s search tool and distinguishes basic result retrieval from tool versions that can filter results before they reach the model’s context. Anthropic documents Messages API search controls, differences in Managed Agents, and billing for searches and retrieved content.

Web fetch tool
Anthropic documents fetching content from specific web pages and PDFs, limitations on eligible material, and versions with filtering before the model reads the content.

Ask Google to recrawl your URLs
Google Search Central describes the potential delay after a crawl request and explains why the request does not guarantee appearance in results.

MIRACL: A Multilingual Retrieval Dataset Covering 18 Diverse Languages
Xinyu Zhang and colleagues describe a benchmark with native-speaker judgments for same-language retrieval tasks across eighteen Wikipedia editions.

BrowseComp: a benchmark for browsing agents
OpenAI explains why BrowseComp tests difficult web research with short, stable answers and identifies the limits of generalizing that design to open-ended user questions.

Evaluating Verifiability in Generative Search Engines
Nelson Liu, Tianyi Zhang, and Percy Liang distinguish whether citations support the statements they accompany from whether an answer’s claims have adequate citation coverage.

Bing Search APIs retiring on August 11, 2025
Microsoft’s lifecycle announcement names the retirement date, says existing instances would be decommissioned and identifies its recommended grounding migration.

Grounding agents with Bing Search tools
Microsoft documents the evidence returned to developers, display requirements, data sent to Bing, the Azure compliance boundary and transaction counting for its Bing grounding tools.

Web search tool
Microsoft documents the Foundry Web Search tool and its use of Grounding with Bing Search and Grounding with Bing Custom Search.

Grounding with Google Search
Google Cloud explains grounded results, the display of Search Suggestions and the conditions for displaying results from other search engines in the same application.

Pricing
OpenAI lists the billing treatment of web search calls and search content tokens across its documented search options.

Brave Search API
Brave describes its own index, Search and Answers products, LLM Context endpoint, Goggles and the need for a plan with storage rights to retain results.

Start searching for free
Exa’s API pricing page distinguishes its search modes, Contents, Answer and Agent offerings, and identifies specialist indexes and third-party data available through Exa Connect.

Credits & Pricing
Tavily describes its credit system and the distinct ways search depth and extraction affect the amount billed.

Tavily Search
Tavily documents the search endpoint and its options for search depth, returning page content and generating an answer.

Parallel API Pricing
Parallel compares Search, Extract, Task and Responses, including the units billed, asynchronous research and the OpenAI-compatible Responses interface.

Perplexity Search API
Perplexity documents ranked results, snippets and filters, demonstrates integration with other model providers and directs developers seeking generated answers to Agent API.

Sonar is moving to the Agent API
Perplexity’s August 2026 announcement names the retirement date for its Sonar endpoints and directs customers to Agent API.

Google users are less likely to click on links when an AI summary appears in the results
Pew Research Center’s July 2025 analysis of March browsing data gives the traditional and summary link click rates, the relationship between query length and summaries, and the method for reconstructing search results in April.

The 2026 Publisher Playbook: 9 strategies to boost acquisition, engagement, and loyalty
Chartbeat’s public report preview gives the share of publisher pageviews attributed to Google Search in July 2024 and July 2026.

Life after SEO: How newsrooms are adapting to the AI search shift
Reuters Institute reporting cites Chartbeat’s year-over-year decline in Google Search referrals to hundreds of publishers and describes what editorial and audience teams at Axios, the Guardian and The Athletic are learning about generative search.

AI in Search is driving more queries and higher quality clicks
Google Search head Liz Reid’s August 2025 account states the company’s position on aggregate organic click volume and defines its measure of click quality.

AI Search Has a Citation Problem
The Tow Center’s original report describes its eight-tool news attribution test, the 1,600-query sample, observed error rates and the limits of inferring access routes from returned sources.

RFC 9309 – Robots Exclusion Protocol
The IETF specification defines crawler instructions by product token and distinguishes the Robots Exclusion Protocol from access authorization.

Overview of OpenAI Crawlers
OpenAI’s technical documentation describes the separate purposes and settings for OAI-SearchBot and GPTBot, the role of ChatGPT-User and the network ranges OpenAI publishes.

Search generative AI control
Google Search Console Help documents the global rollout, the scope of the separate generative AI inclusion control and its distinction from ranking, general search eligibility and AI training.

What is Pay Per Crawl?
Cloudflare’s product documentation confirms the closed beta and explains zone pricing, payment intent in request headers, the HTTP 402 response and the precedence of firewall rules.

A landmark multi-year global partnership with News Corp
OpenAI’s May 2024 announcement describes access to current and archived content at named News Corp publications and permission to display and use content in OpenAI products.

We’re bringing the Financial Times’ world-class journalism to ChatGPT
The April 2024 announcement describes the licensing and product collaboration and specifies how selected FT material could be attributed and linked in ChatGPT.

Generative AI performance report (Search)
Google Search Console Help explains the dedicated report’s impression metric, its breakdowns and aggregation, its supported Search features and its rollout status.

LLM01:2025 Prompt Injection
The OWASP Gen AI Security Project explains indirect prompt injection through external material and describes mitigations including separating outside content, limiting privileges and requiring human approval for high risk actions.

Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection
Kai Greshake and colleagues describe placing hostile instructions in data a language model application is likely to retrieve and demonstrate effects on tool use in tested systems, including a historical version of Bing Chat.

AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents
Edoardo Debenedetti and colleagues describe a benchmark with 97 tasks and 629 security cases and distinguish ordinary task failures from security failures under attack.

Data, privacy, and security for web search in Microsoft Copilot and Microsoft Copilot Chat
Microsoft describes generated Bing queries, the distinct data handling terms for queries and conversations, tenant policy and user controls, and query logging in its named Copilot products.

Increased error rates in Web Search tools in Responses API
OpenAI’s incident record identifies elevated errors affecting web search tools in the Responses API and records recovery on September 5, 2025.

Final Judgment
The December 5, 2025 judgment in the United States and plaintiff states’ Google search litigation records the liability finding and sets out distribution restrictions, data licensing and syndication provisions.

U.S. and Plaintiff States v. Google LLC [2020]
The US Justice Department’s case page records the final judgment and later activity on syndication license templates and appellate briefs.

Alphabet specification proceedings – Sharing of Google Search data
The European Commission explains its July 16, 2026 decision specifying search data sharing measures, including eligibility for search services, limits on uses, anonymization and independent audits.

CMA secures fairer deal for publishers and improves Google search services in UK
The UK Competition and Markets Authority announces the June 3, 2026 publisher conduct requirement for Google search and describes controls on content use, attribution, implementation and compliance reports.

Tools
The Model Context Protocol tools specification defines tool discovery, named invocations, schemas and structured results, illustrating the boundary between interface compatibility and underlying search quality.

About ads in AI-powered experiences in Google Search
Google Ads Help documents sponsored placements inside or alongside its AI search experiences and distinguishes these placements from organic generated responses.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.