Inside Gemini Deep Research: Planning, Evidence, and the Five-Minute Agent

Agree on the investigation before it starts

How do milk and meat regulations differ between the US and Europe? The demonstration in The Inventors of Deep Research begins with that question—and a proposed research plan. Before spending several minutes browsing, Gemini Deep Research lets the user review what it intends to investigate.

In this February 2025 conversation, Gemini Deep Research is a research assistant that browses for about five minutes, produces a report, and answers follow-up questions. It targets multifaceted investigations that might otherwise consume a weekend and 50–60 browser tabs. Targeted search remains useful when the user knows exactly what they want.

A plan helps resolve ambiguity without requiring the user to understand the topic already. A request about batteries could concern recent innovations or a particular chemistry; a newcomer may not know how to narrow it. Showing a proposed breakdown gives them something concrete to respond to. In the food-regulation example, additives and labeling restrictions introduce possible facets while inviting the user to steer.

The plan is an editable scope agreement. Users can revise it conversationally. The team added an edit button after early testers failed to discover that capability, although it says most users still simply start the research. In the demonstration, an edit adds a seventh step covering US and EU labeling requirements. Even an unedited plan makes the report’s intended scope visible.

Let evidence determine the next search

The accepted plan becomes a contract for the investigation. The model identifies substeps it can explore in parallel, using two main capabilities: search and deeper browsing of individual webpages. The interface shows the sites being read in real time.

The crucial mechanism is iterative planning from tool outputs: what the model reads determines what it investigates next. In a hypothetical branch from the demonstration, finding a European Commission restriction on an additive would prompt it to check the corresponding US policy. That follow-up question emerges from the evidence rather than from a fixed list of searches.

The workflow develops in stages: 1. Explore the accepted plan, running independent substeps in parallel. 2. Pursue gaps, partial information, and inconsistencies through further searches and browsing. 3. When the model considers the research complete, analyze the material and outline a report. 4. Draft the report, then revise it through self-critique.

Exploration is typically breadth-first—covering the plan’s different topics before investigating selected details—but this is a model choice, not an enforced traversal policy. Partial or conflicting information helps determine where to go deeper. Website ranking and stopping remain qualitative model judgments here; the team gives no explicit ranking algorithm or measurable completion criterion.

The workflow used a specially post-trained Gemini 1.5 Pro, with additional training to produce useful plans and execute them consistently. The team supplies no reliability measurements. Reproducing that behavior through the Gemini API also remains unresolved: when an initial fine-tuning suggestion is challenged, the response points instead to fine-tuning Gemma models.

The report begins the next interaction

The demonstration report separates milk regulation from meat production, then attempts to explain the differences between regions. Its precautionary-EU versus reactive-US framing illustrates the product’s ambition to synthesize an explanation beyond a list of findings. That framing is generated report content, not a verified regulatory conclusion.

The report sits beside the conversation so users can read and ask questions together. The model is trained to distinguish three follow-up paths: - Answer from gathered evidence: surface a detail captured during browsing but omitted from the report. - Research further: investigate a question the existing material cannot answer, such as extending the comparison to Asia. - Revise the document: condense, remove, or add sections.

The model chooses the path from the query, so a follow-up need not trigger another five-minute run. It can answer quickly from retained material or return to planning and browsing. One participant describes repeatedly extending an initial report with additional investigations, making the interaction an ongoing research project.

Exporting to Google Docs preserves citations and saves the report for further work. This is separate from Gemini Extensions, which retrieves content from other services to inform answers. The conversation’s Spotify playback example belongs to the general Gemini assistant, not Deep Research.

Keep recent evidence in context

The system handles web content as both HTML and Markdown. Markdown conversion reduces markup noise, but the model must also work directly with HTML when that is the available representation, such as an embedded snippet.

At the time, Deep Research did not use vision. Rendering pages introduced latency, and one participant expected visual understanding to benefit a relatively small tail of requests. Another challenged that tradeoff: research already has a budget measured in minutes, and important information trapped in a JPEG is a concrete limitation of text-only browsing.

For follow-ups, the system first uses the model’s available context—the research material it can consult directly. Beyond that capacity, an in-house retrieval-augmented generation (RAG) system retrieves material to inform answers. The team stress-tested this arrangement by repeatedly extending investigations with new requests.

