What if your AI research assistant didn't just retrieve information, but actually thought about what it needed to know, stopped to ask you when a topic was ambiguous, and only started searching once it had a clear direction? That's the core idea behind this project: a multi-agent deep research system built with LangGraph, running entirely on open-source models through LM Studio, with full execution observability through Langfuse.
The system demonstrates four patterns I believe every serious AI developer needs in their toolkit: multi-agent orchestration, the human interrupt pattern, agent observability, and clean context management per agent. Each one is a deliberate architectural decision, not an incidental detail. Let me walk through each.
<hr>
<h2>Why Multi-Agent Instead of One Big Prompt?</h2>
The naive approach to a research assistant is a single LLM call with a long system prompt asking it to search, analyze, and write simultaneously. This breaks down quickly. The model has to context-switch between strategic thinking, search execution, and synthesis, while the context window accumulates a growing pile of intermediate reasoning, search results, and half-formed conclusions.
Multi-agent systems solve this by giving each concern its own agent with its own focus and its own context. This project uses four specialized nodes in a LangGraph <code>StateGraph</code>:
<ul>
<li>Strategist: Analyzes the topic, typically does 1-2 reconnaissance searches if the topic is unfamiliar, then either asks for clarification or produces a structured research plan</li>
<li>Human Interrupt: A dedicated pause point where user input can reshape the strategy before any real research begins</li>
<li>Researcher: Executes the plan through targeted Tavily searches, iterating until it self-assesses that information is sufficient</li>
<li>Writer: Synthesizes all findings into a structured Markdown report with numbered source citations</li>
</ul>
The execution flow:
<pre><code>User Input -&gt; Strategist -&gt; [Human Interrupt?] -&gt; Researcher (1-N iterations) -&gt; Writer -&gt; Report
</code></pre>
Each agent hands off a structured signal to the next rather than raw text. The Strategist outputs either <code>ASK_USER: &lt;question&gt;</code> or <code>PLAN: &lt;numbered queries&gt;</code>. The Researcher outputs either <code>SUFFICIENT: &lt;assessment&gt;</code> or <code>CONTINUE: &lt;what's missing&gt;</code>. These explicit prefix strings make routing deterministic - the graph checks for known signal words in the output rather than asking the LLM to decide where to go next.
<hr>
<h2>The Human Interrupt Pattern</h2>
The most interesting node in the graph isn't an LLM agent - it's a pause.
LangGraph supports interrupting graph execution before a named node using <code>interrupt_before</code>. When the graph is compiled with this option, execution halts at that checkpoint and waits. The state is fully persisted in a <code>MemorySaver</code> checkpointer, so the graph can resume exactly where it left off after collecting user input:
<pre><code class="language-python">app = graph.compile(
 checkpointer=MemorySaver(),
 interrupt_before=["human_interrupt"]
)
</code></pre>
In the main control loop, after each <code>invoke()</code> call, the code inspects whether the graph paused at the interrupt node:
<pre><code class="language-python">while True:
 result = app.invoke(current_state, config)
 state_snapshot = app.get_state(config)

 if state_snapshot.next and "human_interrupt" in state_snapshot.next:
 # Extract the strategist's clarifying question
 question = result["strategist_messages"][-1].content
 print(f"\n❓ Clarification needed:\n{question}")
 clarification = input("Your answer: ").strip()

 # Pass clarification back into the next invoke
 current_state = {"clarification": clarification}
 continue

 break
