# The deep-research agent wars

URL: https://www.thedeepfeed.ai/posts/2026-04-30-deep-research-agent-wars/
Category: Agents
Published: 2026-03-12
Author: the-deep-feed
Tags: agents, deep-research, langgraph, open-source, infrastructure
Kind: deep

> Fifteen open-source deep-research agents reduce to four architecture archetypes. Two of the four are dead ends. Here is the field guide for picking.

## TL;DR

- **Fifteen** serious open-source deep-research agents collapse into **four architectures**: recursive tree search, planner+executor, RL-trained agentic model, and RAG-pipeline.
- Two are converging on production. **Planner+executor** (gpt-researcher, LangChain open_deep_research, DeerFlow) is the default. Recursive tree (dzhng/deep-research, WebWeaver) is the comeback.
- **RAG-pipeline agents** like deep-searcher are private-corpus tools, not deep-research engines. They lose on hard open-web queries.
- **RL-trained models** (Tongyi, MiroThinker, OpenResearcher) win benchmarks but require their own model. They are research projects, not building blocks.
- In twelve months **three or four of these fifteen** will still be installed. Pick the one whose architecture matches your query shape, and stop building your own.

![Four agent archetypes — the field guide for deep research](/post-images/deep-research-agent-wars/hero.jpg)

Together AI's release was a useful institutional marker that the field was no longer just a hobby category:

> Introducing v2 of our Open Deep Research app!
>
> Generate detailed reports on any topic with open source LLMs. Fully free & open source.
>
> We're releasing everything: evaluation dataset, code, app, and blog 🔥
>
> — [@togethercompute](https://x.com/togethercompute/status/2032524281461223614), Mar 13, 2026

OpenAI's Deep Research [shipped in February 2025](https://openai.com/index/introducing-deep-research/) and the category exploded. Anthropic followed with a [public write-up of its multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) in June. By the end of that year there were a dozen serious open-source clones with five-figure star counts. By April 2026 the count is past fifteen, several from large labs (Alibaba's Tongyi, ByteDance, Tencent, Microsoft, Stanford, HKU), and the marketing copy has fully homogenised. Every README promises "agentic research." Every demo writes a Wikipedia-grade brief in three minutes.

The READMEs lie about the same things. The architectures do not.

Read the code and the field collapses into four shapes. Two are converging on what production deep research actually looks like. The other two are dead ends in the sense that matters here: builders should not adopt them. This is the field guide.

> **15** serious open-source agents
>
> **4** architecture archetypes once you read the code
>
> **2** that builders should actually adopt

The repos look different on the README and converge in the source. Different planner prompts, the same outer loop: a for-loop wrapping a search API and a synthesis call. The moat ends up being the eval set, not the architecture.

## What deep research is, and isn't

A deep-research agent takes a high-level question, decomposes it into searches, runs the searches in some order, reads what comes back, and writes a synthesised report with citations. Every implementation has the same outer shell. The architecture is what happens between "received a query" and "wrote a paragraph."

Three things often get called deep research and shouldn't be. RAG over a fixed corpus is question answering. A single LLM call with a `web_search` tool is a chatbot with internet. A workflow that writes a literature review of papers you already curated is a writing assistant. A deep-research agent decides what to look up, refines based on what it finds, and stops when it has enough. None of those three do all of that.

Hold that bar and the field is smaller than the GitHub trending page suggests.

## The four archetypes

The fifteen serious projects map cleanly to four architecture patterns. Each pattern has a defining loop, a representative implementation, and a failure mode.

![Four archetypes as stacked planes — the architecture stack](/post-images/deep-research-agent-wars/archetype-axonometric.jpg)

### Recursive tree search

Take the query, generate N sub-queries (the breadth), search each, extract findings, generate follow-ups, recurse one level deeper with breadth halved. Terminate when depth runs out. Synthesise from the accumulated learnings.

