Hands-On: Build a Multi-Step Research Agent with LangGraph

"Research X for me and give me a report." This kind of task cannot be solved by single-pass RAG because the knowledge base may not contain the answer. It requires an agent to autonomously perform multi-step searches of external information and synthesize its findings. This is one of the most valuable agent use cases and one that best demonstrates "autonomy."

This article uses LangGraph to build a research agent and turns "open-ended research" into an engineered process.

1. How a Research Agent Differs from Ordinary RAG

Ordinary RAG: one retrieval step + one generation step, suitable for "specific questions that can be answered from the knowledge base."

A research agent is multi-round and autonomous: it must decide what to search for, whether it has enough information, whether to try different keywords, and how to synthesize information from multiple sources into a final report. For example, to "compare the strengths and weaknesses of frameworks A and B," it must research A, research B, search for direct comparisons, and then synthesize the results.

The core capability chain is:

Question → decompose into subquestions → parallel retrieval (search + full-text reading) → evaluate (enough?) →
       (not enough) search again → (enough) synthesize into a report

2. Drawing the State Graph with LangGraph

LangGraph's "state graph" model is particularly well suited to this kind of multi-step workflow. Start by defining the state:

import { StateGraph, Annotation } from "@langchain/langgraph";

const ResearchState = Annotation.Root({
  question: Annotation<string>,            // Original question
  subQuestions: Annotation<string[]>,       // Decomposed subquestions
  findings: Annotation<Doc[]>(              // Collected research material
    { reducer: (a, b) => dedup([...a, ...b]), default: () => [] }
  ),
  drafts: Annotation<string[]>,             // Interim answers to each subquestion
  report: Annotation<string>,               // Final report
  steps: Annotation<number>({ default: () => 0 }),  // Step count (prevents runaway execution)
});

findings uses a reducer to deduplicate and merge results. Multiple retrieval nodes can add results in parallel, and the reducer automatically merges and deduplicates them.

Then draw the graph:

plan → search (parallel) → reflect → (not enough) search / (enough) write → END

const graph = new StateGraph(ResearchState)
  .addNode("plan", planNode)          // Decompose into subquestions
  .addNode("search", searchNode)      // Retrieve results (supports parallel fan-out)
  .addNode("reflect", reflectNode)    // Evaluate: Is there enough information? What is missing?
  .addNode("write", writeNode)        // Synthesize the report
  .addEdge(START, "plan")
  .addEdge("plan", "search")
  .addEdge("search", "reflect")
  .addConditionalEdges("reflect", (s) =>
    s.steps >= 5 || enough(s) ? "write" : "search"  // Enough information or hard cap reached → write report
  )
  .addEdge("write", END);

3. Designing Each Node

plan (decompose the question): One LLM call breaks a broad question into 3–5 subquestions that can be researched independently.

Input: "Compare the strengths and weaknesses of Qwen and Llama in Chinese-language use cases"
Output: ["Qwen Chinese-language capability benchmarks", "Llama Chinese-language capabilities", "Qwen vs. Llama comparisons", "..."]

search (retrieve): For each subquestion, call a search tool such as a web search API and retrieve the summaries and URLs of the top results. The key is to search for each subquestion independently instead of using one vague query to search for everything.

read (read full text, optional): For highly relevant search results, fetch the full text, split it into chunks, and extract key points. This is where research quality diverges sharply: research based only on search snippets is shallow, while reading the full text reveals the details.

reflect (evaluate): This is the "brain" of the research agent. One LLM call examines the current findings and determines:

• Is there enough information to answer the original question?
• Are there obvious gaps, such as a subquestion with no useful results?
• Should it search again, and with which new keywords?

The output of reflect determines whether to "continue to search or proceed to write." This node determines the quality of the research. When it works well, the agent autonomously fills gaps. When it works poorly, the agent either writes the report too early, producing shallow results, or enters an endless search loop.

write (synthesize): Synthesize the findings into a structured report that answers the original question, with citations. Every conclusion should identify its source URL. A research agent without citations is not trustworthy.

4. Controls: Keep It from Running Away

The most common problem with research agents is a search loop that never finishes, because reflect always decides that the information is "not enough." Control it with:

1. A hard cap: steps >= 5 forces the workflow to stop searching and proceed to write. A research agent without a cap will search forever.
2. Explicit criteria for reflect: "If every subquestion has ≥2 credible sources, there is enough information." Do not let it decide solely by intuition.
3. Budget constraints: Set limits on total searches and total tokens, and wrap up when either limit is reached.

Whether a research agent has "enough" information is subjective. You must constrain it with explicit criteria and a hard cap.

5. Quality Hinges on Reflect and Citations

Seventy percent of a research agent's quality comes from the reflect node. A poor reflect node:

• Stops too early, producing a shallow report that omits important aspects.
• Never stops, causing an expensive infinite loop.

Tune the reflect prompt by specifying clear criteria for "enough," requiring it to state "what is still missing," and making it aware of the maximum step count.

The other key to quality is citations. The write node must require every conclusion to cite its source. Research-agent output is used to make decisions, and conclusions without citations cannot be trusted. A research report with citations is ten times more valuable as a review.

6. Engineering Considerations

• Choosing a search tool: Use an API that returns page content or summaries, such as Tavily or Brave Search API, rather than one that returns only links. The agent needs to read the content, not just the URL.
• Caching: Cache retrieval results for each subquestion, because research workflows often repeat similar queries.
• Streaming: Stream the final write output so users can read while they wait. One research-agent run can take tens of seconds, and having the entire process remain a black box is frustrating.
• Trace: Record the inputs and outputs of every node—plan, search, reflect, and write—in a trace. When research quality suffers, the trace shows where the problem occurred: "Did plan decompose the question incorrectly, or did reflect stop too early?"

Summary

A research agent is a concentrated expression of agent autonomy: decompose the question → perform multi-step retrieval → self-evaluate → fill gaps → synthesize a report. LangGraph's state graph makes the process clear: nodes represent stages, edges represent control flow, and reflect is the brain.

Remember four rules:

1. Use plan to decompose the question well, then search for each part in parallel.
2. Reflect is the key to quality; give it explicit criteria for "enough."
3. Use a hard cap + budget to prevent infinite loops.
4. Include citations; research output without citations has no value.

Once this system is in place, your agent can perform high-value "open-ended research" tasks that single-pass RAG cannot handle. This is the most irreplaceable advantage agents have over traditional retrieval.