</code></pre>
In the run shown below, the strategist identified that "Microsoft Agentic Framework" was an ambiguous topic. There's a newly released SDK, but what aspect does the user actually care about? It generated five focused options (architecture, comparisons, implementation guide, enterprise use cases, Microsoft 365 integration), paused, and waited. The user selected "Comparison with alternatives", and the strategist immediately produced a targeted research plan for that specific angle.
<img alt="Terminal output showing the Deep Research Agent startup with Langfuse tracing enabled, the strategist doing a reconnaissance search, the clarification prompt with five numbered options, the user selecting &quot;Comparison with alternatives&quot;, and the plan being created before routing to the researcher" src="/assets/blog/images/deep-research-multiagent-langgraph-3.png">
This pattern is powerful beyond research assistants. The same mechanism applies to any agentic workflow where a step requires human approval: content before publishing, a query before executing a database write, a plan before running infrastructure changes. The graph pauses, waits, and resumes with state intact.
<hr>
<h2>The Researcher: Autonomous Iteration With a Safety Budget</h2>
The researcher is a tool-calling agent that receives the strategist's plan and executes Tavily searches to gather information. After each batch of searches, it self-assesses whether it has enough to write a comprehensive report. If not, it generates new search queries targeting gaps in its current knowledge.
What prevents infinite loops is a hard iteration counter in the shared state:
<pre><code class="language-python">def should_continue_research(state: AgentState) -&gt; str:
 iterations = state.get("researcher_iterations", 0)
 max_iterations = state.get("max_researcher_iterations", 10)

 if iterations &gt;= max_iterations:
 return "writer" # Safety exit regardless of assessment

 last_message = state["researcher_messages"][-1].content.lower()

 if "sufficient" in last_message:
 return "writer"
 elif "continue" in last_message:
 return "researcher"

 # Fallback: unclear output, keep researching
 return "researcher"
</code></pre>
In the run shown here, the researcher iterated five times before declaring sufficiency, visible in the Langfuse trace as <code>researcher (5/5)</code>. Each iteration deepened the comparison between Microsoft's framework and the alternatives: LangChain, AutoGen, CrewAI, and n8n. The first four iterations produced progressively more targeted searches, but the researcher kept finding specific dimensions (security compliance, streaming architecture, RAG pipelines) worth investigating further before committing to the writer.
This kind of self-directed iteration is what separates a research agent from a single web search with an LLM summary.
<img alt="Terminal output showing researcher iterations 3 through 5, the SUFFICIENT signal from the model, routing to the writer, and the beginning of the formatted research report rendered in the Rich panel" src="/assets/blog/images/deep-research-multiagent-langgraph-2.png">
<hr>
<h2>Agent Observability With Langfuse</h2>
Running a multi-agent pipeline without observability is flying blind. Print statements tell you what happened but not why a specific call took 15 seconds, what the model actually received as input, or where your token budget was spent. Langfuse solves this by giving every LLM call a structured home in a trace hierarchy.
The integration is a single callback handler passed to LangGraph at invocation:
<pre><code class="language-python">from langfuse.langchain import CallbackHandler

langfuse_handler = CallbackHandler(
 public_key=os.getenv("LANGFUSE_PUBLIC_KEY"),
 secret_key=os.getenv("LANGFUSE_SECRET_KEY"),
 host=os.getenv("LANGFUSE_HOST")
)

result = app.invoke(
 current_state,
 config={
 "configurable": {"thread_id": thread_id},
 "callbacks": [langfuse_handler]
 }
)
</code></pre>
Because LangGraph reports its execution structure to LangChain callbacks, Langfuse automatically reconstructs the full trace hierarchy: a top-level <code>LangGraph</code> span, then named spans for <code>strategist</code>, <code>researcher</code>, and <code>writer</code>, each containing their nested <code>ChatOpenAI</code> calls with exact input prompts, output text, token counts, and latency.
<img alt="Langfuse observability dashboard showing the full LangGraph execution trace with strategist, researcher (5/5 iterations) and writer spans, the graph visualization, and exact model parameters including token counts" src="/assets/blog/images/deep-research-multiagent-langgraph-1.png">
What Langfuse reveals that terminal logs cannot: the researcher's 15-second span broken into five sub-iterations, each with distinct input context and tool call outputs. When an iteration fails to produce a clear sufficiency signal, you can inspect exactly what the model received and understand why it continued rather than declared completion. This is the difference between debugging and guessing.
<hr>
<h2>Clean Context Per Agent: The Relay Race Pattern</h2>
The most common failure mode in multi-agent systems isn't bad prompts - it's a polluted context window. When all agents share a single message history, each subsequent agent inherits the full internal monologue of every agent before it: strategist reasoning, raw search results, draft plans. Models struggle with this overloaded context, token costs scale with every agent added, and output quality degrades as the model tries to navigate an increasingly irrelevant history.
This project takes the opposite approach. Each agent maintains its own isolated message list in the <code>AgentState</code>:
<pre><code class="language-python">class AgentState(TypedDict):
 # Structured data passed between agents
 topic: str
 clarification: str
 plan: str
 findings: List[Dict]
 final_report: str

 # Separate conversation context per agent
 strategist_messages: Annotated[List[BaseMessage], add_messages]
 researcher_messages: Annotated[List[BaseMessage], add_messages]
 writer_messages: Annotated[List[BaseMessage], add_messages]
