Multi-Agent Systems¶
This is a hub page on multi-agent AI systems — when to use them, the open protocols that hold them together, and the canonical four-agent reference architecture (LangGraph + MCP + A2A + a local LLM) documented in Sandeep Bharadwaj Mannapur's April 2026 FreeCodeCamp book How to Build a Multi-Agent AI System with LangGraph, MCP, and A2A. The architectural reasoning here is the substantive content; the specific tutorial code is just one concrete instantiation of it.
What a multi-agent system is¶
A multi-agent system is one where several specialised AI agents coordinate to do work that one agent on its own would do badly or not at all. The most important question — and the one the FreeCodeCamp book opens with — is whether the problem actually justifies multiple agents in the first place.
A single agent with good tools is usually simpler, faster, and more reliable. Adding agents means more moving parts, more failure points, shared state that can be corrupted from multiple directions, and debugging that crosses process boundaries. So the question is not "should I use multi-agent?" but "does my problem have characteristics that justify the coordination overhead?" (Mannapur, FreeCodeCamp).
When a single agent is the right answer¶
A single agent fits when the problem has one primary job that fits in one context window: research-and-summarise, review-a-pull-request-and-comment, answer-from-a-knowledge-base, extract-structured-data-from-a-document. Adding a second agent in those cases just buys you a coordination layer, a shared-state contract, and more failure modes for no architectural benefit.
When multiple agents are warranted¶
The book identifies six conditions; the more of them apply, the stronger the case for separation:
- Different tools for different subtasks — one part needs filesystem, another needs database writes, another calls an external API. Natural seams for separation.
- Different LLM call patterns — one task is a single structured output at temperature 0, another is a multi-turn tool-calling loop that the LLM ends when it has enough context. Mixing these in one agent creates a function that fails in different ways depending on which path executes.
- Different temperature / model requirements — structured planning wants low temp, creative explanation slightly higher, grading low again. One agent with one setting compromises everywhere.
- Fault isolation — if one subtask can fail without taking the others down, you need a process boundary.
- Independent deployment — different update cadences, different scales, different teams or frameworks. Agent separation maps to deployment separation.
- Cross-framework collaboration — if a CrewAI agent is best for one job and a LangGraph agent for another, you need a protocol for them to talk: that is A2A.
Two of these probably justify the cost. All of them make a strong case.
The cost you are paying¶
Be explicit about what multi-agent buys you, because it isn't free:
- Shared-state complexity — every agent reads and writes a shared state object; changes to the schema cascade through every agent.
- Harder debugging — a failure might be caused by bad output from three steps earlier, persisted into state, passed to a second agent.
- Latency multiplication — every agent is at least one LLM call. Four agents is at least four sequential calls per session, more when tool loops are involved.
- Required infrastructure — checkpointing, observability, evaluation, and human oversight are nice-to-haves for single agents and required for multi-agent systems in production.
The reference architecture¶
The book uses a "Learning Accelerator" — a four-agent system that plans study roadmaps, explains topics from your own notes, runs quizzes, and adapts — as a teaching vehicle. The use case is incidental; the architecture is the real subject and is reused in production today for sales enablement, compliance training, customer support, and engineering onboarding.
The technology stack¶
| Layer | Tech | Version | Role |
|---|---|---|---|
| Orchestration | LangGraph | 1.1.0 | Stateful multi-agent graph; SQLite-checkpointed shared state survives crashes |
| Agent ↔ Tool | MCP | 1.26.0 | Standardised tool protocol (filesystem, notes, memory) |
| Agent ↔ Agent | A2A SDK | 0.3.25 | Cross-framework delegation between LangGraph and CrewAI agents |
| Cross-framework agent | CrewAI | 1.13.0 | Served via A2A to demonstrate framework-independent coordination |
| Inference | Ollama | latest | Local LLM (qwen2.5:7b min; qwen2.5-coder:32b recommended for reliable tool calling) |
| Observability | Langfuse | 4.0.1 | Distributed tracing across agent boundaries |
| Evaluation | DeepEval | 3.9.1 | LLM-as-judge quality checks |
A model-size note worth flagging: agents call tools by generating structured JSON arguments, and models under ~7B parameters produce JSON-format errors frequently. The agent then loops without a clear error and hits the iteration cap. The book treats the 7–9B range as the minimum viable tier for reliable tool calling in production.
The four-agent pattern¶
Four agents are used not because four is virtuous but because the four tasks are different enough that combining any two would make the combined agent worse at both:
| Agent | Job | Why separate |
|---|---|---|
| Curriculum Planner | Goal → structured study roadmap | Single LLM call, temp 0.1, JSON output, zero tools. Mixing tool-calling would add noise to structured output. |
| Explainer | Reads source notes via MCP, explains topics | Multi-turn tool-calling loop, temp 0.3. Loop count non-deterministic — LLM decides when it has enough context. Completely different execution pattern from Planner. |
| Quiz Generator | Generates questions (creative, temp 0.4) then grades answers (analytical, temp 0.1) | Two LLM calls with different temperatures. Interactive: pauses for user input. Also runs as a standalone A2A service so other systems can call it. |
| Progress Coach | Synthesises results, updates topic status, routes next | The coordinator. Makes the only cross-framework A2A call (to a CrewAI Study Buddy). Reads/writes MCP memory. Owns the routing decision. |
Stateful orchestration with LangGraph¶
LangGraph models a multi-agent workflow as a directed graph. Nodes are Python functions (the agent code); edges define routing. Every node reads from and writes to a shared state object, and LangGraph checkpoints that state to SQLite after every node runs. That last point is what separates it from a naïve for-loop: the checkpoint survives a crash, and graph.invoke() with the same session ID picks up exactly where it left off. Each node returns a partial update with only the keys it changed; LangGraph merges and saves before calling the next node.
Standardised tool access with MCP¶
Rather than wiring every tool integration by hand, agents access tools through MCP servers. The pattern is exactly the standard one: the agent is the MCP client, each tool category is an MCP server. In the book, two MCP servers expose the notes filesystem and the agent memory store.
Cross-framework coordination with A2A¶
The Progress Coach makes a delegation call out to a CrewAI Study Buddy — a different framework entirely — over A2A. The point of the chapter is not the specific call but the principle: when frameworks differ, the protocol is the integration. (For deeper detail on A2A see a2a-protocol.)
Observability and evaluation are not optional¶
Two layers that single-agent systems can usually skip but multi-agent systems must include:
- Langfuse captures distributed traces that follow execution across agent boundaries — so when the failure surface crosses three nodes, you can actually see where the bad output originated.
- DeepEval runs LLM-as-judge automated quality checks against agent output so you have a signal when output quality is degrading before users notice.
How this hub relates to other pages¶
- a2a-protocol — the open standard for cross-framework, cross-vendor agent-to-agent calls. Multi-agent systems that span teams or vendors will use A2A as the integration layer.
- mcp — the open standard for agent-to-tool integration that every agent in the reference system uses.
- claude-agents / claude-agents-managed — Anthropic-specific framing of how agents are authored and managed.
- azure-foundry-hosted-agents — Microsoft's managed-agent equivalent; you can host individual agents in Foundry and still wire them together with A2A.
Limitations¶
- Tutorial-as-source. The primary citation here is a single book-length tutorial. The architectural reasoning is well-argued and matches the public protocol specifications (LangGraph, MCP, A2A) but specific performance numbers and "this pattern is in production today for X" claims are author-attested, not independently audited.
- Stack assumptions. The reference architecture pins specific versions (LangGraph 1.1.0, langchain-core 1.0.0, a2a-sdk 0.3.25, CrewAI 1.13.0) with an explicit warning not to upgrade because of breaking changes between minor versions. That fragility is a property of the current agent-framework ecosystem, not of multi-agent systems in general.
- Local-LLM caveats. Ollama with qwen2.5:7b is sufficient for the teaching vehicle; production deployments with stricter SLOs may need larger models or hosted inference, which changes cost and latency profiles meaningfully.
- No live benchmarks in source. The tutorial does not include side-by-side benchmarks of single-agent vs. multi-agent for the same task. The "when to split" criteria are sound principles but quantitative thresholds are not provided.
Sources¶
- Sandeep Bharadwaj Mannapur, "How to Build a Multi-Agent AI System with LangGraph, MCP, and A2A [Full Book]", FreeCodeCamp, 30 April 2026 — full ready-to-run repository on GitHub linked from the post.
Changelog¶
2026-05-18 — Page created from https://www.freecodecamp.org/news/how-to-build-a-multi-agent-ai-system-with-langgraph-mcp-and-a2a-full-book/ (Type T, confidence 70). Decided to create a hub page rather than an idea file or just absorbing into a2a-protocol/mcp: the tutorial's substantive value is the architectural reasoning (when to split agents, the four-agent pattern, observability requirements), which is general multi-agent knowledge worth its own page. The specific Learning Accelerator code is treated as one instantiation, not the subject. Hub page can later be extended with spoke pages on individual frameworks (langgraph.md, crewai.md) without restructuring.