How Deep Research Works
Moving from a broad question to a source-backed report a team can actually act on — scope, evidence, synthesis, and the handoff that follows.
Product and platform · · 9 min read
Most research output fails for one of two reasons: nobody can tell which parts are observed and which are inferred, or it arrives with no obvious next action. Both are structural problems, and both are fixable before the first source is read.
Start from the decision, not the topic
“Research our competitors” produces a document. “Decide whether we should ship a free tier this quarter, and what it would need to include” produces an answer. The difference is that the second one has a failure condition — you can tell whether the research succeeded.
Framing by decision also bounds the work. A topic is infinite; a decision has a small number of things that would actually change the answer. Those things are the scope, and everything else is optional colour.
In practice the most useful opening move is to write down what you would need to believe to choose each option. Those beliefs are the research questions.
A topic is infinite. A decision has a finite number of things that would change the answer.
Separate what is observed from what is concluded
The single most common defect in research output is a confident sentence that silently mixes a fact, an inference, and an opinion. A reader cannot challenge it without re-doing the work, so they either accept it wholesale or discard it wholesale.
Deep Research keeps findings attached to the sources that produced them, so the chain is inspectable. A finding says what was seen and where. A conclusion says what the team should infer. They are different objects and they read differently.
This matters most for the claims that are load-bearing. If one source is carrying an entire recommendation, that should be visible on the page rather than discoverable only by someone who goes looking.
Say what you could not establish
A report that answers every question it raised is usually a report that quietly dropped the hard ones. Open questions are not a failure state — they are the most valuable part of the document, because they tell the team where the risk actually sits.
An unresolved question with a note on what would resolve it is far more useful than a confident guess. It converts an unknown into a task.
Three things worth stating explicitly
- What the evidence supports directly, with the source attached.
- What is being inferred, and how large the inferential leap is.
- What could not be established, and what would settle it.
Grounding matters more as models improve
A capable model will produce a plausible answer about a library's current API, a specification revised last quarter, or a vendor's actual rate limits. Plausible is the problem: the failure mode is not obvious nonsense, it is a confident answer that was true eighteen months ago.
Fetching and citing live sources is what separates a research report from a well-written recollection. The citation is not decoration — it is the mechanism by which a reader can catch the model being out of date.
Make the next step obvious
Research pays off when it changes what happens next. A report that ends without a clear handoff usually ends its life as a link nobody opens twice.
The natural next moves are narrow: bring the report into Cowork so a team can decide against it, or use it to frame a Design Studio brief so the constraints it uncovered are present from the first sketch. Either way the evidence travels with the decision instead of being re-summarised from memory.
Key takeaways
- Frame research by the decision it serves, not the topic it covers.
- Keep observation, inference, and recommendation visibly distinct.
- State what you could not establish and what would settle it.
- Citations exist so a reader can catch a stale answer.