The Short Answer
A deep research agent answers a complex question by running many retrievals, not one: it decomposes the question into sub-questions, searches your corpus (and optionally the web) for each, reads and extracts facts with their sources, follows up on what it finds, checks claims against each other, and synthesizes a cited brief. The difference from ordinary RAG is the loop — retrieval informs the next retrieval — and the difference from consumer deep-research products is the corpus: your documents, videos, images, and recordings behind your own API, not the public web.
How is deep research different from RAG?
Single-shot RAG is a pipeline: embed the question, retrieve top-k passages, stuff them into a prompt, answer. It works when the answer lives in one place. Research questions rarely cooperate — "why did churn spike in Q2?" has evidence scattered across support tickets, call recordings, product analytics exports, and a pricing-change memo, and no single query surfaces all of it.
Deep research replaces the pipeline with a loop under an agent's control:
| Stage | What happens | What can go wrong |
| Plan | Decompose the question into sub-questions with distinct search intents | Decomposition mirrors the question's phrasing instead of the corpus's vocabulary |
| Gather | Run retrievals per sub-question — rewritten and expanded, across modalities | One retrieval angle misses evidence other angles would find |
| Read & extract | Pull facts out of retrieved items WITH provenance (doc id, page, timestamp) | Extraction without positions cannot be audited later |
| Follow up | New facts spawn new sub-questions; repeat Gather | Runaway loops burn budget without adding evidence |
| Verify | Cross-check claims across independent sources; flag contradictions | Skipping this ships confident wrong answers |
| Synthesize | Write the brief, every claim linked to its evidence | Citation drift — prose that outruns what sources say |
Why doesn't public-web deep research transfer to private data?
Consumer deep-research products (ChatGPT, Gemini, Claude, Perplexity) are built around browsing: fetch a page, read HTML, follow links. Three assumptions break on a private corpus. First, retrieval replaces browsing — there are no links to follow; the agent's only navigation is the quality of your search API, so retrieval quality bounds research quality. Second, the evidence is multimodal — the decisive fact is on slide 40 of a deck, at minute 32 of a call recording, or inside a chart screenshot, so text-only indexing silently amputates the corpus (see multimodal RAG pipeline architecture). Third, provenance is a requirement, not a nicety — an internal research brief that cannot point at its sources with page numbers and timestamps will not survive review.
What are the stopping criteria?
The naive loop ("keep searching until done") does not converge. Production agents stop on explicit conditions, in priority order:
1. Evidence saturation — K consecutive retrieval rounds return nothing new (dedup against everything already read, not just the last round). 2. Sub-question exhaustion — every planned and spawned sub-question has been answered or marked unanswerable. 3. Budget ceiling — a hard cap on retrieval calls, tokens, or dollars. The cap is a correctness feature: it forces the agent to prioritize breadth-first evidence over depth-first rabbit holes. 4. Contradiction deadlock — two sources disagree and no third source arbitrates; the right output is "sources conflict," cited, not a coin flip.
The same discipline applies to relevance: research agents should log which retrieved items actually grounded claims, because that signal improves the retriever itself over time.
How do you build one on Mixpeek?
Mixpeek's retriever stage catalog maps onto the loop directly — each stage is a typed, composable step, so the research flow is a retriever definition rather than bespoke glue code:
feature_search (multimodal search over your indexed corpus) plus query_expand for recall; external_web_search and web_scrape when public sources belong in scope.attribute_filter for time ranges and entities, llm_filter for semantic relevance judgments.llm_enrich for fact extraction, taxonomy_enrich to tag evidence against your taxonomy, document_enrich to attach related documents.cross_compare across collections, api_call out to external checkers.summarize reduces the evidence set to a brief that keeps citations.Follow-up loops compose the same way:
document_enrich can invoke a sub-retriever, mapping outputs of one stage into the inputs of the next —{
"stage_name": "retriever",
"stage_type": "enrich",
"config": {
"stage_id": "document_enrich",
"parameters": {
"retriever_id": "ret_internal_logs",
"input_mappings": {
"query_text": "{{INPUT.primary_question}}",
"time_range": "{{STAGE.filter.time_range}}"
},
"merge_strategy": "append"
}
}
}What should you evaluate before picking a framework?
Ask four questions of any deep-research stack — a multimodal RAG framework, a hand-rolled agent loop, or a managed platform. Can the retrieval layer see every modality your evidence lives in? Does every extracted fact carry provenance a reviewer can click? Are stopping criteria and budgets enforced by the system rather than promised by the prompt? And can retrieval quality improve from usage? Whichever way you assemble it, the retrieval substrate decides the ceiling: a research agent is exactly as good as what it can find. Rate-card economics for the indexing side are on pricing; the loop itself you can prototype free in Studio.