The reference implementation is [dzhng/deep-research](https://github.com/dzhng/deep-research). Under 500 lines of TypeScript, 18.7K stars. The defaults are breadth 4, depth 3, breadth halving at each level (4 → 2 → 1), giving roughly 20–30 searches per run. [nickscamara/open-deep-research](https://github.com/nickscamara/open-deep-research) wraps the same loop in a Next.js chat UI. Alibaba's [WebWeaver](https://github.com/Alibaba-NLP/DeepResearch) replaces the flat learnings array with a "dynamic outline" that restructures during the run.

This pattern is the easiest to read. It has clear pathologies. Cost grows with breadth × depth. The agent has no global view of what it has already covered. Bad early queries poison the lower levels of the tree. The shape works when the question has a coherent topic but unknown depth. It falls over on broad shallow questions where the breadth multiplier just burns money. It is also the cleanest reference code in the category — `dzhng/deep-research` is short enough to read end-to-end before building anything fancier.

### Planner + executor

Generate a plan up front (a list of sub-questions or sections), execute the plan in parallel, synthesise. The classical pipeline. [assafelovic/gpt-researcher](https://github.com/assafelovic/gpt-researcher) is the OG implementation: planner generates questions, crawler agents gather data per question, publisher writes the report. 26K stars, four years old, still the most-deployed. Harrison Chase, the LangChain founder, has been one of its most vocal endorsers:

> 🚀GPT-Researcher from @assaf_elovic and @tavilyai is the first and best open source deep research agent implementation
>
> Love to see the native LangSmith integration! PR:
>
> All agents need good observability!!
>
> — [@hwchase17](https://x.com/hwchase17/status/2018725920543256800), Feb 3, 2026

[langchain-ai/open_deep_research](https://github.com/langchain-ai/open_deep_research) is the same pattern with a state machine: a supervisor agent fans out to researcher agents, each section is researched independently, a review pass evaluates the draft and loops back if gaps exist. ByteDance's [deer-flow](https://github.com/bytedance/deer-flow) (57K stars) layers the same shape on top of LangGraph and adds a code-execution sandbox, an MCP server, and persistent memory.

What changed in this archetype over the last year is the addition of an inner loop. The pure planner+executor was static: generate plan, execute plan, ship. Modern versions like [qx-labs/agents-deep-research](https://github.com/qx-labs/agents-deep-research) add a knowledge-gap detector that runs after each research round and re-routes the executor toward gaps it identifies. The plan is now a starting point that the agent is allowed to revise.

This pattern is what production looks like.

![Planner+executor with the gap-detection feedback loop](/post-images/deep-research-agent-wars/planner-executor-loop.jpg)

The maintainers of both reference implementations describe the shape the same way. `open_deep_research` was published as a reference, not a product, and the supervisor → researchers → gap-loop pattern is the one that has survived contact with real users. `gpt-researcher` started as a weekend project in 2023; four years later it still works because the planner+executor shape is just correct. Features get added around it; the inner loop does not get replaced.

### RL-trained agentic model

Don't prompt-engineer the agent. Train the model to be the agent. Alibaba's [Tongyi DeepResearch](https://github.com/Alibaba-NLP/DeepResearch) is a 30B Mixture-of-Experts model trained end-to-end with RL on a synthetic data pipeline of research trajectories. [MiroMindAI/MiroThinker](https://github.com/MiroMindAI/MiroThinker) is the same idea tuned for "interactive scaling": up to 600 tool calls per task in a 256K context window. [TIGER-AI-Lab/OpenResearcher](https://github.com/TIGER-AI-Lab/OpenResearcher) trained on 96K research trajectories and posts 54.8% on BrowseComp-Plus, beating GPT-4.1 and Claude Opus 4 on that benchmark. Nvidia adopted it for Nemotron.

These models top every public benchmark. Tongyi sits at #1 on BrowseComp at the time of writing. The architecture inside is just a ReAct loop. The difference is that the reasoning is learned weights instead of a system prompt.

The benchmark numbers are real. The category is also one for model labs, not for application builders. You cannot adopt MiroThinker and use a different LLM for synthesis. The architecture is the model. If you want a better Claude/GPT/Gemini-driven research agent, this archetype gives you nothing to copy into your stack. There is also a real generalisation question: BrowseComp is a fixed corpus, and a benchmark win on it doesn't necessarily translate to "this works on my queries."

### RAG-pipeline

Ingest a corpus, embed it into a vector DB, answer questions against the corpus with a reasoning loop layered on top. [zilliztech/deep-searcher](https://github.com/zilliztech/deep-searcher) is the canonical example: load local files into Milvus, then "reason over them" with optional web augmentation. SurfSense follows the same pattern over Postgres+pgvector.

These tools are excellent for what they actually are: question answering against a private corpus. They get marketed as deep research because the retrieval step looks similar on a slide. They are not deep research. The agent does not decide what new sources to fetch. The corpus is fixed at ingestion time. The "depth" is depth of retrieval into existing chunks.

## The fifteen, mapped

| Project | Stars | Archetype | Stack | License | Status |
|---|---|---|---|---|---|
| [gpt-researcher](https://github.com/assafelovic/gpt-researcher) | 26K | Planner+executor | Python, any LLM, multi-search | Apache-2.0 | Production |
| [bytedance/deer-flow](https://github.com/bytedance/deer-flow) | 57K | Planner+executor (super-agent) | LangGraph, Python+TS | MIT | Production |
| [stanford-oval/storm](https://github.com/stanford-oval/storm) | 28K | Planner+executor (perspective sim) | DSPy, LiteLLM | MIT | Production (academic) |
| [langchain-ai/open_deep_research](https://github.com/langchain-ai/open_deep_research) | 11K | Planner+executor (supervisor) | LangGraph | MIT | Production |
| [qx-labs/agents-deep-research](https://github.com/qx-labs/agents-deep-research) | 752 | Planner+executor + gap loop | OpenAI Agents SDK | MIT | Production |
| [dzhng/deep-research](https://github.com/dzhng/deep-research) | 18.7K | Recursive tree | TypeScript, Firecrawl | MIT | Production |
| [nickscamara/open-deep-research](https://github.com/nickscamara/open-deep-research) | 6K | Recursive tree (web UI) | Next.js, Firecrawl | MIT | Production |
| [Alibaba-NLP/DeepResearch (Tongyi)](https://github.com/Alibaba-NLP/DeepResearch) | 18.6K | RL-trained model | Custom 30B MoE | Apache-2.0 | Research |
| [MiroMindAI/MiroThinker](https://github.com/MiroMindAI/MiroThinker) | 8K | RL-trained model | Custom 30B MoE | Apache-2.0 | Research |
| [TIGER-AI-Lab/OpenResearcher](https://github.com/TIGER-AI-Lab/OpenResearcher) | 615 | RL-trained model | 30B-A3B MoE | Apache-2.0 | Research |
| [zilliztech/deep-searcher](https://github.com/zilliztech/deep-searcher) | 7.7K | RAG-pipeline | Milvus, OpenAI | Apache-2.0 | Production (private corpus) |
| [zaidmukaddam/scira](https://github.com/zaidmukaddam/scira) | 11.5K | Planner+executor (mode-routed) | Next.js, Vercel AI SDK | Apache-2.0 | Production |
| [SkyworkAI/DeepResearchAgent](https://github.com/SkyworkAI/DeepResearchAgent) | 3.3K | Planner+executor (self-evolving) | Autogenesis, OpenRouter | MIT | Research |
| [HKUDS/Auto-Deep-Research](https://github.com/HKUDS/Auto-Deep-Research) | 1.5K | Planner+executor | Any LLM | MIT | Production |
| [virattt/dexter](https://github.com/virattt/dexter) | 20.9K | Planner+executor (financial) | TypeScript, multi-search | MIT | Production |

Tom Dörr, who curates this category for 200K+ followers, kept surfacing new entrants:

> Open-source agent for long-horizon deep research
>
> — [@tom_doerr](https://x.com/tom_doerr/status/2047144828903784761), Apr 23, 2026

Eleven of fifteen are some flavour of planner+executor or recursive tree. The other four split between RL-trained and RAG. The category looks crowded; the architecture space is narrow.

![Cost vs quality across the fifteen — the architecture clusters](/post-images/deep-research-agent-wars/cost-vs-quality-scatter.jpg)

> **8/15** are some flavour of planner+executor
>
> **3/15** are RL-trained models (research projects, not building blocks)
>
> **2/15** are RAG-pipeline (mislabelled as deep research)

### How the four archetypes compare on the dimensions that matter

| Dimension | Recursive tree | Planner+executor | RL-trained model | RAG-pipeline |
|---|---|---|---|---|
| Cost predictability | High (breadth × depth is a knob) | Medium (gap loop is unbounded) | Low (depends on rollout) | High (retrieval is bounded) |
| Open-web coverage | Strong | Strong | Strong | Weak (corpus is fixed) |
| Plan visibility to user | Implicit (tree shape) | Explicit (sections) | None | None |
| Mid-run steerability | Low | Medium (replan on gap) | Low | Low |
| Model swappability | Yes | Yes (per phase) | No (model = agent) | Yes |
| Citation entailment risk | Medium | Medium | Low (trained for it) | High (chunk mismatch) |
| Best for | Long-horizon depth | Section-shaped reports | Benchmarks | Private corpora |
| Production readiness | Medium | High | Research only | Production (closed corpus) |

The shape of this table is the entire argument. Planner+executor wins on every dimension a builder cares about except cost predictability, where recursive tree is genuinely better. RL-trained wins on benchmarks and nothing else. RAG-pipeline wins only when the question never leaves the corpus.

## Why RAG-pipeline can't keep up

The pitch is reasonable. Embed your sources once, retrieve relevant chunks, let the LLM reason. It works on closed corpora: internal docs, a curated paper set, a company knowledge base. It loses the moment the question requires fetching something not already in the index.

DeepTRACE, the citation-audit framework from Salesforce and Microsoft Research, [tested ChatGPT Deep Research, Gemini Deep Research, and Perplexity](https://arxiv.org/abs/2509.04499) and found 18–30% of citations problematic. The dominant failure mode for RAG-style systems was misattribution: the source existed in the index but did not actually say what the report claimed. The retrieve-then-cite property (the constraint that any cited URL must have been physically fetched and stored during the current research run) is what separates trustable systems from plausible-sounding ones, and it is structurally hard for a vector DB to provide. The vector DB returns chunks; the agent does not know whether the chunk is the strongest evidence on the open web or just the closest match in a frozen corpus.

The deeper problem is that RAG is a static contract. You decide at index time what the agent can know. A real research question, like "what's happening with the Hyperliquid validator set this month," has zero useful matches in a corpus that was built last quarter. RAG-pipeline projects like deep-searcher know this and bolt on optional web search, which turns them into a worse planner+executor with a vector DB attached.

If your queries hit a private corpus and the corpus is the moat, use deep-searcher. Don't use it for open-web research.

![Two of the four archetypes are dead ends for builders](/post-images/deep-research-agent-wars/two-dead-ends.jpg)

## Why RL-trained as a category is too narrow

The Alibaba and MiroMind models are real. They top BrowseComp-Plus and they will keep topping it. They are also unusable as a building block. You cannot mix MiroThinker's research loop with Claude's writing or with GPT's structured-output formatter. The agent is the model; you take it whole or you take a different one.

That makes the archetype a research direction rather than a substrate. For a frontier lab building its own research product, training the agent is the right move; Tongyi's reward signal trains jointly on factual accuracy, citation density, and coherence — which is genuinely hard to do with prompting. For everyone else, the practical question is which architecture to wrap around the LLM you already pay for. RL-trained models do not answer that question.

There is a second, narrower problem. The benchmarks these models top are research benchmarks. BrowseComp is a fixed test set. GAIA is a fixed test set. Neither measures whether the agent figured out it should stop and ask the user a clarifying question, and neither measures cost. Across the implementations surveyed in the source data, production deployments care about cost ceilings and interruptibility. RL-trained models are tuned for neither.

OpenResearcher being adopted by Nvidia for Nemotron is the correct destiny for this archetype: it becomes the underlying model that someone else's planner+executor calls. The framework guidance most builders are getting from people maintaining these stacks is consistent: do not fine-tune a research model unless you are a frontier lab. For the next two years, the wrap-the-best-LLM strategy will out-ship custom-trained agents.

## The planner+executor pattern is winning

Eight of the fifteen are some flavour of planner+executor and they are the ones being deployed. The reason is that the pattern decomposes cleanly into the four pieces a real research workflow needs: a plan you can show the user, parallelism you can rate-limit, a synthesis step you can swap models on, and a verification step you can audit.

The current best-of-breed inside this archetype is something like the LangChain `open_deep_research` shape with the `qx-labs` knowledge-gap loop bolted on. The flow is:

1. **Plan.** A supervisor agent generates a list of section-level questions for the report.
2. **Research.** Each section spawns a researcher agent that runs its own multi-search-and-extract loop in parallel.
3. **Gap detection.** After the first pass, an evaluator looks at what was returned and asks "what is still missing?" New questions go back to the executor.
4. **Synthesise.** A stronger model (usually a reasoning-tier one) writes the report from the accumulated state.
5. **Verify.** A citation pass drops or rewrites any claim where the cited source doesn't entail it.

Anthropic's own write-up of their internal multi-agent research system describes the same skeleton. So does OpenAI's Deep Research, modulo the model being theirs. The pattern has won inside the labs and outside them. The architecture is converged; the next year is about evals, citations, and interruptibility, not about building a sixteenth research agent.

The two subtleties that separate good implementations from bad ones are state and citation discipline. State has to be a single object passed through the pipeline (the LangGraph approach) so that the gap detector and the synthesiser see the same evidence. Citation discipline has to be `retrieve-then-cite`: the model is allowed to cite only URLs it has physically fetched during this run. Most published critiques of Perplexity-tier output trace back to the absence of that constraint, and it is invisible at the README level.

Two implementations worth a closer look. [DeerFlow](https://github.com/bytedance/deer-flow) is the most platform-shaped of the lot. It adds a code sandbox so the researcher can compute, an MCP server so external tools can be added without code changes, and a memory system that persists across sessions. [Scira](https://github.com/zaidmukaddam/scira) is mode-routed rather than supervisor-routed: the user picks a mode (Web, Academic, Crypto, Extreme) and the toolset is fixed at that point. Both are planner+executor underneath. Both ship today.

## The recursive-tree resurgence

Recursive tree search looked like it was losing in 2025. It is making a comeback in 2026 for two reasons.

The first is cost honesty. The user can be told "this is going to do 24 searches and take three minutes" because breadth × depth is a knob. Planner+executor pipelines are harder to bound. The gap loop runs until it stops finding gaps, which means cost is uncapped. For long-horizon "spend an hour and write me twenty pages" tasks, recursion is the right shape because it terminates predictably.

The second is WebWeaver. Alibaba's variant, published at ICLR 2026, replaces the flat `learnings[]` array with a dynamic outline that restructures during the run. Sections get added, merged, or expanded based on evidence density. The recursion is no longer "search and pile up bullets." It is "search and reorganise the report skeleton in flight." Early results show it beats flat tree search and beats fixed-plan executors on completeness metrics. The paper is the strongest argument the recursive-tree archetype has had in two years — arguably the most interesting idea in deep research since the planner pattern itself.

For broad exploratory queries, the kind where the user genuinely doesn't know what they're looking for, the recursive shape is also the only one that surfaces unexpected branches. A planner+executor cannot research what it didn't plan for, because the plan came first. A tree can.

The honest read of this archetype today is hybrid. The pattern that actually wins on long, exploratory tasks looks like a planner+executor that can spawn recursive sub-trees when the executor flags a sub-question as "open-ended." DeerFlow does this in spirit; WebWeaver does it inside the recursion itself; `qx-labs/agents-deep-research` approximates it with the gap loop. Picking pure recursive over pure planner is increasingly the wrong question. Both are wrappers around the same underlying primitive: search, evaluate, decide what to do next.

## What to pick

A short field guide.

- **You want a deep-research feature in a product, today, with a model API.** Use [gpt-researcher](https://github.com/assafelovic/gpt-researcher) or [LangChain open_deep_research](https://github.com/langchain-ai/open_deep_research). Both are battle-tested planner+executors, both let you swap models per phase, and both have been deployed at non-trivial scale.

- **You want a hosted product, today, that does the research for you.** Use OpenAI Deep Research or Anthropic's. The labs have already paid the integration tax and they own their evals. Building this from scratch as a side project is a worse use of an engineer-month than almost anything else.

- **You want depth, configurability, and predictable cost.** Use [dzhng/deep-research](https://github.com/dzhng/deep-research) or fork it. Five hundred lines of TypeScript, breadth and depth are both knobs, you can read the whole thing before lunch.

- **You want a private-corpus answering tool and you've been told it should be "deep research."** Use [zilliztech/deep-searcher](https://github.com/zilliztech/deep-searcher). Stop calling it deep research. Your users don't care what you call it. They care whether it answers questions about their own documents.

- **You are training your own research model.** Read Tongyi, MiroThinker, and OpenResearcher. The RL pipelines and the synthetic-trajectory generation are the meaningful prior art. Do not, however, expect to fine-tune one of these and have it slot into someone else's pipeline.

- **You want to build it yourself because the existing ones don't fit.** They probably do fit. The category is younger than it feels, the gap between "I have an idea for a research agent" and the existing implementations is mostly UI and tool selection, and the planner+executor inner loop is a problem the field has now solved twice independently. Adopt and skin.

## The unsolved problems above the agent loop

The architecture is the easy part. Every serious project has converged on roughly the same loop. The hard problems live in the layer above the loop, and they are the reason production deep-research products feel uneven even when they are built on top of a "winning" architecture.

**Citation entailment.** A retrieve-then-cite contract sounds simple (only cite URLs you fetched in this run) but the failure mode the [DeepTRACE audit](https://arxiv.org/abs/2509.04499) found is subtler: the source got fetched, the chunk got embedded into context, but the model paraphrased a claim the source did not actually make. 18-30% of citations across ChatGPT Deep Research, Gemini Deep Research, and Perplexity were problematic by that test. Nobody has shipped a verifier that runs at synthesis time and rewrites bad cites. Until somebody does, every report is a credibility risk.

**Cost ceilings.** Planner+executor pipelines with a gap loop will keep researching as long as gaps keep appearing. On a hard query that means thousands of tool calls and a four-figure invoice if the user forgot to set a cap. Most production deployments hard-cap at the wrapper level (DeerFlow exposes `max_iterations`, `qx-labs` exposes a budget, gpt-researcher exposes a step count) but no implementation has a principled "spend smarter" policy that allocates a budget across sections by their information density.

**Mid-run steering.** A user watching a 12-minute research run wants to be able to say "actually, drop section 3, dig deeper on section 5." Almost no implementation supports this. The plan-then-execute shape is structurally hostile to it. The few that do (Scira's mode-routed UI, DeerFlow's checkpoint system) treat steering as a restart, not a true edit. This is the most user-visible gap in the category.

**Tool selection beyond web search.** Every agent has a `web_search` tool and a `fetch` tool and that's it. Real research uses calculators, code execution, internal databases, structured APIs, image-and-table extraction. DeerFlow ships a code sandbox and an MCP server because ByteDance figured out the tool landscape before everyone else. The rest of the field is one tool deep.

> **18-30%** of citations problematic in DeepTRACE's audit
>
> **0** implementations with principled cost-allocation across sections
>
> **1** category-defining problem nobody has solved: mid-run steering

Andy Hall, who tracks this space closely, flagged the orthogonal trend that is starting to matter:

> Lots of exciting progress in using agents for research, as Chris's thread shows!
>
> Some other recent developments I'm tracking:
>
> (1) The rise of Codex as a powerful research agent roughly comparable to Claude Code, as @soumitrashukla9 has been documenting
>
> (2) Defining hard
>
> — [@ahall_research](https://x.com/ahall_research/status/2049541137598382573), Apr 29, 2026

## The twelve-month forecast

In twelve months, three or four of these fifteen will still be installed at scale. The survivors will be `gpt-researcher`, `LangChain open_deep_research`, `DeerFlow`, and one of the recursive-tree implementations (most likely `dzhng/deep-research` or whatever WebWeaver's open-source version becomes). The rest will follow the path every category in this part of the stack follows: a few canonical implementations absorb the patterns, the others become reference reading and dead links. This is not a bad outcome for the field. It is what it looks like when an architecture wins.

The interesting work for the next year is not building a sixteenth deep-research agent. It is the pieces around the pattern that nobody has solved well. Citation verification that actually catches misattribution. Interruptibility that lets a user steer mid-run. Tool registries that go beyond web search and Firecrawl. Those are the gaps. The agent loop itself is done.

> **3 or 4** of these fifteen will still be installed at scale in twelve months
>
> **1** unsolved problem above the agent loop: citation entailment

## Sources

- [OpenAI — Introducing deep research](https://openai.com/index/introducing-deep-research/)
- [Anthropic — How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)
- [GitHub — assafelovic/gpt-researcher](https://github.com/assafelovic/gpt-researcher)
- [GitHub — dzhng/deep-research](https://github.com/dzhng/deep-research)
- [GitHub — stanford-oval/storm](https://github.com/stanford-oval/storm)
- [GitHub — Alibaba-NLP/DeepResearch (Tongyi)](https://github.com/Alibaba-NLP/DeepResearch)
- [GitHub — MiroMindAI/MiroThinker](https://github.com/MiroMindAI/MiroThinker)
- [GitHub — zaidmukaddam/scira](https://github.com/zaidmukaddam/scira)
- [GitHub — bytedance/deer-flow](https://github.com/bytedance/deer-flow)
- [GitHub — langchain-ai/open_deep_research](https://github.com/langchain-ai/open_deep_research)
- [GitHub — zilliztech/deep-searcher](https://github.com/zilliztech/deep-searcher)
- [GitHub — nickscamara/open-deep-research](https://github.com/nickscamara/open-deep-research)
- [GitHub — qx-labs/agents-deep-research](https://github.com/qx-labs/agents-deep-research)
- [GitHub — SkyworkAI/DeepResearchAgent](https://github.com/SkyworkAI/DeepResearchAgent)
- [GitHub — HKUDS/Auto-Deep-Research](https://github.com/HKUDS/Auto-Deep-Research)
- [GitHub — TIGER-AI-Lab/OpenResearcher](https://github.com/TIGER-AI-Lab/OpenResearcher)
- [arXiv — DeepTRACE: Citation Audit of Deep-Research Systems](https://arxiv.org/abs/2509.04499)
- [GitHub — virattt/dexter](https://github.com/virattt/dexter)
- [WebWeaver — Dynamic outline restructuring for deep research](https://arxiv.org/abs/2602.00114)

---

Canonical: https://www.thedeepfeed.ai/posts/2026-04-30-deep-research-agent-wars/
Site: https://www.thedeepfeed.ai
Full corpus: https://www.thedeepfeed.ai/llms-full.txt