The preference for context reflects two engineering judgments. One participant argues that similarity retrieval based on cosine distance or dot products struggles when a query combines multiple attributes. The same participant reports that newer long-context models were better at extracting fine-grained information as context filled. These observations motivate the design; they are not a measured comparison of retrieval architectures.

A complementary heuristic is to keep recent research in context and retrieve older material as needed. Recent work is more likely to generate follow-ups requiring detailed comparisons. The example of moving material from ten tasks or turns earlier into retrieval is illustrative, not a fixed eviction threshold.

For users, the recommendation is to continue the same thread when the research belongs to one cohesive project. A niche detail discovered about one country can become a lead to check in another. That advice is grounded in tests of natural transitions; abrupt switches to unrelated topics had not been thoroughly tested.

Evaluate behaviors, then judge the report

Across post-training versions, the team automatically tracks planning time, proposed plan length in steps, and average iterative planning steps on a development set. Large distribution shifts signal changed behavior. Step counts are diagnostic, not quality scores: a change can reflect either improvement or regression.

Human reviewers assess comprehensiveness, completeness, and groundedness, or support in the source material. The many plausible outputs for a research query make automated rating difficult. To cover that variety, the team organizes its evaluation set around research behaviors rather than industry categories such as travel or shopping.

The behaviors span a spectrum: - Options exploration: discover many candidates, such as summer camps for children interested in soccer and tennis, and summarize each. - Focused investigation: study one topic in depth. - Intermediate comparisons: examine several options or topics at moderate depth. These are examples, not an exhaustive classification. Compound projects combine patterns: planning a wedding in Lisbon requires research into planners, venues, and catering.

Internal use uncovered unexpected projects, but most users were not pursuing long conversations despite the absence of a hard turn limit. An interviewer suggests that a polished document visually signals completion. The team agrees that the interface could better invite continued exploration—a proposed improvement rather than a shipped feature.

Research behavior also explains where the product fits. One participant prefers visual shopping interfaces for shoes, but sees Deep Research as useful for HVAC systems: understand specifications and voltage ratings, then find suitable installers. Summer camps, products, and scholarships can all involve the same underlying task—sifting through information to curate options—even though their domains differ.

What should another minute buy?

Visible effort can become a misleading proxy for value. An interviewer imagines an agent visiting 70 websites, 30 irrelevant, yet impressing users with the count. The team initially feared the opposite: users abandoning slow runs. It built an approximately 15-minute mode but shipped one taking about five minutes; one member had requested a ten-minute hard stop.

Users’ willingness to wait surprised the team. Its experience with Assistant and other Google products had generally linked lower latency to better satisfaction and retention, though no quantitative comparison is given. For research, extra time can fund broader exploration for completeness or deeper verification of uncertain findings.

The team had not found an optimal allocation between those activities. Ideally, the question and conversation would determine the effort: historical economic research may need more precision than finding birthday venues. A user control could expose the tradeoff, but one participant worries it would become a maximum-power button everyone selects. Inferring the right balance remains an open research problem.

Longer work needs opportunities for correction. An interviewer cites Devin as an example of displaying a plan during execution and accepting chat corrections while work continues. The suggested research interface would update the plan and let the scheduler select its next task from that revised list. For hypothetical hour-long investigations, a team member imagines the agent checking in with findings and obstacles before asking for direction.

The interviewer also criticizes hourly agent billing as an incentive to run slowly and predicts that enthusiasm for hours of autonomous work will eventually give way to complaints about latency. The concern is about incentives, not evidence that longer runs produce worse—or better—results.

A focused product, two kinds of reasoning

NotebookLM influenced the team’s product approach: choose a focused problem, make document upload and question answering work well, and hold a clear view of the user experience. The teams also shared practical lessons about Gemini 1.5 Pro and model pitfalls. They remained separate teams, with access described as bundled into the same existing paid plan.

Deep Research’s own interface bets connect three moments: a plan before work begins, visible sources during browsing, and a report beside the conversation afterward. A team participant sees similar interactions appearing in competing products as useful ideas being reproduced and extended across the industry.

