Skip to main content
18 min read

Multi-agent orchestration with LangGraph

Part 5: Parallel specialist workers, shared state, and a reviewer that reconciles their findings.

👉

Recap

Part 4 turned the agent into a verified loop.

A planner writes a checklist into state. The Part 3 agent works through it one item at a time, with every harness control still in force. A separate verifier decides whether each item is done. Budgets guarantee that every run ends with a report.

Part 4 also ended with three limitations:

  • The first being the serial limit. Three items that do not depend on each other, but wait for the one before each of them.
  • The second is the generalist limit. One executor does every kind of work.
  • The third is the reconciliation limit. A final report lists verified findings, but nothing reconciles them.

This part fixes those three limits. The investigation becomes a team. An intake step routes the question, then specialist workers run in parallel. Each worker has only the read tools for its own source. A reviewer that did not do the investigation reconciles the findings. No worker can reach a write tool, and the report explains how the findings fit together.

Prerequisites: Parts 1 to 4 of this series. You can read them below:

First Steps Towards a Production-Ready Agent with LangChain
Part 1: Tools, structured output, runtime context, and tracing, in one small agent.
Middleware-Driven Context Engineering in LangChain
Part 2: Dynamic prompts, memory, compression, and isolation with middleware
Agent Harness with LangChain Middleware and Jev
Part 3: Retries, fallbacks, routing, guardrails, permissions, and the first human-in-the-loop interrupt.
Planning and Verification Loops with LangGraph and Jev
Part 4: Plans, independent verification, stuck detection, budgets, and loops that stop when the task is done.

When one agent stops being enough

Adding agents is not an automatic upgrade. Anthropic's guidance is blunt. Anthropic's January 2026 post on multi-agent systems explains that teams spend months building elaborate architectures, only to find that better prompting on one agent worked just as well.

The same post identifies three cases where multiple agents consistently do better:

  • Context protection: One subtask would fill the context with material the next subtask does not need.
  • Parallel work: The task splits into independent pieces that can run at the same time.
  • Specialization: Different parts of the task need different tools or instructions.

Our investigation meets all three conditions. Logs, source code/configuration, and incident history live in separate systems. Each source can be checked independently and mostly requires different tools.

👉
Split work by context, not by job title. Anthropic warns against dividing one task among a planner, implementer, and reviewer because every handoff loses context. Instead, split along boundaries where context can be isolated. Logs, config, and incidents provide those boundaries. Each worker can do its job without the others' context.

Where this sits among multi-agent patterns

LangChain itself documents several multi-agent patterns. This part builds a router.

👉
This is not the model router from Part 3. That one picks a model for each call; this one picks which agents work on a question.

A routing step classifies the input, dispatches it to specialized agents in parallel with Send, and combines their results.

The docs contrast a router with the subagents pattern, in which a supervisor decides which subagents to call as tools during a conversation. Use a router for clear input categories and deterministic dispatch. Use a supervisor for open-ended work where a model must choose the next step.

Two multi-agent patterns side by side. Left, the router pattern: an input goes into a classifying router node, which dispatches in parallel via Send to specialized agents, feeding into a synthesize node, labeled for clear input categories and deterministic dispatch. Right, the subagents pattern: a supervisor agent in a loop, calling subagents as tools during an open-ended conversation, labeled for open-ended orchestration where a model chooses the next step.

Note on the reference project:

The code and project setup are attached below as a zip file. Extract it and run uv sync to get going.

Download the zip file below:

Published on Oct 11, 2026