Query Rewriting: The Small Brain Before Agent Search

One query, two worlds of meaning

Yesterday, in the middle of a session designing research tooling, a simple question came up: what happens when an agent is told to search for "nano banana"? In a session that was discussing AI models, the meaning is obvious: the nickname of Google's image model. Read without context, it is a fruit at the market. A three-word query, two worlds of meaning, and the search engine never knows which one it is being asked about.

A small case, but it attacks the most fragile point of an automated research pipeline: the earliest stage, before any crawler or ranking runs. Perplexity calls this stage intent parsing and puts it first among the six stages of their pipeline (Ziptie). LangChain formalized the idea in MultiQueryRetriever: an LLM writes several query variants, all of them execute, and the results merge into a unique union (official documentation). That retrieval can fail is not speculation. Anthropic measured that traditional RAG, which drops context during encoding, often fails to find the relevant information, and a retrieval-stage fix cut that failure rate by up to 49% (Anthropic). Those numbers were measured on internal-document RAG, not web search. But the direction of the problem is the same: what breaks is not the machine, it is what gets handed to the machine in the first second.

The five patterns I installed

I did not hire an extra LLM to rewrite queries. What got installed is a behavior rule in the project's AGENTS.md and in the research skill: every raw user query must be expanded into five variants before a single search runs, and the raw material is the context of the running conversation. For "nano banana" in an AI-image session, the output looks like this.

All five variants execute, results merge, duplicate URLs drop. Why five, instead of one polished query? Because each pattern closes a different class of failure. Literal keeps the possibility that the user really did mean something non-technical. Disambiguation catches nicknames like the one above. The English version acknowledges the reality that primary sources are rarely written in Indonesian. The industry synonym chases the vocabulary practitioners actually use, and the full question matches forums, where answers often live.

Two guardrails keep this rule from becoming waste. First, a query that is already specific at eight words or more only needs two or three variants; forcing five just adds noise. Second, when the two possible meanings are too far apart, the agent may ask back. Guessing five times at a question that could be clarified once is not intelligence, it is stubbornness.

The effect on an agent, and its honest limits

This rule now lives in two places at once. In chat, ambiguous queries get covered without the user re-explaining their intent. In the article research cron, the same rule is attached to the research skill, so the automated pipeline shares habits with manual research. Every research dossier now records the five queries used as an audit trail: when results go wrong, those five are the first thing to inspect.

The cost is nearly zero. No extra API calls; the agent itself rewrites the query, using its own head. Only the number of searches grows, at most five times, and only for genuinely ambiguous queries.

What I do not have yet: numbers. There is no published study measuring the effect of query rewriting specifically on web search agents, so I write it as it is. This is a design decision standing on mechanisms already proven in RAG, not a benchmark result. The risk I watch most is over-expansion: five searches for a query that was already clear means five times as many pages to filter. If the rule keeps missing because it depends on model discipline, the next step is ready: move the logic into a separate script with a local model, deterministic and testable. For now, these five patterns make ambiguity covered, not multiplied.