Query Fan-Out

Query fan-out is the technique of decomposing a single user question into many sub-queries, issuing them in parallel, and synthesising an answer across the combined results. Google has described AI Mode as using a query fan-out technique that runs multiple related searches across subtopics and data sources before composing a response, and the same pattern is what makes an agentic search product bill one user question as ten or twenty API calls.

It exists because one query string is a poor retrieval unit for a compound question. "Is this vendor a safe choice for a regulated deployment" contains at least four separable retrieval jobs: what the product does, what its compliance posture is, what its funding and stability look like, and what recent incidents exist. Sent as one query, it retrieves pages that talk about all of it shallowly. Split into four and run in parallel, it retrieves the specific page that answers each part, and the synthesis step sees better evidence. The cost of that quality is arithmetic: N retrievals per question, plus the tokens to read all of them.

The visibility consequence is that your page no longer competes for the question a user typed. It competes for sub-queries you never see, cannot check in a rank tracker, and can only infer. A page can be cited in an answer to a question it does not rank for, because it was the best result for one decomposed sub-query, and a page ranked first for the headline query can be absent from the answer entirely. This is the mechanism that most generative engine optimization advice is reaching for without naming: covering sub-questions explicitly, answering each in a self-contained passage, and keeping the answer near the top of its own section works because those passages are what the sub-queries retrieve.

The cost consequence lands on a different team and usually later. Vendor pricing pages quote a rate per search or per request, and a build estimate written from that rate is wrong by whatever the fan-out factor turns out to be. Instrument searches-per-user-question in your first week of production traffic, because it is the number that determines your unit economics and it is rarely the number anyone assumed. Pricing models split on where the fan-out sits: answer-level APIs such as Perplexity Sonar absorb the searches behind one request and bill the composed answer, while search-level APIs such as Exa and Tavily bill each sub-query you issue, which means the fan-out is visible on your invoice and under your control. Neither is automatically cheaper. Compare cost per answered question rather than cost per call, since the fan-out factor is what sits between the two. Check each vendor's published rate as of the date you build the model; these pricing pages change.