Latest / Embodied AI 101 / Deep Research Agents: Survey and Roadmap for Autonomous AI Research

Transcript

Deep Research Agents: Survey and Roadmap for Autonomous AI Research · Embodied AI 101

• Deep Research Agents: Survey and Roadmap for Autonomous AI Research. The last year has seen a wave of bold claims: AI assistants that can think for us, solve problems end-to-end, even autonomously run business processes. Chief among these is the idea of an autonomous research agent – an AI that can independently carry out multi-step information-gathering and analysis, much like a junior scientist. Large language models (LLMs) have brought this into reach, and companies like Google, OpenAI, Microsoft and others have launched so-called “deep research” features across their products. In December 2024 Google rolled out Gemini Deep Research, and soon after OpenAI, Perplexity, xAI (Grok) and others had similar offerings. By mid-2025 these tools were a standard part of the paid tiers of LLM-based chatbots (indeed, deep research is now a selling point of every major AI lab’s stack). What exactly is a deep research agent? Think of tasks that go far beyond one-shot question-answering: scanning the literature on a technical topic, browsing news and blogs on some current issue, running experiments or data analyses, and finally writing a coherent report with sources and facts. In the survey “Deep Research Agents: A Systematic Examination and Roadmap”, Huang et al. offer a clear definition: a deep research (DR) agent is an autonomous, LLM-powered system that combines dynamic reasoning, adaptive long-horizon planning, multi-hop information retrieval, iterative tool use, and structured report generation to tackle open-ended informational research tasks. In other words, these agents plan out a series of search-and-analyze steps, use tools or APIs as needed, and synthesize what they find into a polished output. This survey pulls together the scattered pieces of this emerging field. It breaks down the building blocks of DR agents (search methods, tool frameworks, memory systems, learning strategies), proposes a taxonomy of workflows and architectures, and critiques how we’re currently testing research AIs. Perhaps most importantly, it lays out hard challenges and promising directions. In the paragraphs that follow, we’ll walk through the key ideas from this paper. We’ll explain how DR agents retrieve information, incorporate tools, plan their workflows, and how they’re evaluated. Along the way we’ll note related work and current practice. By the end, you should have a thorough technical picture of what Higlight’s “Deep Research Agents” are and how to think about building or improving one. Key Capabilities of Research Agents. The core flavors of a deep research agent can be seen in its pipeline. When a human researcher tackles a question, they might first refine what they’re looking for, then hit search engines or scientific databases, skim results, experiment with code or math tools if needed, iterate on queries based on what they learn, and finally write up conclusions citing evidence. DR agents aim to automate this loop. Concretely, Huang et al. note that DR agents rely on dynamic reasoning and iterative tool use. A single prompt won’t cut it; the agent needs to break the high-level query into sub-tasks and execute them in sequence or parallel, choosing what to do next based on intermediate results. They need long-horizon planning, meaning they should plan multi-step strategies (e.g. “first find key papers, then enumerate hypotheses, then run a small experiment”) rather than just answering one question. And crucially, they must retrieve from or interact with external knowledge: this includes web search, APIs to databases (ArXiv, Wikipedia, news venues, etc.), and perhaps even multimodal sources like images or PDFs. The paper encapsulates these abilities as “an autonomous, LLM-powered system that combines dynamic reasoning, adaptive long-horizon planning, multi-hop retrieval, iterative tool use, and the generation of structured analytical reports”. We can therefore break down the agent’s capabilities into these parts:. Information Retrieval & Browsing: The agent must gather data from outside its parameters. Two broad approaches exist: using search or other APIs to get results as text, or simulating browser-based exploration. That is, it might query Google (or DuckDuckGo, Bing, or scientific indices like Semantic Scholar) via their public APIs to get a list of links and snippets, or it might drive a headless web browser to click through links, scroll pages, and extract information as a human would. Huang et al. explicitly contrast these “API-based retrieval methods” with “browser-based exploration”. Either way, the agent needs to iteratively refine searches (multi-hop retrieval) to handle complex queries. For example, to research a topic it might first search a broad query, pick promising results, then formulate narrower follow-up queries based on what it found. The survey critiques current practice, noting agents typically still lack full access to the open web and instead work on limited corpora or cached data. In practice, designers have built connectors (like the Tavily search API used in LangChain examples [69]) so that an LLM can fire off web queries or database queries as needed. After getting search results, most agents then “filter URLs and fetch page content” for deeper reading, since raw search results only give you pointers. Modular Tooling & Execution: DR agents are often built on more than just plain LLM calls. They use tool-use frameworks that let the model call out to external tools or code. Typical tools include a Python REPL (so the agent can run code to crunch data, make plots, etc.), PDF readers for parsing scientific papers, and even specialized APIs (e.g. a WolframAlpha API for math). The survey examines “code execution, multimodal input processing, and the integration of Model Context Protocols (MCPs)” as core tool-framework components. For example, a DR agent might find a data set online and want to analyze it – it would call a Python tool, get results (a chart or statistics), and then use that in its reasoning. “Multimodal input processing” refers to the ability to handle things like images, diagrams, or PDFs by running vision or document-parser tools. Finally, they discuss Model Context Protocols (MCPs) as an emerging standard for organizing tools. In essence, MCP defines how an LLM discovers and invokes tools in a uniform way. For instance, Google’s work on MCP aims to let any GPT model seamlessly use thousands of available APIs without needing custom prompts for each. The survey notes that adopting MCP (and related agent-to-agent protocols) will make DR agents far more extensible, since new tools can join the ecosystem. Memory and Continual Learning: Unlike a one-shot chat, a research agent should remember what it has done so far in the session and ideally carry knowledge across tasks. This is often done with external memory stores (i.e. non-parametric memory). Huang et al. explicitly list memory as a core component, and they highlight “non-parametric continual learning” in particular. That means using retrieval (vectors or databases) to accumulate knowledge, rather than continually re-training the model. In practice, agents frequently use Retrieval-Augmented Generation (RAG) techniques: building up a vector store of retrieved documents or notes and allowing the LLM to query that store on each step. This lets the agent recall facts from earlier in the conversation or from previous investigations, beyond the fixed context window of the LLM. It also enables updating with new information over time without re-tuning the model weights. A fully-fledged DR system might long-term archive sources it has read, so next time it knows what’s already been covered. This non-parametric memory thus helps the agent handle “complex, multi-turn” research threads that exceed one model context. Learning and Adaptation: Finally, there’s how we train or fine-tune a DR agent. Huang et al. survey options like supervised fine-tuning (SFT) on research-task data and reinforcement learning (RL) to optimize for final report quality. The emphasis on “non-parametric continual learning” again suggests that much of the agent’s improvement comes from adding external data or feedback loops, rather than just static training. Some recent work (e.g. AllenAI’s Tülu project, or Meta’s research on RL fine-tuned agents) indeed builds large datasets of search-and-answer trajectories or uses human feedback to shape agents. These learning methods are not the survey’s main focus, but it does note them as tools in the toolbox. Pulling these together, a DR agent is essentially a planner + retriever + executor + writer. It plans out subgoals, fetches and organizes information, uses tools to analyze, and then drafts a structured answer or report. The cited survey phrases this as generating “structured analytical reports” on the end task. For example, you could ask a DR agent to produce a market analysis for a new robotics product. It might open Google and tech blogs (retrieval), skim them and extract salient points (processing), maybe run a quick spreadsheet calculation (tool use), iterate its queries if something is unclear, and finally write up a report with headings and bullet points. All of those steps would ideally be done without human intervention, aside from supplying the initial prompt or feedback. Workflows and Architectures: Static vs. Dynamic, Single vs. Multi-Agent. Not all DR agents follow the same design pattern. A key contribution of the survey is a taxonomy of agent workflows and compositions, separating approaches along two axes: static vs. dynamic workflows and single-agent vs. multi-agent architectures. It’s worth unpacking these terms, which have emerged organically from how people build such systems. Static vs. Dynamic Workflows: A static workflow is essentially a fixed, human-designed pipeline that the agent executes step by step. Think of it as a flowchart drawn by engineers: “Step 1: parse the question; Step 2: search news; Step 3: summarize results; Step 4: answer”. Each stage and sub-stage (including which tools to call at that stage) is pre-coded. The agent then runs through these stages, possibly filling in details but not changing the sequence on the fly. This is easier to implement and reason about—each module has a clear role, and you can harden each part with error checks. The downside is rigidity. As one summary puts it, static pipelines are “clear in structure and easy to implement”, but they generalize poorly to new tasks because the steps are fixed. If you move from a medical research task to a computer-vision task, you often have to redesign parts of the pipeline. Static workflows are like following a recipe with no room for improvisation. By contrast, a dynamic workflow lets the LLM agent itself break apart and adapt the workflow as it goes. Rather than following a pre-packaged script, the model decides “what next?” at each turn. It might choose to loop back to search more, branch into a code experiment, or skip a step entirely, all based on its internal reasoning. In effect, the model is both planner and executor in one. The survey notes that dynamic flows “allow the agent to adjust future steps based on feedback and context, completing the entire loop of planning, execution, reflection, and adjustment autonomously”. The benefit is flexibility: the agent can tailor its approach to each unique query, which is powerful for complex or novel tasks. For instance, if midway through the search it finds a surprising fact, it might pivot to a new line of inquiry. The cost, however, is instability. A fully self-planned pipeline places huge demands on the LLM’s reasoning; without careful guidance or fallbacks, it can easily go off-track. As one analysis warns, dynamic workflows are “strong on flexibility and generalization… but require high model capabilities and can be unstable”. In practice, teams often use a hybrid strategy, combining static and dynamic elements. For example, a base pipeline might be fixed, but the agent can inject additional dynamic searches or loops as needed. The survey’s taxonomy highlights this spectrum and urges that good DR systems will likely incorporate both planning styles to balance structure and adaptability. Single-Agent vs. Multi-Agent Architectures: A related dimension is how many “brains” are involved in the workflow. In a single-agent (monolithic) design, one LLM handles everything. It acts as planner, worker, and reflecting critic in one loop. After the user’s prompt, the model internally decides every subsequent query, tool call, or reasoning step, running each to completion before moving on. The advantage here is simplicity: having one agent means all context is naturally unified in that model’s state or memory. Earlier chain-of-thought frameworks (e.g. the ReAct protocol) essentially use this style: the single LLM repeatedly reasons, then acts by calling a tool, then reasons again, all in one conversation chain. According to the survey, single-agent DR “relies on the model’s own strong reasoning and long context window” and proceeds on its chosen plan. Pros include a complete memory of what happened (no hidden state split across sub-agents) and the ability to train the whole process end-to-end (e.g. via reinforcement learning). Indeed, recent research agents like Meta’s ReSearch or OpenAI’s own WebPilot work this way. The cons are significant: you need a very capable LLM with huge context and excellent tool-calling stability. You also lose modularity—improving one aspect (say, search strategy) means retraining the whole agent, which can be difficult. In a multi-agent framework, the workload is divided among specialized sub-agents under some coordination. Typically, one “manager” or “planner” agent takes the user’s goal, decomposes it, and assigns pieces to other expert agents (search agents, code agents, summary agents, etc.). Those sub-agents run in parallel or sequence, then feed their results back to the manager. A blog-style explanation describes it like a human team: “a planner agent understands and splits the task, then multiple subtask agents (like code, search, analysis) take over execution, and finally a result agent delivers the output”. For example, one sub-agent could be dedicated to web search and information extraction, another to running code or doing math, another to writing the report. The multi-agent approach excels at scalability: if you have many resources, you can do several branches of the problem at once, and you can swap in new specialty agents for new tools. In handling very complex tasks, this can yield richer solutions because the agents can parallelize the work or use different strategies. However, coordination is harder. These sub-agents don’t automatically share memory, so you must design channels for passing information. As the blog analysis warns, you need careful “context/memory management” to avoid agents working at cross purposes. It also complicates end-to-end training; you often have to tune or supervise each agent separately. Nonetheless, many tool-based platforms are moving this way. For instance, LangChain’s “deep research” example actually uses parallel sub-agents under the hood, and some research frameworks (OpenResearch/Manus, Deerflow, etc.) explicitly adopt this planner–workers hierarchy to enable greater flexibility. In summary, Huang et al.’s survey organizes DR systems along these lines: static pipelines vs. dynamic autonomy, and solo agents vs. agent teams. In practice one might mix them (e.g. a mostly static pipeline with a dynamic planning agent at the top, or a dynamic system orchestrating fixed sub-modules). The key takeaway is that researchers are recognizing compositionality in design: different tasks and constraints (performance, stability, parallelism) favor different architectures. Our own projects should consider: Do we want full end-to-end flexibility (single dynamic agent) or defenseworthiness and inspectability (static pipeline)? How many agents can we run in parallel, and how will they share what they find? The survey’s taxonomy helps frame these choices. Information Gathering: API vs. Browser and Beyond. Drilling into the retrieval component, let’s look at how DR agents fetch knowledge. Broadly, there’s a spectrum from high-level APIs to raw browsing. On one end, an agent might simply query search provider APIs or databases: for instance, it could call Google’s Custom Search API, an ArXiv API, or a news API like NewsAPI or the New York Times developer API. The benefit is structured results – you immediately get JSON with titles, descriptions, URLs. Huang et al. point out this method “directly obtains structured results (URLs, snippets, etc.)” which are easy for the agent to parse. In many frameworks, the agent uses a web-search API to get a batch of candidate links, then programmatically filters them by relevance. After filtering, the agent issues follow-up requests to fetch the full contents of chosen URLs (via those APIs or a simple HTTP GET). The cost is that APIs often charge per query, and they only expose a subset of the web. Also, semantics of queries matter heavily – a good DR agent must learn to rewrite or refine search terms. Some systems solve this by generating multiple subqueries: for example, a fine-tuned module might take an initial question and produce several refined keyword queries to maximize coverage. On the other end, browser-based exploration tries to mimic human surfing. Here the agent literally drives a browser (often headless) to open pages, scroll through content, click on links, and extract text. This is slower but can reach anything a normal user could. It also allows richer interaction (e.g. logging into gated sites, navigating graphical interfaces) that an API can’t do. Some agents use libraries like Playwright or Selenium to script these web trajectories (Microsoft’s recent “WebGPT” style research falls into this camp). Huang et al. contrast these two: in API mode, the agent is limited to what the endpoint delivers; in browser mode, it has free rein but at higher complexity. Currently, many DR agent demos (including LangChain examples) stick to APIs for speed and robustness, while leaving true browsing for later. A nice middle-ground is targeted data scrapers or specialized connectors. For example, if the agent knows the user is interested in academic research, it might query Semantic Scholar or Scopus. There are also plugins like the “Academic Search” or “Database Browse” tools that some agent frameworks support. Essentially, a DR agent should have a toolkit of retrievers: generic web search, scholarly search, database queries, and perhaps even proprietary sources if it’s deployed behind a company firewall. Part of the survey’s roadmap is encouraging an ever-broader arsenal of data sources. They specifically call out the need for “broader information access via MCP/A2A ecosystems”, which means enabling agents to plug into many types of data services in a seamless way. As we build our own systems, we should keep an eye on new APIs (like OpenWebText endpoints, Twitter or Reddit APIs, etc.) and standards (like the emerging Agent2Agent protocols) to enrich where the agent can dig. Tools and Integrations: Code, Multimodality, and Protocols. Information retrieval is only half the story; the other half is what the agent does with that information. Modern DR agents depend heavily on tool use to analyze and synthesize data. A simple language model can scan text, but often we want it to compute or transform information in ways that exceed pure text reasoning. Code Execution: A very common tool in these agents is a live coding environment. For example, the agent might have access to a Python REPL where it can run arbitrary code it generates. This allows it to do things like fetch a CSV file and perform data analysis, call statistical libraries, generate plots, or even train a small machine learning model on the fly. The survey notes that many frameworks include code execution modules as part of the tool stack. This is critical for scientific research tasks: imagine asking about an unusual dataset’s properties – the agent may actually download the data and run a describe on it. Architectures like DeepMind’s AlphaCode or systems like Mesa Commander take this further, but even a modest Jupyter-like interface can greatly amplify an agent’s power. Multimodal Inputs: Real-world research often isn’t just text. It might involve diagrams, images, audio samples, or complex table data. DR agents therefore are starting to incorporate multimodal processing. The survey explicitly calls out “multimodal input processing”. In practice, this could mean the agent can use an image recognition API (say, OCR on a PDF figure, or a vision model on a photograph) and then reason over the result. Some demo agents will grab a chart image from a report, run it through a vision model to extract numbers, and comment on the trends. Others might use vector search on embeddings of images to find similar figures. This is still an emerging area (most prototypes remain text-focused), but it’s on the roadmap. Model Context Protocols (MCPs) and Ecosystems: As we touched on, MCP (Model Context Protocol) is a future-looking concept for tool integration. The key idea is to have a machine-readable table of available tools and endpoints. An MPC-compliant system lets the LLM discover and call tools by name/description. For DR agents, this means one could plug in new analytical tools, data sources, or plugins without rewriting the prompting logic. For example, Google’s Gemini Deep Research leverages a protocol like this to integrate Gmail, Drive, calendar, etc. The survey highlights MCPs as crucial for extensibility. In practical terms, when building an agent we should design our tools with clear interfaces (input/output schemas) and consider using or developing an MCP-like registry. This way, if later we add a new “scholar search” or a “database query” tool, the agent can flexibly use it. Workflow-Oriented Frameworks: Beyond individual tools, there are higher-level platforms that orchestrate the whole pipeline. LangChain’s DeepAgents (which we cited in the example) is one such open-source framework: it provides a skeleton where you define steps as subagents or “skills” and the system manages passing outputs along. Others like Microsoft’s AutoGen or AgentVerse do multi-agent orchestration. The survey notes that many current pipelines use off-the-shelf frameworks, and there are active efforts (like the “DeepAgents” library from NVIDIA’s R&E team) to make research-agent building more systematic. When designing a new agent, it’s worth evaluating these frameworks for managing state, tools, and asynchronous execution. The survey’s emphasis on multi-agent ecosystems suggests that the field is moving toward community-driven “agent marketplaces” of capabilities. Architectures in Practice: Examples from Industry and Open Source. It helps to ground this in some concrete systems. Huang et al. explicitly survey existing products and codebases. For instance, they call out Google’s Gemini Deep Research, OpenAI’s chat-driven research mode (with browsing), Perplexity’s research assistant, xAI’s Grok, and others. These are mostly proprietary, closed-source demos, but they illustrate the hype. All of them provide an LLM with a range of data sources (web, internal docs, user files) and tool support. They are usually still “single-agent” under the hood (a single LLM orchestrating everything), though Google in particular is promoting MCP to bring external code executors and databases into the mix. On the open-source side, LangChain has been a notable enabler. Its DeepAgents examples repository includes a “deep_research” agent pattern: “Multi-step web research agent using Tavily for URL discovery, parallel sub-agents, and strategic reflection”. This example uses the Tavily API (a wrapper over Google/Bing search) and splits the task among sub-agents, exactly illustrating the multi-agent design discussed above. The LangChain docs walk through setting up such an agent, showing how the planning, iteration, and summarization steps can be encoded as separate modules. Another example is the Agentify/Marvel line of projects (e.g., Auto-GPT and its research-focused variants), where a single LLM with an “autonomous” loop generates search queries, decides when to call a search tool and when to write output, etc. Systems like ReAct-RC (Reading Comprehension) or Meta’s AgentBench use a single-agent with chain-of-thought plus optional web calls. On the multi-agent front, frameworks like AutoGen and AgentOS allow defining multiple cooperative agents and have even been used to replicate research workflows. We won’t enumerate them all, but it’s clear the ecosystem is lively. Finally, there are emerging benchmarks worth noting. The survey critiques existing benchmarks as inadequate (e.g., they often restrict agents to a fixed dataset rather than letting them truly search the open web, and their metrics don’t capture report quality). In response, several new benchmarks have appeared. For example, Bosse et al. introduced DeepResearch Bench to test LLM agents on web-search tasks. Zhang et al. propose a FINDER benchmark – 100 human-curated research tasks, each with a structured checklist of items a good report must satisfy – to accurately measure agent performance on report generation. They also define a “DeepResearch Failure Taxonomy” of common agent errors (misunderstanding queries, hallucinating facts, etc.). These efforts echo the survey’s call for more realistic evaluation: we can expect that, going forward, new tasks will emphasize interactive querying, multi-hop reasoning, and verifiable outputs, rather than just single-turn Q&A. Lessons, Directions, and Integration. What can we take away from this survey for building or using deep research agents?. First, architecturally, it's clear there is no one-size-fits-all. A lightweight research bot might use a simple static pipeline with one LLM and a few APIs. A heavyweight version might employ multiple specialized agents, each with distinct responsibilities. The right choice depends on scale and reliability requirements. The taxonomy suggests that hybrid designs (a mostly static pipeline with some dynamic, or a few cooperating agents rather than dozens) may strike a balance. In our own work, we should identify which parts of the workflow might need on-the-fly flexibility (warranting a dynamic step) and which can safely be agumented as fixed sub-processes. Second, retrieval strategy is paramount. Allowing the agent to access live information is key. Whenever possible, we should connect agents to real web data – through search APIs, news APIs, or (if safe) direct browsing – rather than confining them to stale corpora. We should also invest in good query generation. Current research shows that rewriting a complex question into sub-queries significantly improves results. Given the survey’s emphasis on “multi-hop retrieval”, building or fine-tuning modules that automatically derive intermediate queries will make a big difference. (Some advanced agents already fine-tune LLMs to produce better search queries.). Third, tool integration should be as seamless as possible. MCP-style protocols are still new, but we can start by designing clear interfaces for each tool. For example, define exactly what data format a new PDF reader or charting API uses, then train or prompt the model to use it. We should maintain an inventory of tools (search interfaces, data processors, code executors, etc.) and think about how to route tasks to them. If multiple agents or humans might call these tools, documenting them in a machine-readable way (MCP) will pay off. Fourth, memory and verification can’t be afterthoughts. The survey repeatedly notes that agents need robust fact-checking and long memory to be trustworthy. We should incorporate verification steps: for any factual claim in the report, try to back it with a source snippet or use external fact-check tools. Also, consider incremental saving of what the agent discovers: possibly storing intermediate facts in a knowledge base that the agent queries as it goes. This not only avoids repeated work but also allows post-hoc auditing (“which sources did you cite for that data?”). Fifth, evaluation must evolve as well. If we’re developing our own research agent, it makes little sense to only test it on fixed QA datasets. Instead, simulate real research tasks: assign it a topic, let it freely use the web, then have an expert inspect the output for correctness and completeness. Consider building a checklist of requirements (much like FINDER does) and scoring against it. We should also measure latency and resource use, since asynchronous or multi-agent setups can get expensive. In sum, align our success metrics with the end goal: a useful, human-readable research report, not just correct paragraphs or codesnippets. Finally, future directions from the survey are worth watching. It emphasizes extending beyond individual agents to entire ecosystems. One vision is an “Agent-to-Agent” or A2A network where research agents share workflows and tools. For example, one could imagine a library of specialized sub-agents (one that knows biotech journals well, another with medical DB access, etc.) that can be dynamically composed for a project. Another direction is true continual learning: agents that not only consume new data but can upload discoveries back into a common knowledge base, then retrain themselves periodically. The mention of “self-evolving, multi-agent architectures” hints at agents that spawn or upgrade new variants on the fly. This is cutting-edge, but for now it suggests designing systems in a modular way so that components can be improved independently. There’s also an implicit call for better human-AI collaboration. Many deep research frameworks still assume full autonomy, but one could incorporate periodic human checks. A practical DR agent might, for instance, stop and ask for clarification or confirmation at key points (especially when the risk of hallucination is high). Some diagrams even show a human “supervisor” agent in the loop. As roboticists, we’re used to human-in-the-loop systems; applying that wisdom to research agents is sensible until trust grows. Conclusion. Deep Research Agents are an exciting frontier at the intersection of NLP, IR, and planning. This survey by Huang et al. lays out the landscape: the what and how of such agents, as well as the gaps we must fill. In plain terms, these systems aim to automate the full-stack of research: from gathering information to generating a coherent report. Achieving that requires assembling a suite of techniques – search APIs, browsing tools, code execution, multi-agent orchestration, long-term memory – all wrapped in a smart planning loop. What’s clear is that we’re still in the early days. Current agents can impress on toy tasks, but struggle with truly open-ended inquiry. The paper critiques existing benchmarks as too narrow and urges the community to build tasks that mirror real research workflows. For anyone in robotics or AI looking to leverage these ideas, the roadmap is helpful. If you want your system to autonomously explore a problem domain, think in terms of planning, retrieval, and iterative tool use. Decide whether a static script or an adaptive agent loop suits your case. Build in mixed-initiative capabilities – maybe a first-pass static pipeline augmented by an LLM that can override or extend steps. Give your agents access to live, diverse data sources. And as you develop, adopt or even contribute to community tools (like LangChain, AgentOS, etc.) and protocols (MCP, A2A) that make integration easier. In summary, deep research agents promise to boost productivity by shouldering tedious literature surveys and data analysis. This survey gives us a clear framework to analyze these agents and to measure progress. It reminds us that success isn’t just about having a bigger model, but about smarter architecture: how the agent sees the world, reasons over it, and grows its knowledge over time. The road ahead involves not only better models but system-level engineering. It's a grand challenge – enabling an AI to do meaningful research – but the paper charts the path and highlights where the potholes are. Future work along these lines will determine how close we truly get to AI that can “think” and explore like a researcher. Sources: The definitions and taxonomy above come from Huang et al. (2025). The discussions of static vs dynamic workflows and agent architectures draw on that survey as well as complementary analyses. Industry context is cited from an AI wiki on deep research. Examples of current agent frameworks were taken from LangChain’s documentation. Critiques of benchmarks and future recommendations are explicitly discussed in the survey’s TL;DR and related works on new benchmarks. Our explanations blend these references with general knowledge of agent design. All quoted phrases and figures are cited in-text.