Context Engineering and Agent Development at Scale: Building Open Deep Research

langchain · Tech · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: deep-research agents and context engineering

LangChain needed Open Deep Research to manage the context explosion created by long-running tool-calling agents, while continuing to adapt as model capabilities improved.

Constraints:

Architecture

Open Deep Research evolved from a structured research workflow into a more general tool-calling agent built with low-level orchestration primitives. Its context strategy combines offloading token-heavy tool observations to disk or state, high-recall summaries for retrieval decisions, compaction at tool-call boundaries, caching for repeated message history, parallel read-only subagents for context gathering, and a final one-shot writing step to avoid conflicting subagent-written sections.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  research-request["research request"] --> open-deep-research-agent["Open Deep Research agent"]
  open-deep-research-agent --> tool-calling-loop["tool-calling loop"]
  tool-calling-loop --> retrieval-and-tool-context["retrieval and tool context"]
  tool-calling-loop --> context-offload-store["context offload store"]
  context-offload-store --> summary-and-compaction-layer["summary and compaction layer"]
  summary-and-compaction-layer --> open-deep-research-agent
  open-deep-research-agent --> parallel-read-only-subagents["parallel read-only subagents"]
  parallel-read-only-subagents --> final-report-writer["final report writer"]
  open-deep-research-agent --> final-report-writer
  low-level-orchestration-runtime["low-level orchestration runtime"] --> open-deep-research-agent
  low-level-orchestration-runtime --> context-offload-store
  provider-prompt-cache["provider prompt cache"] --> open-deep-research-agent
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
research request User question or research objective that drives the agent trajectory. Open Deep Research agent
Open Deep Research agent Tool-calling research agent that decides the research path and coordinates context management. research request, tool-calling loop, context offload store, parallel read-only subagents, final report writer
tool-calling loop Repeatedly calls search/retrieval/tools and returns observations that must be managed as context. Open Deep Research agent, context offload store, summary and compaction layer
context offload store Externalized memory such as disk or LangGraph state that holds raw tool outputs outside the main message history. tool-calling loop, summary and compaction layer, Open Deep Research agent
summary and compaction layer Produces high-recall summaries or compacted tool results so the model knows what can be retrieved later. context offload store, Open Deep Research agent
retrieval and tool context RAG/retrieval outputs and other tool observations that provide external research evidence. tool-calling loop, context offload store
parallel read-only subagents Subagents used for parallel context gathering when tasks are read-only and easy to parallelize. Open Deep Research agent, final report writer
final report writer Single final writing step that composes gathered context into the final report. Open Deep Research agent, parallel read-only subagents
low-level orchestration runtime LangGraph-like nodes, edges, checkpointing, and state management used without hiding agent internals behind high-level abstractions. Open Deep Research agent, context offload store
provider prompt cache Caching layer that can reduce latency and cost for repeated message history, though not context-quality issues. Open Deep Research agent

Data flow

A research request enters a LangGraph-style agent or workflow. The agent calls tools, offloads token-heavy observations to external storage/state, writes compact summaries back into the message history, optionally uses retrieval and caching, parallelizes read-only context gathering across subagents when appropriate, then performs final writing in one step from shared gathered context.

3 supporting quotes
“agent makes a bunch of tool calls. Those tool calls are passed back to the LM at each turn and you naively just plum all that context back.”transcript, stated
“Write those to disk and you can write back a summary. It could be a URL something so the agent knows it's retrieved a thing.”transcript, stated
“they're just doing context collection and you can do a write from all that share context after all the sub aents work”transcript, implied

Why this architecture

The architecture focuses on context engineering rather than simply adding more prompt text. It keeps raw observations retrievable, compresses high-recall summaries into the active context, isolates parallel research work where it is safe, and avoids high-level agent abstractions so the system can be rebuilt as model capabilities improve.

“context engineering is the challenge of feeding an LM just the right context for the next step which is highly applicable to agents”transcript, implied
“I'm actually wary of abstractions. I'm very sympathetic to that part of the critique of frameworks, but I don't hate low-level orchestration frameworks”transcript, stated

Models used: LLM tool-calling agent · summarization model · fine-tuned summarization model as cited from other agent systems · LangGraph runtime

Scale

Alternatives considered (roads not taken)

naively append all tool outputs to the message history

Rejected because: It caused token-heavy runs, context-window pressure, and long-context performance degradation.

“if you just naively plum in the context from each of those tool calls naively you just hit the context window of the LM”transcript, stated
“there's degradation in performance with respect to context length. And also the trivial problem of hitting the context window itself.”transcript, stated

irreversible pruning/summarization without raw context

Rejected because: Summarization can lose information, so raw context should remain available through offloading.

“the kind of warning that pruning comes with risk particularly if it's irreversible. And cognition kind of hits this too. They talk about we have to be very careful with summarization. You can even fine-tune models to do it effectively. That's actually why”transcript, stated
“but you still have that raw context available to you so you don't have kind of lossy uh compression or lossy summarization”transcript, stated

multi-agent subagents that independently write final sections

Rejected because: Independent subagent writing produced disjoint reports because subagents did not communicate enough.

“if you write report sections in each sub aent the final report is actually pretty disjoint. This is exactly Allesio's challenge and problem about you know using multi- aent. So I actually hit that exact problem. So I ripped out the independent writing and”transcript, stated

highly structured 2024-style research workflow

Rejected because: It initially improved reliability but later blocked tool-calling and MCP benefits as models improved.

“while the workflow was more reliable than building an agent back in 2024, that flipped pretty quickly as LMS got better and better and better.”transcript, stated
“I couldn't take advantage of the fact that tool calling was getting significantly better over time. So then I moved to an agent, started to remove structure, allow for tool calling, let the agent decide the research path. A subtle mistake that I made which”transcript, implied

Patterns

context-compaction (context-management)

Open Deep Research summarizes and compacts token-heavy tool results while preserving enough detail for later retrieval decisions.

“I try to prompt the summarization model to give kind of an exhaustive set of bullet points of the key things that are in the post”transcript, stated
“my summaries capture with high recall what's in the document but compress the content significantly.”transcript, stated

agent-memory (context-management)

The design offloads raw tool observations to disk or runtime state so the agent can fetch them later instead of carrying everything in active context.

“using the file system as externalized memory rather than just writing back the full contents of your tool calls”transcript, stated
“it could be kind of the the agent runtime state object. It could be the file system.”transcript, stated

multi-agent-orchestration (agent-architecture)

Parallel subagents are used where the work is read-only context gathering and can be merged by a final writing step.

“apply multi- aents to problems that are easily paralyzable that are read only for example context gathering for deep research”transcript, stated

tool-use-orchestration (agent-architecture)

Open Deep Research moved toward a tool-calling agent that lets the model choose the research path.

“So then I moved to an agent, started to remove structure, allow for tool calling, let the agent decide the research path.”transcript, stated

semantic-caching (serving)

The discussion highlights caching repeated prior message history to reduce latency and cost in looped agents.

“Manis talks about the idea of just caching your prior message history. It's a good idea.”transcript, stated
“So, caching reduces both latency and cost significantly. >> Yeah. But don't most other APIs auto cache for you? I mean, if you're using like OpenAI, you would just automatically have a cash hit.”transcript, stated

durable-execution (orchestration)

LangGraph is valued for low-level state management and checkpointing rather than opaque agent abstractions.

“I use Langraph because you get some nice you get checkpointing, you get state management. It's low-level stuff.”transcript, stated

Tradeoffs

Offload raw tool outputs while summarizing active context.

Chose externalized raw context plus compact summaries over passing all tool outputs back into the message history.

Rationale: This keeps raw evidence retrievable while reducing token pressure in the active model context.

“Don't just naively send back the full context of each of your tool calls. You can actually offload it”transcript, stated
“Write those to disk and you can write back a summary. It could be a URL something so the agent knows it's retrieved a thing.”transcript, stated

Use multi-agent parallelism only where task boundaries are clean.

Chose read-only parallel context gathering with one final write over subagents independently writing final solution components.

Rationale: Read-only research is easier to parallelize without conflicting decisions.

“use multi-agent in cases where there's very clear and easy parallelization of tasks.”transcript, stated
“they're just doing context collection and you can do a write from all that share context after all the sub aents work”transcript, stated

Move from a structured workflow to a more general agent as models improved.

Chose tool-calling agent deciding the research path over fixed section-decomposition workflow.

Rationale: The structured workflow was reliable for older models but blocked MCP/tool-calling improvements.

“So then I moved to an agent, started to remove structure, allow for tool calling, let the agent decide the research path.”transcript, stated

Use low-level orchestration rather than opaque agent abstractions.

Chose LangGraph-style nodes, edges, state, checkpointing, and state management over high-level import-agent abstractions.

Rationale: Low-level primitives are easier to tear down and recombine as assumptions change.

“if I was building for example you know open research with an with an abstraction I wouldn't necessarily know how to rip it apart and rebuild it”transcript, stated

Cache repeated message history where possible but still reduce context.

Chose provider prompt caching plus explicit context management over treating caching as a substitute for context engineering.

Rationale: Caching helps latency and cost, but long-context failure modes remain.

“It absolutely helps you with latency and cost. >> Yeah, I I I do think I do wonder what else can be cached.”transcript, stated
“I do think an important and subtle point here is that caching doesn't solve the long context problem. So, it of course solves the problem of like latency and cost.”transcript, stated

Gotchas (what bit them)

Naive tool-call accumulation made deep research expensive and context-heavy.

Root cause: Each token-heavy tool result was pushed back into the model context at every turn.

Resolution: Offload raw observations, summarize what is available, and retrieve the raw context on demand.

“with a naive tool calling loop was using 500,000 tokens. It was like a dollar to $2 per run.”transcript, stated
“You're saving it in externalized system. You're fetching it as needed. This saves token cost significantly.”transcript, stated

Compaction and pruning can erase important evidence.

Root cause: Summaries are lossy, and irreversible pruning removes the raw context needed to recover.

Resolution: Keep raw tool outputs in an offload store while passing compact summaries back to the model.

“you have to be careful about information loss uh this is something that people do disagree on”transcript, stated
“they always use a file system to offload things so they can retrieve it.”transcript, stated

Multi-agent designs can conflict when subagents make write decisions independently.

Root cause: Subagents implicitly make decisions without enough communication, producing coordination conflicts.

Resolution: Use subagents for parallel read-only context gathering and perform final writing in one step.

“each sub aent implicitly makes decisions and those decisions can conflict.”transcript, stated
“with research you're just doing context gathering in each of those sub aent steps and you're writing in a single step.”transcript, stated

Useful structure can become a bottleneck as models improve.

Root cause: The early workflow encoded assumptions about research and tool reliability that stopped fitting newer models.

Resolution: Continuously reassess scaffolding and remove structure that blocks improved model capabilities.

“I was completely bottlenecked as models got better. I had to rip out the entire system and rebuild it twice”transcript, stated
“adding structure necessary to get things to work today, but keeping an eye on improving models”transcript, stated

Caching reduces cost but does not solve long-context quality degradation.

Root cause: Even cached tokens remain part of the model's long context, so context rot can still apply.

Resolution: Use caching for latency/cost, but still manage context length and relevance explicitly.

“caching doesn't solve the long context problem. So, it of course solves the problem of like latency and cost.”transcript, stated
“caching shouldn't actually help you with all the context rot and long context problems.”transcript, stated

High-level agent abstractions can make the system hard to rebuild.

Root cause: Opaque abstractions hide what is under the hood, which is risky while agent designs are still immature.

Resolution: Prefer low-level orchestration building blocks such as nodes, edges, state, checkpointing, and state management.

“agent abstractions are problematic because you don't know what's necessar under the hood of the abstraction”transcript, stated
“I don't hate low-level orchestration frameworks that just provide nodes, edges, you can just recombine them in any way you want.”transcript, stated

Evaluation

The discussion references iterative development over a year, Deep Research Bench performance, and empirical costs/tokens from naive tool-calling runs, but does not describe a formal release gate or benchmark protocol in the transcript.

Metrics: 500,000 tokens in naive runs · $1 to $2 per naive run · typical agent workloads of 50 to hundreds of tool calls · best-performing open-source deep research assistant on Deep Research Bench

“it's now according to deep research bench the best performing uh deep research agent um at least on that particular benchmark.”transcript, stated
“the thing that's at least on deep research it's the best performing open deep research assistant at least that that's open source”transcript, stated

Outcomes

The system was developed across roughly a year, after naive deep-research runs reached about 500,000 tokens and one to two dollars per run.

“So I ripped out the independent writing and did a oneshot writing at the end and this is the current kind of version of open deep research”transcript, stated
“I started with a system that was very reliable for the current state of models back in mid 2024, early 2024”transcript, stated