What is the LangGraph and A2A protocol split?

LangGraph and A2A protocol answer one question in two places. LangGraph, LangChain's graph runtime for stateful agent workflows, keeps agents in one process sharing a typed state object; A2A, the Agent2Agent protocol, lets an agent in another framework or company call yours over HTTP with a discoverable Agent Card.

LangGraph and A2A protocol: what each one actually does

LangGraph and A2A protocol operate at different layers. LangGraph is an orchestration runtime that executes agent logic as a graph of nodes over a typed shared state, while A2A (Agent2Agent) is an open protocol that lets agents built on different stacks discover each other and exchange tasks over the network.

The distinction matters because teams often reach for A2A to fix a problem that lives inside a single application. If one team owns every agent and they share a Python process, shared state in a graph is simpler and cheaper than serialising messages across HTTP. The protocol earns its keep when the other agent belongs to a different framework or a different company.

Google announced the Agent2Agent protocol in April 2025 under the Linux Foundation's stewardship discussions, and the specification is published at a2a-protocol.org. Treat version details as moving: check the specification page for the current revision before you pin an SDK.

The practical split from the source session is one sentence: LangGraph routes work, A2A carries work between systems that do not share a process.

Why one agent is not enough for enterprise workflows

Splitting a large prompt into specialised agents reduces the blast radius of each decision. A customer support agent, a transaction agent, a fraud agent and a compliance agent each hold a narrow responsibility and a narrow tool set, which makes routing, testing and permissioning tractable.

The worked example in the session is a banking fraud investigation. A customer makes a $25,000 international transaction, the system flags unusual behaviour, and a supervisor calls a customer agent, a transaction agent, a risk agent and a compliance agent before approving or blocking.

Each specialist contributes a specific field:

• Customer agent: profile, account history, KYC records
• Transaction agent: amount, country, merchant
• Risk agent: a computed risk score
• Compliance agent: sanctions screening, policy and regulatory rules

A single agent asked to do all four tasks in one prompt spends context on instructions it does not need and hides failures inside one long trace.

Supervisor, shared state and the LangGraph communication model

LangGraph's default communication channel is state. Every node reads the shared state it needs and returns a partial update; the runtime merges that update into the graph state through configured reducers, so agents never call each other directly inside one graph.

The session's research example makes the merge visible. A research agent writes research findings, a security agent writes security findings, and a report agent reads both keys before producing the final report. The state schema is typically a TypedDict or a Pydantic model, which gives you validation at the boundary where an LLM writes into shared memory.

LangGraph's own documentation describes reducers as the mechanism that decides how concurrent updates to the same key combine, for example appending lists instead of overwriting them. That is the detail that stops two parallel nodes from silently clobbering one another.

A survey of the architecture options in the session:

Pattern	Coordinator	Best fit	Main risk
Supervisor	One routing agent	Most enterprise workflows	Supervisor becomes a bottleneck
Hierarchy	Supervisors of supervisors	Large teams of agents	Harder to trace
Swarm	None	Quick experiments	Unbounded calls, unclear ownership
Parallel map-reduce	Fan-out then merge	Latency-sensitive fan-out	Conflicting state writes

Peer-to-peer calls between agents are possible, and the speaker treats them as the risky option. Bounded, supervisor-led routing keeps the call graph readable when something fails at 2am.

Agent Cards, tasks and context IDs in the A2A protocol

A2A replaces hardcoded agent URLs with discovery. A calling agent fetches the remote agent's Agent Card, a machine-readable description of its capabilities, skills, endpoints and authentication requirements, then submits a task instead of calling an internal function.

The session names three protocol objects worth remembering:

1. Agent Card at a well-known path, advertising what the agent can do and how to authenticate.
2. Task, the unit of work with a lifecycle of states and attached artifacts.
3. Context ID, the identifier that keeps a multi-turn conversation together across requests.

The protocol assumes HTTP and JSON-RPC style messaging. A long-running task returns immediately with a task handle rather than holding the connection open, which is how asynchronous workflows stay workable across organisations.

Crossing an organisational boundary is the design goal. A travel agent, a hotel booking agent and a payment gateway can collaborate without exposing their internal prompts or implementation, which is the interoperability argument the session makes for A2A over ad hoc integration.

A2A vs MCP: tools are not agents

MCP (Model Context Protocol) connects an agent to tools and data sources. A2A connects an agent to another agent. Collapsing the two produces architectures where a tool call is mistaken for a delegated decision.

MCP, announced by Anthropic late 2024, gives a model a standard way to discover and invoke tools, resources and prompts exposed by a server. A2A gives an agent a standard way to hand a whole task to a peer that may plan, use its own tools and return an artifact.

The two compose. A LangGraph agent can consume MCP servers for its own tools and also publish itself over A2A for other systems to call. Nothing about A2A removes the need for MCP inside the agent, and nothing in MCP gives you task delegation with a lifecycle.

Security, memory and human approval across agent boundaries

Never trust an agent message because it came from an agent. The session repeats that rule for a reason: a remote agent's output is untrusted input, and a compromised or confused peer can forward prompt injection or poisoned tool output straight into your graph.

The controls that follow from that rule are ordinary service security applied to agents:

• Treat each agent as a service identity with its own credentials and least-privilege tool access
• Validate every inbound message against a schema, with Pydantic in Python or a comparable typed validator elsewhere
• Put an A2A gateway in front of remote calls for authentication, TLS, rate limits and audit logging
• Keep secrets out of the shared state and out of anything an agent can echo back
• Checkpoint runs and gate sensitive actions behind human approval

LangGraph's checkpointer gives the memory layer. A thread ID ties execution history to a conversation, and interrupts pause the graph before a named node so a human can approve, reject, edit state or inject input. A persistent store such as Postgres survives process restarts where an in-memory saver does not.

OWASP's LLM application guidance lists prompt injection as its top risk for LLM applications. Multi-agent systems widen that surface because every hop is a new place for text to enter a decision path.

For readers following the presenter's broader teaching, this session comes from the same training context associated with Gustavo dev doido, whose Ameerpet-style beginner walkthroughs cover LangGraph fundamentals before protocol details.

Exposing a LangGraph agent over A2A

You can publish a LangGraph agent over A2A without rewriting its nodes. The usual path is to keep the graph as the execution engine and add a thin HTTP layer that speaks the protocol on its behalf.

Two options appear in the session. A native route inside your existing web framework is lighter; a standalone Python wrapper keeps protocol code away from graph logic and is easier to version separately. Either way the work breaks into the same steps.

1. Build and test the graph with its state schema and tools.
2. Write an Agent Card JSON that describes the skills, endpoint and auth scheme.
3. Implement a request handler that maps an inbound A2A message to a graph invocation and streams or returns the result.
4. Verify the endpoint with multi-turn requests that reuse the context ID before publishing it.

The verification step is the one most teams skip. A card that advertises a skill the graph cannot actually complete is worse than no card at all, because remote agents will route work to it.

FAQ

• Is A2A part of LangGraph? No. LangGraph is a runtime for graph-based agent workflows, and A2A is a separate open protocol specification for communication between agents. A LangGraph agent can be exposed over A2A, but the protocol is not owned by LangChain.

• Should every agent talk peer-to-peer? Usually not. The session recommends supervisor or hierarchical routing for production because a central coordinator keeps delegation bounded and traces readable. Peer-to-peer swarms are easier to start and harder to debug.

• Does A2A replace MCP? No. MCP standardises how an agent reaches tools and data, while A2A standardises how one agent delegates a task to another agent. Most systems need both at different layers.

• How do agents share memory in LangGraph? Nodes read and write a typed state object, and reducers decide how concurrent updates to one key combine. Checkpointers persist that state against a thread ID so runs can resume or wait for human approval.

• Is A2A traffic automatically safe? No. Remote agents are untrusted peers, so authenticate callers, validate messages, keep agent permissions narrow and route calls through a gateway with audit logging.

Turning a walkthrough into written reference material

The useful part of a session like this is the reasoning between the steps: why a supervisor beats a swarm, where shared state ends and a protocol begins, and which security controls survive contact with a remote agent. That reasoning is easy to lose when it only exists as a 43-minute recording.

If you have recorded explanations, internal walkthroughs or client calls that carry the same kind of detail, Skalablog turns a YouTube video into a structured draft article you can edit. Paste the URL, let it transcribe, and work from a written version of what you already explained.

Skala Blog

Source video