Ask most legal-AI tools a genuinely broad question and you get one answer. "Assess the risk across IP ownership, data protection, indemnity caps, change of control, and the non-compete." Five real issues, one response, and the response spends most of its attention on whichever issue the retrieval happened to surface first. The other four get a sentence each.
That is not how a lawyer works a question like this. A lawyer splits it into sub-issues, researches each one properly, and only then reasons about how they interact: the non-compete has different teeth after a change of control, the indemnity cap is close to meaningless if the IP ownership is contested, and so on. The synthesis is the work. This post walks through the deep-research engine we actually run for multi-issue questions: how a broad request is broken into dimensions, how each dimension gets its own retrieval, how the parts are woven back together, and, at the end, a test you can run against any tool to see whether it does the same or just blurs everything into one shallow paragraph.
First, when this even fires
One-shot RAG is the right tool for a single question. It is the wrong tool for a request that is secretly five questions wearing a trench coat.
So the first decision is a gate, not a pipeline. The engine only takes over when the message is a research request that spans several distinct areas. It looks for a research trigger ("deep research," "research the following areas," "research each of these issues") and then parses out the actual list of areas. If it finds at least three distinct areas, it runs the multi-dimension path. Below three, it hands the question back to the normal single-answer path, because a two-part question does not need this machinery and would pay for depth it cannot use.
Parsing the list sounds trivial and is not. It handles numbered, lettered, and bulleted lists, inline enumerations, and the loose "research these: a, b, c" phrasing. The subtle rule is the one that decides where an area ends. "Data protection and cross-border transfers" is one area, not two, even though it contains the word "and." So the parser prefers to split on new lines and only falls back to splitting on "and" or commas for a genuine single-line list, precisely so a multi-word area is not shredded into phantom dimensions. Boundary detection is where this earns its keep: the goal is to research exactly the set of questions you asked, no more and no fewer, so the parser is deliberately conservative about where one area ends and the next begins.
The whole engine, from the gate to the two things that come out the other end, looks like this.
The plan: map how the areas relate before researching any of them
Here is the decision that separates this from running N searches in parallel and stapling the results together.
Before any research runs, a planning pass looks at the whole request and the first-pass list of areas and does three things. It refines the areas, merging obvious duplicates and splitting an "area" that is really two. It maps how the areas relate to each other, recording for each interacting pair whether the relationship is a dependency, a tension, or a trade-off. And it writes a one- or two-sentence framing of how the areas fit together as a whole, the throughline.
Simplified, the plan it produces looks like this:
{
"dimensions": ["IP ownership", "License scope", "Change of control", "..."],
"interdependencies": [
{"between": ["IP ownership", "License scope"], "note": "scope is moot if ownership is contested"},
{"between": ["Change of control", "Non-compete"], "note": "CoC can trigger or void the covenant"}
],
"framing": "One transaction; the covenants only matter as a package."
}
That is not decoration. Each area's research is handed the sibling areas plus any recorded links that touch it, so a section can say "this bears on the change-of-control analysis" instead of pretending it is the only issue in the world. The integration pass at the end gets the whole link map. If this planning step fails for any reason, the engine degrades to the plain list of areas with no link map and keeps going. The memo still gets written; it just loses the up-front coordination.
Fan out: each dimension gets its own retrieval
Now the areas are researched in parallel, but each one is researched as if it were the only question you asked.
For a single area, the engine runs two retrievals at once. The first is our own full query pipeline over the firm corpus and, if the question is attached to a matter, your matter documents, on the deep research tier. This is the same hybrid retrieval and reranking that backs a normal deep answer, pointed at one area. The second is a real web research pass, and "real" is the operative word. It is not one search. A planner proposes several distinct web angles for the area (governing rules, leading authorities, recent developments, practical or market standards, likely edge cases), we run all of them in parallel, and then a gap-finder reads what came back and proposes focused follow-up searches to drill into whatever is still thin. Breadth first, then one round of depth, the way a person actually researches, so a single area runs on the order of eight to twelve searches rather than one. The concrete bounds: a bounded number of planned breadth angles plus a bounded set of gap-filling follow-ups per area, several results pulled per query and de-duplicated by URL, with the searches inside an area run concurrently. At the outer level the engine fans out to a bounded number of areas and researches a few of them at a time under a concurrency limit, so a large request stays parallel without stampeding the retrieval and web backends. The corpus retrieval and the web pass for one area also run at the same time as each other, so an area is not waiting on one before starting the other.
Then the section gets written, and this is where trust is either built or lost. The writer is given a single numbered list of sources, the ones retrieval actually found, and told to write the section using only those sources. Every factual assertion, rule, holding, figure, or quotation has to carry an inline bracketed citation whose number points at the source it came from. No claim without a citation. If the sources are thin on a point, the instruction is to say so plainly rather than paper over it. And because the areas are interrelated, the section is also told to flag where its area bears on another area and name it, without wandering off to research it.
Why the citation numbers can be trusted
A cited memo is only trustworthy if the [4] you click is actually the fourth source. That is a plumbing problem, and it is easy to get quietly wrong.
Inside one section, the model cites its sources locally: its [1] is the first source that section was given. But the finished memo has one continuous source list across every area, so a local [1] in the third section is not the first source in the report. The orchestrator renumbers every section's citations to their global position as it assembles the memo, and it stamps each source with a unique identifier keyed to that global number. That last part matters more than it looks. Downstream, sources are de-duplicated by identifier, and without a unique stamp, web sources (which carry no natural id) would all collapse into one, and same-document corpus chunks would merge. Either would shift the source array by one and silently desync every citation after it, so a reader clicking [7] would land on the wrong passage. The synthetic per-citation identifier keeps de-duplication a no-op, so the Nth inline marker resolves to the Nth card, every time.
The synthesis: the part that is not a summary
If the engine stopped at five well-cited sections, it would be a stack of mini-memos. The value is in the pass that comes next.
After the sections are written, a final integration pass reasons across them. It is explicitly not a summary of each section. It is told to surface the connections and dependencies (how the areas interact, what one implies for another), the tensions and trade-offs (where the areas pull against each other and how to resolve them), and the conflicts in the evidence. That last one is a small but real piece of judgment: where sources disagree, it weighs them by authority and recency rather than averaging them into mush. It ends on the bottom line, the combined recommendation and the highest-priority next steps. It carries the inline citations forward, so even the synthesis stays clickable back to a source rather than becoming an unsourced opinion at the end.
This is deliberately the concise part. The framing and this integrated analysis are what stream into the chat as the answer you read first: a short, dense, cited lead. The deep per-area sections, which are long, go somewhere else.
The memo artifact, rendered verbatim on purpose
The full research, every area with its sources, is saved as a Word memo attached to the message. There is one design choice here worth spelling out, because it is the kind of thing that is invisible when it works and corrosive when it does not.
The obvious way to build the memo would be to hand the assembled text back to a model and ask it to author a nice document. We do not. A model re-authoring the memo caps its own output length, so a long five-area memo would silently truncate, and the fallback path tends to strip the bracketed citation markers, which is the one thing we cannot lose. Instead the memo is rendered verbatim through a citation-aware document renderer. The markdown goes in exactly as written, the length is whatever the research produced, and every inline marker is preserved and linkified to its source's URL. The reader gets a Word file where the reasoning is intact and every claim still traces to where it came from.
Built to degrade visibly, never silently
Depth means more moving parts, so we designed each one to surface a gap rather than hide it. The design goal is simple: if any part cannot complete, you see exactly which part, never a quietly dropped issue.
If retrieval finds nothing for an area, that section says so plainly: no sources in the corpus, your documents, or the web, try enabling more sources or narrowing the area. If writing a section errors out, it is replaced with a visible marker telling you to re-run, not omitted. If the up-front planning fails, you lose the link map but still get every area, and if the final synthesis fails, you still get the sections. The engine also caps the number of areas it will fan out to and reports the truncation rather than hiding it. A shallow tool hides its gaps behind fluent prose; ours openly tells you which corner it could not cover, so you always know exactly how much of the question was answered.
Test any deep-research tool yourself
You do not need our code to judge this. You need one genuinely multi-issue question and five minutes.
-
The five-issue question. Give the tool a real question with several distinct sub-issues ("assess IP ownership, data protection, the indemnity cap, change of control, and the non-compete in this deal"). A strong tool addresses each issue on its own terms with its own citations. The tell of a weak one: one flowing answer where two issues are analyzed and the other three get a passing mention, all citations pointing at the same couple of sources.
-
The interaction test. Read the answer and ask whether it ever says how the issues affect each other, for example that a change of control changes the non-compete analysis. A strong tool has a synthesis that reasons across the issues. The tell: five tidy paragraphs that never once reference each other, which means nothing was actually synthesized.
-
The per-issue citation test. Pick the sub-issue you know least about and check its citations specifically. A strong tool cites sources that are actually about that issue. The tell: every issue leaning on the same generic source, which is the signature of one shallow retrieval stretched across five questions.
-
The conflicting-evidence test. Choose a question where good sources genuinely disagree. A strong tool names the disagreement and takes a reasoned position on which authority controls. The tell: a confident single answer that shows no awareness the sources ever conflicted.
-
The coverage-honesty test. Include one sub-issue that is obscure enough that the tool probably cannot find good sources. A strong tool tells you it came up thin on that issue. The tell: an equally confident, equally long paragraph on the issue with no support, which is where fabrication lives.
And the questions to ask the vendor
The prompts test the product. These test whether the team behind it thought about the problem.
-
When I ask a five-issue question, do you research each issue separately or run one retrieval for the whole thing? One retrieval for five issues is one shallow answer no matter how it is formatted.
-
Do you produce a synthesis that reasons across the issues, or a list of per-issue summaries? Those are different products, and only one of them is worth the wait.
-
Does every claim in the output carry a citation to a specific source, including in the synthesis? An unsourced conclusion at the end quietly undoes the sourcing above it.
-
When the final document is long, is it re-generated by a model, and does that risk truncating it or dropping citations? Ask, because the failure is invisible until the memo you needed is the one that got cut off.
-
What do I see when you cannot research one of the issues? A tool that always sounds equally confident on every issue is telling you it does not know when it is guessing.
A vendor who answers these concretely is doing the actual work of research. A vendor who points at how comprehensive the output looks is selling you the length, not the reasoning.
