deep-research: The research agent that wins by never opening a browser

Aaron Francis turns web research into a straight-line pipeline: fan out search, canonicalize and dedupe URLs, fetch with retries, then synthesize a citation-grounded brief.

10 min read • View on GitHub • More from aarondfrancis

A stream of web search results and article scraps moves through a pair of sieves and becomes a single bound report. An oversized browser window sits off to the side, unused, which makes the point that the system is about narrowing evidence, not browsing theatrics.
Search widens the net. Fetch narrows it. Synthesis writes the brief.
Key Takeaways

The surprise in aarondfrancis/deep-research is not that it can do deep research. It is that it refuses the thing most agent demos lean on: a live browser. Instead, Aaron Francis pushes the web through a narrower, cleaner pipeline. Search widens the net. Fetch strips the noise. Synthesis writes the brief.

The weird part is the point

Yesterday, OpenAI released Deep Research, a system that browses the web to summarize content and answer questions based on the summary. The system is impressive and blew our minds when we tried it for the first time.

Aymeric Roucher, Author · Open-source DeepResearch

That reaction captures the overlap. The project is not trying to out-browse the browser. It is trying to recover the useful parts of research and leave the rest behind. The stack makes the bet explicit: Browserbase Search for discovery, Browserbase Fetch for retrieval, OpenAI for synthesis, and no session-heavy browser automation in the middle.

The evidence funnel

The repo narrows the web before the model starts writing.

That funnel is the real product. The model never has to roam freely and invent its own search plan from scratch. It receives a smaller, curated bundle of pages that have already survived three filters: relevance, uniqueness, and fetchability.

Why Aaron Francis chose this path

Hedcut-style portrait of Aaron Francis based on his GitHub avatar, rendered in black ink on white. It introduces the builder behind the repo and signals that this article is about a practical engineering choice, not a faceless framework.

Francis is the kind of builder who tends to expose the mechanism instead of hiding it. The repository is small on purpose, with index.ts at the edge, src/main.ts orchestrating the flow, and focused modules for discovery, fetch, synthesis, async control, and HTTP handling. That shape matters. It keeps the architecture legible enough that you can see where the trust comes from.

What actually makes it work

The interesting part is not any single model call. It is the glue. src/discovery.ts expands a topic into multiple search angles and then canonicalizes URLs so tracking parameters and query-order noise do not create fake uniqueness. It also keeps results from collapsing into one domain bubble. src/fetch.ts is defensive about bad pages, using retries and content extraction to throw away nav chrome and cookie-wall sludge. Then src/synthesis.ts chunks sources into manageable groups and asks the model to write from evidence notes, not from memory.

A close-up illustration of several nearly identical URL strings being trimmed down to one canonical address. The image explains how the repo avoids duplicate fetches and keeps the source list clean.
Canonicalization turns near-duplicates into one source of truth.

That little step changes the economics of the run. Without it, the agent wastes requests on the same page under different URLs. With it, each fetch has more chance of adding something new.

A thin stack on purpose

The stack is plain TypeScript, not a framework maze. cheerio handles HTML parsing, dotenv handles configuration, and the custom async and HTTP helpers keep concurrency and backoff predictable. That is the larger design move: every layer is there to reduce surprise, not to impress anyone.

What it beats, and what it does not

SystemBrowser dependencyWhat it optimizesTrade-off
aarondfrancis/deep-researchNone in the core pathFast, citation-grounded briefsLess able to handle interactive pages that need a live session
Playwright-style browser agentFull browser sessionInteractive site coverageHeavier, slower, and more brittle
LangChain Open Deep ResearchConfigurableComposable production workflowsMore setup and orchestration overhead
A split illustration shows one side drowning in tabs, loading spinners, and browser automation clutter, while the other side uses a compact API pipeline to produce a clean report. It clarifies the cost difference between browser-heavy agents and an API-first research funnel.
The contrast is not feature count. It is operational weight.

integrating these LLMs into agentic systems can give them real superpowers!

merve merve, Developer · Open-source DeepResearch

That is the promise, and this repo shows the practical version of it. Agentic systems become useful when they are constrained by retrieval, not when they are allowed to wander. deep-research is closer to a disciplined evidence tool than to a free-form explorer, which is exactly why it feels credible.

The limits are part of the lesson

The limitations are not accidental. It is a proof of concept, not a full product, so there is no database, no UI, and no claim that every site can be handled without escalation. Some pages still want a live browser. The value here is narrower and better: show that a lot of research can be done with API calls, careful normalization, and a strict synthesis step.