The model discussion distinguishes reasoning within a model from iteration across an agent workflow. A thinking model spends computation reasoning before acting; a research agent also spends computation searching, reading, and deciding what to do next. The team sees promise in stronger analytical capabilities and critique of intermediate steps, but announces no model upgrade or benchmark results.

An interviewer asks whether internal reasoning could reduce verification work—or make the model rely more on memory and search less. Both remain hypotheses. The response emphasizes that grounding a claim in a source helps users trust even a correct answer. Recalling a number accurately does not remove the user’s need to inspect its supporting source.

Better reasoning also need not mean a larger store of facts. When a participant suggests thinking models know more, another challenges the claim. The response narrows it to stronger capabilities such as mathematics: using knowledge more effectively is distinct from possessing more factual knowledge.

Planning must generalize; execution must survive

Teaching generalizable iterative planning was a major modeling challenge. Training separate planning traces for every domain or research pattern would be impractical. The aim was to draw efficiently on existing model knowledge, specializing the workflow without losing capabilities acquired during pretraining. The team used data augmentation and repeated experiments to tune that balance, but does not disclose the techniques or quantitative results.

Execution required a platform that could preserve progress independently of the chat session. Users could leave the chat or close their computer while research continued, then receive a phone notification. The platform keeps state and determines which operations to retry so failures do not discard several minutes of work. At the time, mobile access was live on Android and rolling out on iOS.

Apache Airflow, Temporal, and AWS Step Functions appear as workflow-system reference points, not identified backend components. One participant considers static execution graphs less suited to adaptive research. The desired platform must accommodate the agent’s chosen actions while remaining stable across hundreds of model calls. Hour-long and multi-day jobs are prospective uses, not reported execution results.

From benchmark answers to testable discoveries

An interviewer argues that not publishing benchmarks hurt the product’s marketing. The team’s response centers on relevance: contrived questions may poorly represent real investigations, and success on Humanity’s Last Exam does not necessarily make a system a good researcher. The priority is solving users’ research needs.

Benchmarks still help assess progress and rally engineers. One participant recalls MLPerf competition motivating improvements to an accelerator stack over a few days, without giving measured gains. Comparing scores for generated text brings another difficulty: labs may judge answer correctness differently while presenting numbers side by side.

Moving from synthesis to discovery requires more than a stronger answer generator. A participant argues that reasoning models can draw second-order insights, but hypothesis generation must connect to testing and feedback. An agent needs to propose an idea, test it in an environment, receive a useful signal, and iterate.

That loop depends on the domain’s verification tools. Coding and mathematics offer ways to test hypotheses. The respondent presents chemistry as harder because it lacks the kind of synthetic experimental environment with accurate verification signals they envision, while computer-use research is developing useful environments. This is a view of what makes automated discovery feasible, not a demonstrated boundary across scientific fields.

The next research agent needs the user’s context

Personalization is a closing priority. A high-school student and a PhD researcher need different reports. Prompting can specify an audience, but the desired agent would also understand what the user already knows and how the current investigation fits into their learning.

Deep Research was still text-in, text-out. Proposed extensions include multimodal inputs and interactive reports with charts, maps, and images. Presentation would adapt to the task: an academic paper and a child’s learning program need different structures. These are future directions, not demonstrated capabilities.

The research material must expand too. One participant expects the open web to reach limits in specialized industries, where useful evidence lives in users’ own documents, private collections, and subscriptions. The desired product would let users bring those sources into an investigation.

The advice to builders is to make one experience work well before generalizing it into a platform. Reusable tools can supply foundational layers, but one participant considers interchangeable, plug-and-play agent components premature. That judgment is provisional: the tooling problem described today could change within months.

Looking ahead to a conference appearance, the interviewer asks for implementation detail alongside future direction, especially for developers adapting research agents to particular industries. The final technical question concerns authenticated access: how can an agent research material the user is entitled to read? The interviewer sees protocol coordination as a central obstacle; no solution is presented.

A team participant wants to learn how companies beyond Google’s consumer-focused setting approach business research. The interviewer anticipates a concrete enterprise request: run deep research over our company’s documents. The next useful investigation may depend as much on access to that evidence as on the agent’s ability to plan.