Multi-Agent AI with LangGraph, MCP and A2A: An Enterprise Architecture Guide

A single AI chatbot answers questions. An agent goes further: it plans steps, calls tools, reads results and decides what to do next. A multi-agent system divides a larger job among several specialised agents that coordinate with each other. Done well, this can automate multi-step work such as processing an enquiry, preparing a quotation or triaging support tickets. Done badly, it produces expensive, unpredictable systems that are hard to debug.

This guide explains a practical multi-agent AI architecture built around three increasingly common building blocks — LangGraph for orchestration, the Model Context Protocol (MCP) for tools, and the Agent2Agent (A2A) protocol for agent interoperability — plus the memory, human approval, monitoring and cost controls that make such systems safe to run.

When Do You Actually Need Multiple Agents?

Start simple. Many tasks are handled perfectly well by one model call, or by one agent with a few tools. Multiple agents make sense when:

• the work has distinct stages that need different skills or permissions (research, drafting, checking, filing);
• you want to limit what each component can do — a drafting agent should not be able to send emails;
• different teams or vendors own different agents that must work together;
• you need clear checkpoints where a human or a validator reviews intermediate results.

If none of these apply, a multi-agent design adds cost and complexity without benefit.

Defining Agent Responsibilities

Each agent should have one clearly defined job, a short list of tools and a defined output. A typical enquiry-handling workflow might use:

Separating responsibilities this way makes each agent easier to test and limits the damage any single failure can cause.

Orchestration With LangGraph

LangGraph is an open-source library from the LangChain ecosystem for building stateful agent workflows as graphs. Each node is a step — an agent, a tool call or a plain function — and edges define what happens next, including conditional branches.

Why a graph helps:

• Explicit control flow: you can see and test every path, including loops and retries, instead of hoping a single prompt behaves.
• Shared state: a defined state object carries data between steps, so each agent works from the same facts.
• Checkpointing: state can be saved after each step, so a long-running workflow can resume after a failure.
• Interrupts: the workflow can pause at a chosen step and wait for human approval before continuing.

Two common orchestration patterns are a supervisor, where one coordinating agent decides which specialist runs next, and a fixed pipeline, where the order is defined in advance. Fixed pipelines are more predictable; use a supervisor only where the path genuinely varies.

Tools With the Model Context Protocol (MCP)

The Model Context Protocol is an open protocol, introduced by Anthropic in late 2024, that standardises how AI applications connect to tools and data. An MCP server exposes capabilities — tools that can be called, resources that can be read, and reusable prompts — and an MCP client inside the AI application discovers and uses them.

The benefit is reuse: instead of writing a custom integration for every model and every tool, you wrap a system (a CRM, a database, a document store) once as an MCP server, and any compatible agent can use it.

Practical guidance:

• Expose narrow, well-described tools ("get_customer_by_phone") rather than broad ones ("run_sql").
• Make read and write tools separate, and grant write tools only to agents that need them.
• Validate every tool input on the server side; never trust arguments generated by a model.
• Treat third-party MCP servers like any third-party code: review them before connecting them to sensitive systems.

Interoperability With A2A

MCP connects an agent to tools. The Agent2Agent (A2A) protocol, introduced by Google in 2025 and since moved to the Linux Foundation as an open project, addresses a different problem: letting agents built by different teams or vendors communicate.

In A2A, an agent publishes an Agent Card — machine-readable metadata describing what it can do and how to reach it. Another agent can then send it a task, follow the task's progress and receive results, using standard web technologies.

A2A is useful when, for example, your internal scheduling agent needs to hand a task to a partner's logistics agent. Inside a single application, plain function calls or a LangGraph graph are usually simpler. Like any young standard, A2A is evolving, so check the current specification before building on it.

Memory and Shared State

• Working state: the facts of the current task, held in the workflow's state object.
• Conversation memory: recent turns, summarised as the conversation grows to control token use.
• Long-term memory: stored facts or preferences retrieved when relevant — with clear retention limits and the ability to delete data on request.

Store as little personal data as the task needs, and never let one customer's memory leak into another customer's task.

Human-in-the-Loop Approval

Agents should not take consequential actions on their own. Require human approval before an agent:

• sends a message to a customer or patient;
• changes or deletes business records;
• commits money, prices or contractual terms;
• makes any decision about a person's employment, health or finances.

Show the reviewer the proposed action, the evidence behind it and a simple approve/edit/reject choice.

Error Recovery

• Timeouts and retries with limits, so a stuck tool does not stall the workflow forever.
• Validation of every agent output against an expected format before the next step uses it.
• Fallbacks — a simpler path or a human hand-off when an agent fails repeatedly.
• Step limits to stop agents looping indefinitely.
• Idempotent actions so a retried step does not send the same message twice.

Monitoring and Observability

You cannot run what you cannot see. Trace every workflow run: which agents ran, which tools they called with which inputs, how many tokens each step used, how long it took and why the workflow branched. Review failed and escalated runs regularly; they are the best source of improvements.

Security and Access Control

• Least privilege: each agent gets only the credentials its job requires.
• Prompt injection: content from emails, web pages or documents can contain instructions aimed at the agent. Treat retrieved content as data, never as instructions, and keep sensitive actions behind approval.
• Secrets: keep API keys and credentials out of prompts and logs.
• Audit trail: record who approved which action and when.

Cost and Latency Controls

Multi-agent workflows can multiply model calls quickly. Keep them predictable with per-task token budgets, small models for simple steps (classification, extraction, checking), caching of repeated lookups, parallel execution of independent steps, and alerts when a workflow's cost or duration drifts. Our guide to reducing LLM token costs covers these techniques in depth.

A Reference Architecture

1. Entry point: a message, form or event starts a workflow.
2. Orchestrator: a LangGraph graph with explicit state and checkpoints.
3. Specialist agents: intake, research, drafting and checking, each with narrow tools.
4. Tool layer: MCP servers wrapping business systems, with read and write separated.
5. External agents: A2A for hand-offs across organisational boundaries, where needed.
6. Approval step: an interrupt that waits for a human before any action.
7. Observability: tracing, cost tracking and alerting across every run.

We are researching these patterns in our AI Transformation Lab. They are design principles and research, not claims of production systems.