Mozilla AI asks: Who searches the web for your agent?

Mozilla AI is challenging bundled agent search with Otari, which lets teams choose a search service independently of their model. Who searches the web for your agent? Its October 19 post makes that question concrete: choosing an AI model does not necessarily tell you where its search queries go.

Otari sits between an agent, software that uses tools to complete tasks, and the model provider. Mozilla AI says that position lets it redirect searches while preserving supported client interfaces. The proposed change concerns who controls information retrieval, rather than which model writes the answer.

The competing approaches are straightforward: accept search bundled with a model service, or manage search as a separate dependency. Claude Code provides a useful reference because its built-in search uses Anthropic’s backend. Otari challenges that arrangement by making search routing an independent decision, with additional responsibility for whoever makes it.

Who searches the web for your agent? Otari makes the choice explicit

In its agent search analysis, Mozilla AI describes three choices: Otari-operated search, a customer’s search account, or a self-hosted endpoint. The company names Brave, Exa, and Tavily among the services customers can connect using their own credentials.

According to Mozilla AI, customers can retain Claude, GPT, or Gemini while changing the service that handles searches. Search credentials stay in the gateway, the intermediary that routes requests, rather than reaching the agent. The company also describes workspace controls and search records associated with model usage.

The consequential change is making search a dependency teams can select separately from the model.

That distinction is easy to miss when an application presents a single answer box. A user asks a question, waits, and receives a response containing citations. The interface can make retrieval and reasoning look like one operation, even when different services perform them.

Separating those operations changes how buyers assess the system. A model evaluation answers whether the model follows instructions and reasons effectively. A search evaluation asks whether the system retrieves suitable evidence, handles queries acceptably, and supports the organization’s operating requirements.

Neither evaluation substitutes for the other. Good reasoning cannot recover a document that never entered the evidence set. Strong retrieval cannot prevent every unsupported conclusion. Treating them separately gives teams a clearer way to investigate failures without attributing everything to the model.

Mozilla AI’s post should also be read accurately as a statement of product direction and documented capabilities. Its publication date does not establish when every underlying feature became available. Nor does the announcement establish that customers have already achieved better answers or lower operating costs.

The immediate news is therefore narrower than a claim that agent search has been solved. Mozilla AI is making the search supplier an explicit part of the purchasing and architecture conversation. That creates a practical alternative to accepting whatever retrieval service accompanies a chosen model.

For teams already satisfied with bundled search, the alternative needs to justify its operational burden. For teams blocked by an unacceptable search arrangement, separating that dependency addresses a different problem entirely. They need a choice they can evaluate, rather than another model leaderboard.

The query itself deserves scrutiny

A search query is an outbound disclosure, even when the requested answer concerns public information.

Consider a hypothetical coding assistant investigating a software failure. The useful public query might describe an error message and a library version. An unnecessarily specific query might also include an internal service name, a customer identifier, or an unreleased project name.

The distinction concerns what leaves the organization, not whether public documentation is safe to read. An assistant can have a legitimate reason to search while still constructing an inappropriate query. Selecting the search supplier addresses the recipient; reviewing query construction addresses the content.

That separation matters for engineering managers and enterprise buyers. Approving a model does not answer every question about tools attached to it. Each additional service introduces an operational relationship that deserves its own assessment, particularly when queries originate from private working context.

The sensible response is to trace an actual task. What information entered the prompt? What text became a search query? Which service received it? What results returned, and which of those results influenced the answer?

These questions make a purchasing discussion more concrete. They also expose where a claim stops. Knowing the destination establishes visibility into routing. It does not establish that every query was necessary, appropriately worded, or covered by acceptable handling terms.

The same reasoning applies to customer research. Imagine an assistant preparing a briefing about a prospective account. Public company information belongs in the research process. Private sales notes, proposed contract language, and internal assessments require a separate decision before appearing in external queries.

These are illustrative scenarios, not documented Otari customer deployments. Their value is showing why search selection matters beyond developer preference. An apparently ordinary lookup can cross a boundary that the final answer does not reveal.

Knowledge workers also need a distinction between public discovery and searching their own material. A personal knowledge base addresses an information need that differs from finding new public sources. An effective workflow should identify which kind of evidence the task requires before choosing where to search.

For a product manager, that might mean consulting internal research before requesting current competitor information. For an engineer, it might mean checking private design decisions before looking up public documentation. The point is purposeful retrieval, rather than sending every uncertainty to the open web.

This places pressure on the people approving agent deployments. They need enough visibility to explain the information path, including its limits. A product that exposes the search destination can support that explanation, but the organization must still decide what information belongs on that path.

Who searches the web for your agent? For buyers, an adequate answer includes the operator, the relevant agreement, and the scope of information sent. Naming a recognizable model alone leaves the search portion of that answer unfinished.

Bundled search offers convenience, while separate search adds accountability

