Deep research returns reports with coverage and gaps, not raw text

A question like "Summarize last quarter's incident root causes across our three products, and compare how the industry responded to each cause" takes more than one search. The agent has to dig through three internal databases, documents and the web. When a single agent works through those branches one after another, the query results and web page excerpts from every branch pile up in one conversation. By the time it reaches the fourth branch, most of the model's input is source text from branches that are already finished. Information from a subtask that stays in the context after the next task no longer needs it is called context pollution.

Deep research splits the work in two. The lead makes the plan, hands out branches and writes the final report. A researcher investigates one branch in its own context and returns a short report to the lead instead of the source text. But dropping the source text also drops what the source text told you: whether a result covers everything or only part, and what the researcher failed to find. This post explains how the report carries that information instead, and what stops the lead from going back to researching on its own.

#Every way of trimming the source text loses something different

Splitting the work across researchers does not solve the problem by itself; it depends on how the results come back. There are three common approaches.

The third approach is the lightest, but what it leaves out matters. Suppose a researcher queried only the 50 most recent incident tickets and wrote "the main cause is deployment mistakes." That sentence looks exactly like a conclusion drawn from every ticket. The lead has no way to tell the difference and carries a conclusion from a sample into the report as fact.

So we fixed the report format. A researcher does not pass on the source text; it writes the sources, coverage and gaps that the source text would have shown into set sections.

#Researchers report in fixed sections, and coverage can never be empty

A researcher works only from the task description the lead wrote. It sees neither the conversation, nor the user, nor other researchers' work. When it finishes, its last message is the report, and that report reaches the lead's input as a single tool result (“One agent loop for every feature, with the differences in hooks”). A report is usually well under a page and has these sections.

Other sections may be left out when empty, but coverage is always filled in. Without it, the lead cannot tell a complete answer from a sample. In the incident ticket example, coverage would read "queried only the 50 most recent tickets; total for the quarter not checked," and the lead uses that line to decide whether to send a follow-up.

Findings are written in business language. Table and column names and queries go only in the source notes, and only when a follow-up needs them. The readers of a report are the lead and later-stage researchers, none of whom saw the source text.

Because the format is fixed, the server reads reports by rule, without a model call. The progress screen shows the first line of each report's findings as that researcher's one-line summary.

#Later-stage researchers start from four sections of the earlier report

Branches often depend on each other. You need the list of incidents per product before you can look up each incident's patch history. So every plan item must state its stage and its prerequisite items. If either is missing, the plan tool rejects the plan. A dependent item's researcher cannot be started until the researcher for its prerequisite has finished.

Within a stage, every item that can be started now must go in one call. Without this rule, the model starts one researcher per round. One model we measured started four stage-one items that way, and the last researcher set off 13.6 seconds after the first.

A later-stage researcher cannot see earlier researchers' work, so the system attaches two things after the task description. One is the overall plan with the researcher's own item marked. The other is four sections from each prerequisite item's report: findings, coverage, source notes and gaps. The researcher skips what the findings already established, goes straight to the databases and tables named in the source notes, checks the coverage to see whether the earlier work saw everything, and reads the gaps to see what is still unknown. Conflicts and leads are not passed on. Deciding which source to trust and which clue to follow is the lead's job.

The attached amount has a cap: 6,000 characters per prerequisite item and 12,000 in total. The attachments we measured were 1,054 and 1,382 characters, so the cap is rarely reached; it exists for exceptions such as a report with a whole table pasted in. When the cap is hit, lines are cut from the end, so the order of the four sections is the order of what survives. Where text was cut, a marker points to a tool that reads the earlier report in full. That tool can read only the reports of the researcher's own prerequisite items.

#The lead's own research calls are capped by count

A design that hands the lead only reports falls apart as soon as the lead starts researching by itself. If deep research is on and the lead calls data and web tools directly, it gets the source text back and recreates the very context the design was meant to avoid. In production, one self-hosted model called data and web tools 13 to 24 times directly, with no plan and no researchers, and then went straight to the report. It did so even with the prohibition written into the prompt.

So the lead's tool calls are checked before they run. Until the plan is confirmed, the lead may make only scoping calls (table search and document search) that show which database or collection holds the topic, up to 4 by default. Query execution, web search, connector calls, starting researchers and the final answer are rejected with a reason telling the lead to propose a plan. The plan is confirmed only when the user clicks Start research on the plan card.

Even after every item has a researcher, the lead may make at most 3 research calls of its own by default. In a test environment, after three researchers used up their budgets, the lead called read-only SQL ten times itself to fill the holes. Calls past the cap are rejected with a reason telling the lead to send a follow-up researcher for the gaps. Both counts can be changed in the configuration file with agentLoop.researchLeadScopingCalls and agentLoop.researchLeadOpenPhaseCalls.

If rejections keep coming, the next round is set to require the plan tool or the researcher spawn. If the model still doesn't comply, the limits are lifted for that turn. A turn that can't end because its answer is blocked is worse than an answer without a plan.

#Before the report, the lead reviews the gaps and has key claims checked against other sources

The lead receives only reports, so it cannot use the source text to catch a wrong finding. That is why, once the researchers for every plan item have finished, the server gives two instructions before the report is written.

The first is a follow-up review. For each finished researcher, the server collects the coverage, gaps and leads sections (up to 1,500 characters per researcher), shows them to the lead and asks it to decide whether to send follow-up researchers. A researcher that failed or was stopped appears as a single line saying its part is empty. A review runs each time a new report comes in while there is still time to start researchers, up to 2 per turn by default.

The second is verification. The lead picks the key claims the report will rest on and hands them to a verifier. The verifier tries to refute each claim rather than confirm it. For each claim it looks for a source other than the one the claim came from, and gives one verdict: supported, refuted, partly wrong, out of scope or not cross-checked. Rereading the same source does not count as a cross-check, even when it says the same thing. Without that rule, a verifier rereads the footnote a claim came from and passes even a bibliographic error as "confirmed." The verification instruction also lists links that researcher reports cited but that nobody opened during the turn. An address seen only in search results can turn out to be a page that doesn't exist, and such a page has ended up cited in a report.

Verification runs once per turn, and only when researchers still have more than 5 minutes to work (agentLoop.researchVerificationMinSeconds, 300 seconds by default). A verifier with a few seconds left returns most claims as "not cross-checked."

The instructions come before the report for a reason. Rejecting a finished report and sending it back gives the rule an obvious place to sit, but in a test environment Claude Sonnet 5.5 then rewrote its report two or three times. When the review and verification are finished before writing, the report comes out in one pass.

#Design choices

The lead sees only the reports. As a result, however many researchers run, the lead's input holds only a report of under a page per branch. The cost is that whatever a report misses, the lead misses too. To reduce that cost, coverage is a required section, and the server instructs the pre-report review and verification. Passing the source text along would let the lead judge more accurately, but it would erase the reason for splitting the branches.

Reports are read by rule. A section heading with a modifier or a count attached is accepted, but a report that renames a heading to a different word gets no summary on the progress screen. Cleaning up a malformed report with a model would add calls and give a different result each time, so we chose to leave the summary empty.

Because the lead's own research is capped by count, even a small check the lead could finish quickly has to go to a researcher. That adds model calls and time, on top of plan approval and verification. This is why deep research runs only when the user turns it on. If a question needs several branches and each branch piles up long source text, turn on deep research; if one branch will do, an ordinary question saves time and usage.