</code></pre>
The strategist only sees its own conversation thread. When it produces a plan, that plan string is extracted and stored in the shared <code>plan</code> field. The researcher starts with a clean context containing only the plan and its accumulated findings. The writer receives only a formatted text of the findings - no strategist reasoning, no raw researcher dialogue.
Think of it as a relay race: each runner carries the baton (structured data) from the previous stage, but runs their own race from a clean starting position. No runner sees the others' internal monologue. The practical effects are measurable: each agent token budget is spent on its own task rather than on irrelevant history, and each agent produces sharper output because it isn't reasoning around artifacts from previous stages.
<hr>
<h2>Running on Open-Source Models With LM Studio</h2>
The entire system runs on Qwen3-30B-A3B-Instruct-2507, a Mixture of Experts model with 30.5 billion total parameters and approximately 3.3 billion active per token. LM Studio exposes it through an OpenAI-compatible REST API:
<pre><code class="language-python">llm = ChatOpenAI(
 base_url="http://localhost:1234/v1",
 api_key="lm-studio",
 model="qwen/qwen3-30b-a3b-2507",
 temperature=0.7,
 model_kwargs={"top_p": 0.8, "max_tokens": 65536}
)
</code></pre>
The MoE architecture delivers the reasoning capability of a 30B model at the inference cost of a much smaller one. On an M4 MacBook Pro with 48GB unified memory, this runs at 15-25 tokens per second - fast enough for interactive research sessions. No API keys for the LLM, no per-token billing, no prompts sent to external model endpoints.
The choice of Qwen3 was deliberate: its tool-calling reliability is critical for the researcher agent, which must emit structured JSON tool calls consistently across multiple iterations. Less capable models in this size range frequently fail to call tools correctly, producing free-text responses when a tool call is needed and causing the researcher loop to stall. Qwen3's strong instruction following makes this unnecessary.
<hr>
<h2>The Real Cost of Running This System</h2>
This is worth spelling out explicitly, because the number is surprisingly low.
<table>
<thead>
<tr>
<th>Component</th>
<th>Cost</th>
</tr>
</thead>
<tbody><tr>
<td>LM Studio (local inference)</td>
<td>$0 - free desktop app</td>
</tr>
<tr>
<td>Qwen3-30B-A3B model</td>
<td>$0 - open weights, download once</td>
</tr>
<tr>
<td>Langfuse (self-hosted)</td>
<td>$0 - open-source, runs locally</td>
</tr>
<tr>
<td>Tavily Search API</td>
<td>$0 - 1,000 free credits per month, no credit card required</td>
</tr>
</tbody></table>
Tavily's free tier gives you 1,000 API credits per month. A basic search costs 1 credit, and a typical research session like the one shown here - five researcher iterations with 4-6 searches each - uses roughly 20-28 credits. That's around 35-50 complete research sessions per month on the free tier before you spend a single dollar. For development, experimentation, and personal use, this is effectively unlimited.
When you need more, Tavily's pay-as-you-go rate is $0.008 per credit.
The entire stack - LLM inference, orchestration, observability, and web search - runs at zero recurring cost during normal development and light use. This is a meaningful shift from a year ago, when building a comparable system required OpenAI API credits for every LLM call and a paid search API subscription just to get started.
<hr>
<h2>What Could Be Added: Extending Agent Capabilities</h2>
The system currently gives every agent one tool: Tavily web search. But LangGraph's tool binding is additive - you can give any agent additional tools without changing the orchestration logic. This is where the architecture becomes genuinely extensible.
Some directions worth exploring:
For the Strategist: A code execution tool (Python REPL) would let the strategist run quick calculations or data analysis as part of reconnaissance - useful for topics involving statistics, benchmarks, or datasets.
For the Researcher: Beyond web search, the researcher could use:
<ul>
<li>A PDF reader (via <code>pypdf</code> or similar) to extract content from research papers directly</li>
<li>A Wikipedia tool for factual grounding on well-established topics</li>
<li>A YouTube transcript tool for conference talks and technical presentations that don't have written equivalents</li>
<li>An arXiv search tool for research topics where preprints are the primary source</li>
</ul>
For the Writer: A tool that can write the report to disk, push it to a Notion database, or send it to an email address - turning the writer from a text generator into an actor that delivers its output somewhere useful.
<pre><code class="language-python"># Example: Adding tools to the researcher
from langchain_community.tools import WikipediaQueryRun
from langchain_community.utilities import WikipediaAPIWrapper