The strongest case for bundled search is convenience. A developer receives a supported tool interface without assembling every part of retrieval. An organization can prefer that arrangement when its requirements align with the provider’s service and documented behavior.

Anthropic’s web search tool illustrates the integrated approach. Claude determines when to search, the service executes searches, and the final response includes citations. Its documentation also describes domain controls and different tool versions.

Those capabilities matter because configurable search is not unique to an independent gateway. Customers should distinguish controls over search behavior from control over the search supplier. A provider can expose useful restrictions while retaining responsibility for operating the underlying service.

The central choice is who owns retrieval decisions and the work required to maintain them.

Otari’s proposition appeals to teams that want that ownership. But independence introduces responsibilities that bundled services absorb or simplify. Someone must manage credentials, assess service behavior, investigate failures, and maintain a working relationship between the agent and its search tools.

Ollama offers another useful comparison. Its hosted web search documentation specifies an authenticated request to ollama.com/api/web_search. The response includes results containing page titles, addresses, and content snippets.

That example establishes a limited but important point: using a local model does not establish that its web searches stay local. The documented search request reaches a hosted service. Customers need to examine inference, search, and page retrieval separately when assessing where processing occurs.

This is not evidence that hosted search is inherently unsuitable. A hosted service can be an acceptable choice when its terms, behavior, and reliability meet the organization’s needs. The relevant failure is assuming that one architectural choice automatically determines every other component.

The same discipline applies to answer quality. Changing search services changes the evidence available to the model. An evaluation that changes the model and search simultaneously cannot easily explain which change improved or damaged the result.

Separating those variables supports more informative comparisons. Teams can hold the model constant while examining retrieval, then hold the evidence constant while examining synthesis. Such evaluations still require careful design, but they avoid treating the entire application as an indivisible black box.

An Otari web search evaluation should therefore begin with the team’s own tasks. Public documentation lookup, recent company research, and specialized technical discovery can require different evidence. A universal claim that one search service is best would need evidence extending beyond those individual workloads.

Mozilla AI’s announcement provides no independent comparative study establishing such a winner. The stronger reading is that customers should be able to choose and test the dependency. That is an argument for control and evaluation, rather than a demonstrated ranking of search engines.

The pressure falls on both approaches. Bundled providers need to explain their search arrangements clearly enough for buyers to assess them. Independent infrastructure needs to show that additional control remains usable when clients, models, and tool interfaces change.

Otari web search depends on preserving the client’s expectations

A configurable search service helps only if the agent can use it correctly. Applications expect more than a list of links. They depend on recognizable tool responses, error behavior, and enough source information to continue the task.

Otari’s search interception documentation describes taking over supported provider-named search declarations when interception is enabled. Interception means handling a request that would otherwise go to the provider’s tool. The documentation distinguishes that behavior from forwarding provider-native requests.

It also describes workspace restrictions, including disabling search, limiting results, and narrowing domains. The documentation warns that the bundled SearXNG setup is rate-limited for sustained use. That warning matters when evaluating production readiness rather than a short demonstration.

Preserving the interface reduces integration work, but it does not establish identical behavior.

A client can accept a response while receiving different evidence. It can also handle a successful lookup correctly while reacting poorly to an unavailable service. Compatibility therefore needs to cover ordinary operation and the cases that interrupt it.

A hypothetical coding task makes the difference visible. An assistant searches for a migration guide, reads the result, and proposes a code change. A useful evaluation asks whether the retrieved guide matches the relevant software version and supports the proposed change.

The same task should remain understandable when search returns nothing. An agent that clearly reports missing evidence behaves differently from one that improvises an answer. The gateway’s response format matters, but so does the client’s interpretation of failure.

This is where comparisons based only on answer fluency become misleading. A polished explanation can conceal weak evidence. A less polished response that identifies its limits can be more useful for a consequential technical decision.

Otari’s search configuration documents named search instances and a default selection. It also describes provider-specific settings and requirements for credentials. These details show that search independence is an operating configuration, rather than merely a preference expressed in a prompt.

For platform teams, configuration brings familiar maintenance questions. Who can change the default? How does a change reach different workspaces? What evidence shows that a request used the intended service? The answers determine whether control survives normal organizational activity.

A setting can exist without becoming an effective policy. An evaluation needs to establish what happens under the actual deployment configuration, including permitted exceptions. Otherwise, a demonstration of selectable search risks being mistaken for assurance about every production request.

The distinction becomes especially important when an application has several ways to reach external information. A search tool, a page fetcher, and a browser can represent different paths. Controlling one path does not establish control over all of them.

That observation is an architectural consideration, not a finding that Otari has a specific bypass. Buyers should ask for coverage evidence that matches their clients and enabled tools. Broad phrases such as “all agent traffic” require broader verification than a successful intercepted search.

The mechanism is promising because it places a routing decision outside the model’s judgment. Its practical value depends on whether the surrounding application consistently uses that controlled route. The evaluation must follow the complete task, including the moments when the expected route fails.

