Building Gemini Deep Research: An Agentic Research Assistant with Custom-Tuned Models

google_deepmind · Tech · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Consumer research agents

Google DeepMind built Gemini Deep Research to automate multi-faceted web research that normally forces users to open many tabs, decide what to read, compare sources, and synthesize a cited report by hand. The system needed to run for minutes, make its plan visible and steerable, browse fragmented web content iteratively, preserve user trust through citations and progress visibility, and evaluate long-form outputs whose quality cannot be captured by a single benchmark score.

Constraints:

• The target tasks are broad research journeys where users want to go from zero to 50 quickly rather than simple factoid searches.
• The agent may spend five to ten minutes browsing, so users need a way to inspect or steer the plan before compute is spent.
• The web is fragmented and noisy, and later search decisions often depend on partial or inconsistent findings from earlier searches.
• Long-running jobs need asynchronous state, retry, notification, and cross-device continuation rather than synchronous chat assumptions.
• The model must balance internal knowledge and reasoning against source-grounded browsing so reports remain trustworthy and cited.

Architecture

Gemini Deep Research wraps a custom post-trained Gemini model in a multi-stage research-agent product. The UI first asks the model to draft an editable research plan, then the accepted plan becomes the contract for execution. The agent parallelizes obvious substeps, uses search and page-browsing tools, reasons over previous findings to choose later searches, and enters an analysis/drafting stage to reconcile sources and produce a cited report. An internal async execution platform keeps multi-minute jobs durable across browser/device changes and failures, while long context holds fresh research material for follow-up questions with retrieval available as fallback.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  user[User] --> gemini-deep-research-ui[Gemini Deep Research UI]
  gemini-deep-research-ui --> editable-research-plan[Editable research plan]
  gemini-deep-research-ui --> report-artifact-workspace[Report artifact workspace]
  editable-research-plan --> gemini-research-agent[Gemini research agent]
  gemini-research-agent --> search-tool[Search tool]
  gemini-research-agent --> webpage-browsing-tool[Webpage browsing tool]
  gemini-research-agent --> source-context-store[Source context store]
  gemini-research-agent --> analysis-and-synthesis-stage[Analysis and synthesis stage]
  gemini-research-agent --> async-execution-platform[Async execution platform]
  gemini-research-agent --> evaluation-harness[Evaluation harness]
  search-tool --> source-context-store
  webpage-browsing-tool --> source-context-store
  source-context-store --> analysis-and-synthesis-stage
  analysis-and-synthesis-stage --> report-artifact-workspace
  report-artifact-workspace --> user

Components

Data flow

A user submits a research query. Gemini Deep Research generates a proposed plan, exposes it for editing, and starts only after the user accepts or steers it. The agent identifies parallelizable substeps, searches the web, opens pages of interest, reads previous outputs, and issues follow-up searches when earlier findings expose missing or conflicting information. It then moves into analysis, drafts a report, self-critiques the draft, presents a cited artifact beside the chat, and supports follow-up questions or export while the async platform preserves state and retries across the job.

Why this architecture

The plan-first interface mitigates the risk of spending several minutes on the wrong research path. Search and page-browsing are separated so the agent can first explore breadth, then double-click when prior findings reveal gaps or inconsistencies. Long context supports complex follow-up over freshly browsed material, while async orchestration is necessary because a five-to-ten-minute agent job can outlive the browser session and fail mid-run. Custom post-training was used because ordinary Gemini behavior was not reliable enough for repeatable planning, browsing, and synthesis.

Models used: Gemini 1.5 Pro · Gemini 2.0 Flash · Gemini · Gemma

Scale

• Deep Research browses for about five minutes before producing a research report.
  “it takes your query, browses the web for about five minutes, and then outputs a research report for you to review and ask follow-up questions”article, stated
• The product targets research journeys where users might otherwise open 50 to 60 tabs.
  “you spend like a weekend, you know, just opening like 50, 60 tabs and many times I just give up”article, stated
• The team tested a 15-minute hardcore mode, shipped a five-minute version, and originally wanted a 10-minute hard stop.
  “We had, like, a hardcore mode that takes, like, 15 minutes. And then what we actually shipped is a thing that takes five minutes.”article, stated

  “there has to be a hard stop, by the way. It can never take more than 10 minutes.”article, stated
• The system uses Gemini's one-to-two-million-token context window before falling back to retrieval when needed.
  “you have 1 million to 2 million token context. Has it ever exceeded 2 million? And what do you do there?”article, stated

  “we have retrieval mechanisms if required. So we natively try to use the context as much as it's available”article, stated
• The async product reached Android phones and was rolling out to iOS during the interview.
  “we wrapped on all Android phones and then iOS is this week. But yeah, what's, what's neat though, is like, you can close your computer, get a notification on your phone.”article, stated
• The team anticipated future hour-long or multi-day jobs and hundreds of LLM calls.
  “you can imagine once you start doing hour or multi-day jobs. Yeah. You have to model what the agent wants to do.”article, stated

  “Like hundreds of LLM calls. Yeah. It's boring, but like, you know, this is the thing that makes it run autonomously”article, stated

Alternatives considered (roads not taken)

Ask direct clarification questions before starting research.

Rejected because: The team believed users often do not know what facets to ask about, so showing a proposed plan teaches the topic and still gives a steering surface.

Use the public/base Gemini model behavior without specialized adaptation.

Rejected because: The team said the product uses a post-trained version of Gemini 1.5 Pro, with training needed to make planning and browsing reliable.

Rely on model memory or reasoning instead of verifying from sources.

Rejected because: The team viewed unsourced model-memory answers as untrustworthy for research, even when the model might know the answer.

Use retrieval for all accumulated research material.

Rejected because: The team prefers full context for recent research because retrieval can struggle when follow-up questions combine several attributes.

Use static workflow engines as-is for research orchestration.

Rejected because: The team needed flexible orchestration for dynamic agent decisions, while Step Functions-style workflows were described as static graphs.

Patterns

human-in-the-loop-gate (agent-ux)

Gemini Deep Research exposes an editable research plan before execution so the user can inspect or steer a multi-minute agent run.

tool-use-orchestration (agent-architecture)

The research agent coordinates search and webpage-browsing tools, parallelizes independent plan steps, and uses prior outputs to decide later searches.

prompt-chaining (agent-architecture)

The product breaks research into plan generation, iterative search/browse, analysis, drafting, self-critique, and final report presentation rather than one answer-generation step.

fine-tuning-adaptation (model-development)

The team used custom post-training on Gemini 1.5 Pro so the model would reliably produce research plans, browse, iterate, and synthesize with high reliability.

durable-execution (infrastructure)

Deep Research required a custom asynchronous platform that keeps state, retries failed steps, and lets users leave while multi-minute agent work continues.

rag-retrieval (context-management)

The system keeps recent browsed material in Gemini's long context, then falls back to retrieval for older or overflowed research material.

eval-driven-development (quality)

The team evaluates Deep Research with automatic behavioral metrics, human evaluation, product-defined quality criteria, and an ontology of research journey types.

observability-tracing (agent-ux)

The product shows which websites the agent is reading in real time, making long-running agent actions visible to users.

Tradeoffs

Expose an editable plan instead of running immediately.

Chose plan-first research execution over immediate background browsing.

Rationale: A plan lets users steer before a multi-minute run, and also teaches users about facets they may not have known to request.

Spend inference time on exploration and verification.

Chose multi-minute research agent work over low-latency answer generation.

Rationale: The team found that, for research tasks, users often perceive visible time and source coverage as value, while engineers still need to balance exploration and verification.

Use custom post-training for Deep Research behavior.

Chose specialized Gemini 1.5 Pro adaptation over off-the-shelf public Gemini behavior.

