Deep learning has mastered many narrow domains. Image recognition works. Language understanding works. But training agents that can actually conduct research, that can search through vast information repositories, extract evidence, and synthesize answers, remains unsolved. The gap is real: knowing facts and knowing how to find and use facts are different problems entirely.
A language model trained on text knows what’s true about the world only to the extent that world appears in its training data. It can’t go beyond that. Research agents need something different. They need to navigate a corpus of information, decide which sources matter, and build arguments piece by piece. They need to learn the workflow of actual research: ask a question, search for relevant sources, skim results, dive deeper into promising leads, extract evidence, synthesize an answer.
Current work on research agents trains on trajectories collected from real web interactions. Systems like web-based question-answering use live API calls to gather training data. The problem compounds across three dimensions. First, cost and speed: each trajectory requires multiple API calls, so scaling to 100K trajectories becomes expensive and slow. Second, instability: web results change. Search snippets get reformatted. Websites go down. An experiment reproducible three months ago fails today because the web moved. Third, reproducibility and openness: since everything depends on proprietary APIs, you can’t fully open-source your work. Researchers without API access can’t rebuild the training set. Competitors can’t use your approach. This creates a research moat around teams with deep pockets and API relationships, not around teams with better ideas.
So that means the motivation for OpenResearcher is urgent: if research agents are to become widely-used tools rather than proprietary services locked behind paywalls, we need training pipelines that are cheap, stable, reproducible, and open.
Why current pipelines are holding us back
Existing research agent training is fragile infrastructure masquerading as progress. Each team builds its own version, dependent on services beyond their control. APIs change interfaces or pricing. Servers go down. A pipeline that works today may break tomorrow.
This fragility has real costs. It means experiments take longer to run because you’re waiting on external services. It means reproducing work from a competitor’s paper often fails because their API landscape may differ from yours. It means the research community can’t easily build on prior work. When your training data comes from live web APIs, the data itself is locked away, inaccessible to others.
But there’s a deeper issue hiding beneath the practical problems. Current approaches treat corpus building and trajectory synthesis as a single intertwined process. They use the live web as both library and query engine simultaneously. This conflates two fundamentally different problems.
The insight: decouple corpus from synthesis
The elegance of OpenResearcher lies in a simple architectural choice: completely separate the corpus-building phase from the trajectory-synthesis phase.
Think of research in two distinct steps. First, you gather your reference library. You know what documents exist, how they’re organized, what they contain. Second, you use that library to answer questions. You search, you read, you extract evidence. Most existing pipelines interleave these steps, running both against the live web at once.
OpenResearcher inverts this. Build a corpus once, offline, carefully curated from multiple sources. Then run as many training trajectories as you want against that fixed corpus. No external dependencies. No changing results. Same environment every time.
This separation is powerful because the two phases have different constraints. Building a good corpus is expensive and happens once. You want to curate it, validate it, merge multiple sources. You want it to be stable. Trajectory synthesis is cheap once the corpus exists. You can run it many times with different teacher models, different prompts, different agent configurations. You can even run it offline on a single machine. By decoupling these, OpenResearcher makes both better: corpus building gets the attention it deserves, and trajectory synthesis becomes scalable and reproducible.