Self-hosting changes responsibility without eliminating dependencies

Running the search intermediary yourself does not mean operating an independent web index.

SearXNG’s metasearch architecture aggregates results from other search engines. That makes the meaning of self-hosting precise: an organization can operate the aggregation service while still relying on upstream engines for results.

For an Otari deployment using SearXNG, that distinction prevents an inflated privacy claim. The operator controls its instance, but the instance’s configured upstream relationships still matter. A complete assessment follows the query beyond the organization’s first server.

This is a useful skeptical test of the broader message. If self-hosting is presented as complete independence, metasearch complicates that promise. If it is presented as control over a defined component, the claim is narrower and easier to evaluate.

The same discipline should govern cost comparisons. Removing a bundled search charge does not remove the work of operating retrieval. Infrastructure, maintenance, incident response, and staff attention belong in the assessment, even when they do not appear as a per-query bill.

There is no basis here to declare self-hosting universally cheaper. The relevant comparison depends on workload, service requirements, and the organization’s existing capabilities. A team already operating related infrastructure faces a different decision from a team without that expertise.

Credential control also needs a precise interpretation. Keeping credentials away from the agent reduces one exposure path. The service holding those credentials remains a sensitive system that requires appropriate administration and access controls.

Search records create another tradeoff. They can help explain why an agent produced an answer, but they can also preserve sensitive query text. An organization seeking accountability should decide who can inspect those records and how long they remain useful.

More visibility therefore creates a governance task of its own. Detailed records are not automatically better in every context. The goal is sufficient evidence for investigation, with handling rules appropriate to the information those records contain.

Domain restrictions have similarly bounded value. They can constrain the pool of eligible sources. They do not establish that every page from an allowed domain is accurate, current, or appropriate for the specific task.

Nor does choosing a search supplier solve prompt injection, malicious content designed to redirect an assistant’s behavior. Retrieved pages remain external inputs. An agent must handle them as evidence to assess, rather than instructions with authority over its task.

These limitations do not invalidate the case for independent search. They define what the case can support. Selecting a dependency gives organizations a place to exercise judgment; it does not guarantee the judgment will be correct.

The credible outcome is greater accountability for identifiable choices. A buyer can ask why a service was selected, what assumptions support it, and what would trigger a change. Those questions remain valuable even when the chosen answer is a managed provider.

An Otari web search deployment should be judged against those concrete responsibilities. The announcement alone does not establish superior retrieval, universal compatibility, or a complete privacy outcome. Evidence from a team’s actual environment must carry those conclusions.

Watch compatibility, comparative evidence, and provider disclosure

The next reporting window should focus on observable changes rather than promises about a more open AI stack. Through late 2026 and early 2027, the useful signals concern whether independent search becomes easier to operate and easier to assess.

The strongest evidence will show dependable control during real tasks, including failures and changes.

The first signal is published compatibility evidence for the clients and tool interfaces teams actually use. A useful release would identify tested behavior, supported versions, and known limitations. Reproducible examples would strengthen the case that customers can retain their applications while changing search.

Conversely, repeated client-specific workarounds would weaken the practical claim of independence. A theoretically replaceable service offers limited freedom if each replacement requires substantial application repair. Compatibility needs to remain understandable as the surrounding software evolves.

The second signal is comparative evaluation with a controlled workload. Hold the model and tasks constant, then examine retrieval relevance, freshness, response time, failures, and total operating effort. The outcome should identify where each arrangement works, including cases where bundled search remains preferable.

A convincing evaluation would publish enough detail for readers to understand its boundaries. Results from documentation lookup should not become claims about every research task. Evidence of selective benefits would be more credible than an unexplained declaration of overall superiority.

The third signal is clearer disclosure or additional supplier choice from bundled providers. More explicit documentation would help customers assess existing services without adopting another intermediary. Provider-supported selection would also test whether customers primarily want independence or simply clearer controls.

That development would strengthen Mozilla AI’s underlying argument while changing Otari’s competitive position. Search would become a more visible purchasing decision even if buyers exercised that choice elsewhere. The lasting issue is who can make and explain the decision.

Who searches the web for your agent? The answer should become more specific as these signals develop. It should identify an actual information path and the evidence supporting its use, rather than relying on assumptions drawn from a model’s name.

Before expanding an agent workflow, review a representative task from prompt to final answer. Identify the outbound query, its recipient, the returned sources, and the evidence supporting the conclusion. Then ask whether the arrangement matches the sensitivity and purpose of the work. Keep bundled search when its documented behavior meets those needs. Evaluate a separate search service when supplier choice, operating control, or clearer records address a concrete requirement. For tasks combining private knowledge with public research, examine that boundary explicitly rather than treating every lookup alike. The useful next step is a decision your team can explain: which search service should this agent use, and what evidence justifies that choice?