wikipedia_tool = WikipediaQueryRun(api_wrapper=WikipediaAPIWrapper())

researcher_llm = llm.bind_tools([tavily_tool, wikipedia_tool])
</code></pre>
The point is that each agent's skill set is configurable independently. You can build a researcher that uses web search for current events and Wikipedia for historical background, without changing how the strategist or writer work. This is one of the cleaner properties of the relay race pattern - because agents are isolated, enhancing one doesn't risk breaking the others.
This extensibility is also a natural next topic: building domain-specific research agents by swapping in specialized tools. A medical research agent might use PubMed search instead of Tavily. A financial analysis agent might pull SEC filings. The orchestration layer stays identical.
<hr>
<h2>Conclusion</h2>
This project demonstrates that production patterns for agentic AI don't require proprietary APIs or managed cloud infrastructure. The combination of LangGraph for orchestration, Qwen3-30B for reasoning, Langfuse for observability, and LM Studio for local inference produces a system that can handle genuinely ambiguous research topics, iterate autonomously through multi-step searches, and deliver structured reports with citations.
The patterns here aren't research-assistant-specific:
<ul>
<li>Human interrupt scales to any workflow requiring human approval before a consequential action</li>
<li>Clean context per agent applies to any multi-stage pipeline where agents build on structured outputs from previous steps</li>
<li>Agent observability is the operational foundation that makes any multi-agent system debuggable in production</li>
</ul>
The interesting engineering challenge in multi-agent systems isn't building the agents - it's managing the information flow between them. What does each agent need to know? What should it never see? How does the system recover when an agent produces an ambiguous output? This project treats those questions as first-class design decisions, and the architecture reflects that.
<h3>Resources</h3>
<ul>
<li>LangGraph: <a href="https://langchain-ai.github.io/langgraph/">https://langchain-ai.github.io/langgraph/</a></li>
<li>Langfuse: <a href="https://langfuse.com/">https://langfuse.com/</a></li>
<li>LM Studio: <a href="https://lmstudio.ai/">https://lmstudio.ai/</a></li>
<li>Qwen3 Models: <a href="https://huggingface.co/Qwen">https://huggingface.co/Qwen</a></li>
<li>Tavily Search API: <a href="https://tavily.com/">https://tavily.com/</a></li>
<li>LangChain Callbacks: <a href="https://python.langchain.com/docs/concepts/callbacks/">https://python.langchain.com/docs/concepts/callbacks/</a></li>
</ul>

Building a local multi-agent deep research system with LangGraph, Qwen3-30B, and Langfuse observability. Covers the human interrupt pattern, clean context management, and running the full stack at zero API cost.

Building a Local Multi-Agent Research System: LangGraph, Langfuse, and Open-Source LLMs

Keywords: