Deep research with LangGraph: a production setup

The gap between a working notebook and a production-grade automated research agent is almost always an architecture problem, not a model problem. LangGraph deep research pipelines expose this gap quickly: a chain that works for five queries breaks on the sixth because state piles up, search tools time out, and token budgets explode past early estimates. The graph abstraction exists precisely to manage these failure modes systematically. What follows covers the design decisions that determine whether your agentic research pipeline ships once and stays reliable, or ships once and gets quietly disabled two weeks later.

What a langgraph deep research loop actually does

A langgraph deep research agent does not run a single prompt. It runs a state machine with three distinct phases: decomposition, retrieval, and synthesis. Each phase maps to a node in the graph (conditional edges decide when to loop back for another retrieval pass and when to proceed to synthesis).

A concrete run looks like this. The planner node receives a research question and produces three to five sub-questions. Each sub-question goes to the researcher node, which executes a search query and appends results to a shared list field in the state object. The writer node reads the accumulated results and produces a draft. If the draft confidence score falls below a threshold, or if a required sub-topic has no coverage, the graph routes back to the researcher node rather than returning the draft to the caller.

A typical run completes three to five search iterations. Token consumption depends on result verbosity and synthesis depth: expect 150,000 to 400,000 tokens per research question for a thorough run. At GPT-4o input pricing (roughly $2.50 per million tokens as of mid-2025), that puts model costs at $0.40 to $1.00 per question, not counting search API fees. This number matters at design time, not just at billing time, because it constrains how many sub-questions the planner should generate by default.

The routing logic is what earns LangGraph its place here over a simple for-loop. Conditional edges let you express branching decisions (retry this sub-topic, skip this branch, escalate to a different retrieval strategy) without tangling that logic into node code.

The open_deep_research reference architecture

The langchain-ai/open_deep_research repository, released on July 16, 2025, is the most complete public blueprint for a production AI research workflow. Reading it as a reference is worthwhile even if your project diverges from it, because the design decisions are explicit and the code comments explain the reasoning.

Graph topology: planner, researcher, writer

The reference graph has three primary nodes. The planner takes the input question and generates a research plan as a list of sub-questions stored in state. The researcher executes search calls against a configurable backend and appends results to a list field in state. The writer consumes all accumulated results and produces the final output.

MCP server support was added in Q3 2025, making it possible to swap search backends at runtime without rewriting node logic. This is useful when your agentic research pipeline needs to support both a Tavily-based run and a local Bing Search API run from the same graph definition, with the backend injected as a configuration parameter at instantiation time.

What the reference repo intentionally omits

Open_deep_research does not include output formatting beyond plain text, citation deduplication, or result caching. These are deliberate omissions: the repo is a blueprint, not a complete product. Deduplication in particular is worth adding early in your fork. The same URL frequently appears across multiple sub-question search results, inflating the token count passed to the writer node without adding information.

State schema: the contract that holds the graph together

The state schema is the central engineering decision in a research automation system. It defines the contract between every node. If the schema drifts between a node that writes and a node that reads, you get silent data loss, not a traceable error.

A minimal five-field schema for a research agent:

from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph.message import add_messages

class ResearchState(TypedDict):
    query: str
    sub_questions: list[str]
    search_results: Annotated[list[dict], add_messages]
    draft: str
    iteration_count: int

The Annotated type on search_results with add_messages as the reducer is the key detail. Without a reducer, parallel branches that each append to the same list will overwrite each other. LangGraph's reducer pattern merges concurrent writes correctly, making parallel sub-question retrieval safe without any coordination code in your nodes.

Define the schema before writing any node code. Changing it after nodes exist is possible but expensive, because every node signature depends on it. Treat it the same way you would treat a database schema change in a production system.

Search tool integration: Tavily, Serper, and MCP backends

Three search backends cover most production scenarios for multi-step web research.

Tavily is purpose-built for LLM research agents and returns pre-processed snippets rather than raw HTML. The free tier caps at 1,000 searches per month. The Pro plan runs around $50/month for 100,000 searches. Five search calls per research run at Tavily Pro is negligible cost per run; at 1,000 runs per month, search API spend reaches $25-$50/month, which can equal or exceed model costs for short, focused questions.

Serper proxies Google Search results at $0.30 per 1,000 queries on the base plan. It is cheaper per query than Tavily Pro and gives access to Google's index, but it returns raw SERP snippets that require more prompt engineering to use reliably in a synthesis step.

The Bing Search API remains a viable option for teams already in the Azure ecosystem, with a free tier at 1,000 transactions per month and pay-as-you-go pricing of $3-$7 per 1,000 queries depending on tier.

When your autonomous research bot needs to support more than one provider, the MCP integration pattern in open_deep_research is the correct approach: node code stays identical, the backend is injected as configuration. This avoids conditional branching inside node logic, which becomes unmaintainable past two providers.

Reliability in production: retries, token budgets, and observability

Three failure modes appear repeatedly once a research automation system leaves the notebook. Understanding them upfront reduces debugging time significantly.

Search tool timeouts are the most frequent. Handle them with exponential backoff capped at three retries. If all retries fail for a sub-question, write an empty result to state and let the writer node handle partial coverage explicitly, rather than letting the exception propagate and halt the graph.

Context window exhaustion happens when search results accumulate across many iterations and the full state exceeds the model's context limit before the writer node runs. The fix is a rolling window on search_results: keep the N most recent or most relevant results before constructing the writer prompt. Implement this as a utility function called at the start of the writer node, not scattered across node code.

Infinite loops are addressed by a hard max_iterations cap. The open_deep_research repo defaults to 5 as of mid-2025. Treat this as a hard guard in code, not a configuration value that operators might forget to set or might raise to an unreasonable number.

The 2026 operational baseline shifts this picture in one concrete way: LangGraph's built-in persistence layer, checkpointing to Postgres or Redis, makes mid-run recovery practical without custom state serialization code. A run that fails at iteration 4 can resume from iteration 3's checkpoint rather than restarting from the planner node. This was an advanced pattern requiring manual implementation in 2024; in 2026 it is the expected default for any agent running longer than thirty seconds.

LangSmith tracing provides per-node latency breakdowns and token counts without instrumentation overhead. Wire it in before your first production run. The cost visibility alone, showing which node consumes the majority of tokens on a given question type, informs schema and prompt decisions that are otherwise guesses.

Actually, let me be more direct about the tracing part: you will regret not setting it up early. I've seen too many teams scramble to add observability after their agent starts burning through their API budget with no visibility into which component is the culprit 💸

Key takeaways

Four decisions separate a fragile langgraph deep research demo from a maintainable production agent: define the state schema before writing any node code; treat max_iterations as a hard cap in code rather than a soft default; account for search API costs at design time, not at billing time; and connect LangSmith observability before the first real run. The graph abstraction earns its complexity only when state, retries, and token budgets are treated as first-class constraints from the first commit, not retrofitted after the demo breaks under load.

---

LangGraph deep research agents fail when state piles up and search loops break on the sixth query. The production CLAUDE.md template in the kit shows how to cap iterations, structure agent rules, and document the stack cost before your pipeline gets quietly disabled.

→ Get the welcome kit