From Question to Cited Report: How Our Research Mode Works

A web search returns three things: a title, a URL and a snippet of about two lines. For a single-fact question, that is enough. "When does the next stage of the EU AI Act take effect?" can be answered from a snippet. The questions that actually come up in companies look different: "Which obligations apply to us if we use generative AI internally, which deadlines apply, and what of this concerns us as a deployer rather than a provider?"

Type such a question into a search engine and you get ten results, each holding a tenth of the answer. The real work starts afterwards: open the results, read, compare, resolve contradictions, write up, note the sources. That is research, and for a question like this it quickly takes several hours.

We built a research mode in TheroAI for this work. In this post, we walk through one run, from plan to finished report. At two points, we also explain why we decided against the obvious design.

Why a Web Search Is Not Research

The assistant in TheroAI can decide on its own to search the web. It formulates a search query, receives a result list with title, URL and snippet, and answers from that. For factual questions, this is the right path. It is fast, and the answer appears in the chat within seconds.

For a multi-part question, this pattern breaks down for three reasons:

• A single search query rarely covers all parts of the question. "EU AI Act obligations deadlines deployer" finds overview articles, but no details on individual obligations.
• Snippets are teasers. The number, the article or the exemption that matters sits in the full text of the page, not in the excerpt.
• The answer is produced in one pass. There is no step in which the model checks its material against the question and notices what is missing.

Research consists of four steps: several searches, actual reading, a check against the original question, and a text with evidence. The research mode maps exactly these four steps.

First Step: The Plan

A research run starts in the same composer as any other question. You pick "Recherche" from the tools menu and send the question.

Enlarge

The model does not start searching right away. It writes a plan first. It decomposes the question into sub-questions. The example question above becomes roughly: Which roles does the AI Act define, and which one are we in? Which obligations apply to deployers of generative AI? Which deadlines apply to which obligation? Which reliefs exist for purely internal use? This plan is visible in the product. Expand the reasoning steps and you see which sub-questions the model has translated your question into.

Enlarge

The visible plan is the earliest point where you can check whether your question came across. If the sub-questions miss the core, the question was phrased imprecisely. You see that within seconds instead of reading it off the finished report minutes later.

Searching Two Spaces in Parallel

For each sub-question, the system then searches two places at once: the open web and the connected company knowledge.

Web search runs through Tavily, a search API built for language models. Instead of a list of links to click through, it delivers already extracted content from the pages it found. The model reads text rather than snippets. In parallel, the system searches the internal knowledge: connected drives, wikis and documents, with the same permissions that apply everywhere else in the assistant. Anyone not allowed to see a document never gets it cited in a research report either.

The sub-questions are independent of each other, so we do not make them wait for one another. All searches in a wave run in parallel. It is the one place in the pipeline where waiting time can be saved without losing quality, and we use it consistently.

Exactly One Reflection Round

After the first search wave, a pile of material is on the table. Now comes the step that separates the research mode from a chained web search: the model lays the material next to the plan and checks what is missing. Did a sub-question remain unanswered? Do two sources contradict each other? Does an important claim stand there without evidence? For such gaps, it may run targeted follow-up searches.

Exactly once. Then it has to write.

The obvious design would be a loop: search, self-assess, search again, assess again, until the model declares itself finished. We decided against that for two reasons.

First, every round costs time. A research run takes minutes, not seconds, and each extra round extends the wait noticeably. That time is well spent when the round closes real gaps. That is exactly what the first reflection round does: it catches the cases where the first search wave missed a sub-question. Further rounds, by contrast, mostly rephrase queries that already ran in similar form.

Second, a loop needs a stopping rule, and "until the model is satisfied" is not one. Language models are poor judges of their own completeness. The same question would end after one round today and after five tomorrow. The runtime would be unpredictable for you, and the behavior would be hard to debug for us. A run with a fixed structure of plan, search, one reflection and report behaves the same way every time. If a report comes out thin, we see in the plan what went wrong, instead of hoping that one more round would have fixed it.

This decision has a price, and we name it: there are questions where a second reflection round would have found more. We still consider the trade right. A tool whose runtime you can estimate gets used in daily work. One that runs three minutes one day and fifteen the next gets avoided.

The Report: Executive Summary and Numbered Sources

The run does not end in a long chat paragraph. The model writes a structured report. It opens with an executive summary that states the answer in a few sentences. Then come sections along the sub-questions from the plan. Every substantial claim carries a numbered source reference, and at the end of the report sits the source list with links.

Enlarge

The numbers are the difference between a report and an opinion. You derive a decision from the report, or you forward it to someone who does. That person must be able to check whether the source behind reference 3 really says what the report claims. With the reference, that is one click. Without it, they would have to repeat the research.

That is why a hard rule applies in the writing step: a core claim with no source in the collected material does not belong in the report. It sounds obvious. It is still the single most important instruction we give the model for this step.

The Sources Menu Is Part of Answer Quality

Next to the composer sits an inconspicuous menu with more influence on the report than it appears to have: the source selection.

Enlarge

Five options are available:

• Automatic: The model decides per question whether to search internally, publicly or in both spaces. The default for most cases.
• Company knowledge only: Only what is in your connected sources counts. No search query leaves the system.
• Public sources only: Only the open web, for example when you deliberately want the outside view.
• Combined: Company knowledge and public sources in one run, when the question demands a comparison, for example internal policy against current law.
• No external sources: The model works only with the conversation and its training knowledge. Useful for rewriting and structuring, where search results would only be noise.

Why is this menu part of answer quality? Because the same question means something different against different sources. "How do we handle remote work from abroad?" is, against company knowledge, a question about your policy. Against the open web, it is the question of how anyone handles the topic. The answer sounds just as fluent and is still the wrong one. The other way round, "Which reporting obligations apply from 2026?" answered from internal sources alone tends to return last year's summary, while the web knows the current state.

A wrongly chosen search space does not produce a recognizably wrong answer. It produces a fluent, neatly cited answer to a different question than the one you meant. That is why we treat the source selection as part of the question and place it visibly next to the composer instead of burying it in the settings.

Web Search or Research Mode?

Both modes have their place. Web search is the everyday default. Research mode is the tool for questions whose answer you have to forward, file or defend.

What You Can Take Away

• Ask factual questions in the normal chat. Research mode pays off as soon as the answer needs structure and evidence.
• Give the question context: what you need the answer for and in which role you are asking. The plan then matches the question far more closely.
• Expand the plan as soon as it appears. If the sub-questions are off, sharpen the question and start a new run. That costs seconds; a report on the wrong question costs minutes.
• Choose the search space deliberately. Internal question, internal sources. Legal situation and market, public sources. When in doubt, automatic.
• Check the numbered sources wherever the report carries a decision. That is what they are for.