Rationale: Reliable planning, browsing, and synthesis needed behavior shaping beyond the base model, but the team also had to avoid overfitting away pretrained knowledge.

Hold recent research in long context before falling back to RAG.

Chose long-context-first memory over RAG-only retrieval over all browsed pages.

Rationale: Complex follow-ups over recent work benefit from having the full research material in context, while older tasks can be retrieved later.

Use HTML-to-markdown conversion without abandoning raw HTML paths.

Chose hybrid page representation over single canonical page representation.

Rationale: Markdown strips noise for normal pages, but raw HTML or snippets are still useful when the source format requires them or newer models can use them directly.

Avoid benchmark-first optimization.

Chose product-centered evaluation over optimizing primarily for academic benchmark scores.

Rationale: The team values benchmarks, but argued they do not directly prove that a product is a good deep researcher for real user tasks.

Gotchas (what bit them)

Users may ignore a steering mechanism even when it exists.

Root cause: Most users hit start without editing, especially when the plan feels like an 'I'm Feeling Lucky' default.

Resolution: The team added an explicit edit button while still treating the plan as a transparency mechanism for non-editing users.

Iterative planning can become unscalable if trained per domain.

Root cause: The agent has to adapt search strategy from prior findings across many research behavior types, and hand-teaching traces for each ontology type would be nightmarish.

Resolution: The team used data-efficient post-training and augmentation while carefully avoiding overfitting away useful pretrained capabilities.

Thinking models can compete with source-grounded browsing.

Root cause: A more capable reasoning model may answer from internal knowledge rather than spending tool time to verify and cite facts.

Resolution: The team treats balancing internal reasoning with external grounding as a key design problem for research agents.

Web pages arrive in noisy and mixed representations.

Root cause: Useful web content may be embedded in HTML snippets, while ordinary pages contain noise from JavaScript, CSS, and markup.

Resolution: The system uses both markdown conversion and raw HTML handling depending on the access path and model generation.

Long-form research evaluation has high output entropy.

Root cause: There are many valid report structures, source choices, and synthesis styles, so automatic graders and benchmarks do not map cleanly to product quality.

Resolution: The team combines behavioral distributions, human review, product criteria, and use-case ontology coverage.

Locking the chat during long-running work limits mid-execution steering.

Root cause: Initial Deep Research-style systems treat the plan as static while the agent works, unlike agents that accept user input during execution.

Resolution: The team acknowledged that longer tasks should let users engage more and update direction during the run.

Evaluation

Gemini Deep Research is evaluated with product-centered human review plus automatic behavioral metrics over a development set. The team monitors planning time, number of iterative steps, research-plan length, and other behavioral distributions, then uses human evaluation for comprehensiveness, completeness, groundedness, accuracy, and depth. Instead of organizing only by vertical, the team built a use-case ontology that spans broad-shallow exploration, deep-narrow investigation, comparison, and compound planning tasks.

Metrics: planning time · number of iterative steps · research plan length · number of research plan steps · distribution shifts across a development set · comprehensiveness · completeness · groundedness · accuracy · coverage across a research-use-case ontology

Outcomes

• Gemini Deep Research launched as a consumer-facing agent that browses for minutes and returns cited research reports.
• The product makes the research plan visible and editable before execution.
• The agent can parallelize plan substeps and iteratively search or browse based on earlier findings.
• Users can see websites being read in real time and export cited reports to Google Docs.
• The async platform lets users close the computer and receive phone notifications when research completes.
• The team's evaluation shifted from vertical categories to an ontology of research behaviors.

The case reports 5-6 minute research jobs, a shipped 5-minute version, a 10-minute hard cap, a tested 15-minute hardcore mode, user workflows involving 50-60 tabs, one-to-two-million-token context, Android and iOS surfaces, and future designs for hour or multi-day jobs with hundreds of LLM calls.