Can MCP, A2A, and LangGraph share and compose a single verified runtime?

#ai #mcp #agents #langgraph

Here is a goal I keep coming back to:

"Show me my portfolio performance, summarize https://en.wikipedia.org/wiki/Nvidia, and turn both into a one-page brief I can read in the morning."

Three steps, and each one is easy on its own. The portfolio numbers live behind an MCP server. The summarizer is an A2A service someone else runs. The brief writer is a LangGraph agent a teammate deployed last month. What is not easy is running them as one thing you can trust, and the reason why is hiding in plain sight: those three names are not three kinds of agent. They are three kinds of boundary.

None of these is an agent

The industry uses the word "agent" for all three, so it is worth being precise.

MCP, introduced by Anthropic in November 2024, is a tool protocol. The specification borrows its shape from the Language Server Protocol: hosts, clients, servers, JSON-RPC 2.0, with servers exposing tools, resources, and prompts. A filesystem MCP server is not an agent. It is a capability behind a uniform socket, which is why the "USB-C for AI" analogy stuck.

A2A, launched by Google in April 2025 and now a Linux Foundation project, is an agent protocol. Endpoints publish agent cards and accept tasks. The card claims agency. What actually sits behind it is a task-processing endpoint with good metadata.

LangGraph is not a protocol at all. It is a framework for building agents as graphs, and the graph is your code in your process. It only becomes something a stranger can call when it is deployed behind LangGraph Platform, which speaks Agent Protocol, LangChain's open serving specification.

So the honest question is not whether three agents can share a run. It is whether work behind three different kinds of boundary can be composed into one run you can verify. The orchestrator composes calls, not agents.

What the run would have to do

Walk the goal slowly and the requirements fall out on their own.

Something has to decompose the goal into steps with dependencies. The brief waits for the numbers and the summary; those two can race each other. Something has to find the right endpoint for each step, which means a registry with semantic search, because you cannot hardcode the world. Something has to speak each boundary natively, one handler per protocol, because the moment joining requires a rewrite, nobody joins.

And every step has to be verified, because in any agent loop the verifier is the bottleneck, not the model. Three steps that each look correct can still compose into a brief that is wrong. That failure mode has its own post in this series, and it is not a short one.

What the evidence says

This is where it stops being a thought experiment. Line up the last eighteen months:

November 2024. Anthropic open-sources MCP.
April 2025. Google launches A2A with more than 100 partner organizations.
June 2025. Google donates A2A to the Linux Foundation.
August 2025. IBM's ACP, a REST-native agent protocol built for the BeeAI platform, merges into A2A rather than compete with it.
December 2025. Anthropic donates MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI.

A recent survey of multi-agent orchestration describes the pattern well: competitors cooperating on standards while competing on implementations. The boundaries are consolidating under neutral governance faster than most people building on them realize. The adoption numbers are vendor-reported but large. Anthropic claims more than 10,000 public MCP servers and 97 million monthly SDK downloads, and the Linux Foundation counts 150-plus organizations around A2A at its one-year mark.

Two caveats keep this honest. Neutral governance is not the same as adoption, and at least one practitioner postmortem asks what actually happened to A2A after the donation fanfare. More importantly, convergence of protocols says nothing about composition. Settling the sockets does not settle what happens when you plug three of them into the same wall. One goal, three boundaries, verified end to end: that is still nobody's job.

What the agents would return

If a run is going to be checked, endpoints cannot answer with prose. They have to return structure. Imagine every step replying with a small manifest instead of a paragraph:

{
  "__canvas__": true,
  "summary": "Portfolio dashboard: $142,300 across 8 positions.",
  "manifest": {
    "version": "1.0",
    "layout": "dashboard",
    "components": [
      { "type": "metric_card", "label": "Total Value", "value": "$142,300", "trend": "up" }
    ]
  }
}

Structured output persists. More importantly, structured output can be checked, by something other than a human reading a chat log and squinting.

What joining would have to cost

If the price of admission is rewriting your agent, the network stays empty. The API you would want is embarrassingly small, something like:

import runtime

@runtime.agent(name="My Agent", description="What I do")
def handle(task: str) -> str:
    return f"handled: {task}"

Under that, a versioned, schema-validated manifest describes what the agent does. Additive changes ship freely. Breaking changes need the equivalent of an RFC, because once strangers build on your spec, breaking it breaks everyone.

The questions I do not have answers to

This is the part I actually wanted to write.

How does an agent declare what it is allowed to do, not just what it can do? A manifest field for authorized scope feels necessary. It also feels insufficient the moment money or user data is involved.

Should agents pay each other at all? Mocking payments is obviously the right place to start, but "obviously right for now" is not an architecture.

If you accept a manifest from one protocol and quietly route it through another protocol's handler, did you support the first protocol or not? A compatibility alias is honest engineering and a marketing lie at the same time, and I do not know which side it lands on.

Does Agent Protocol become a fourth boundary, or does it get absorbed the way ACP was? LangChain's specification is open, but today it is spoken almost entirely by LangGraph Platform. A boundary with one implementation is a product feature wearing a spec's clothes.

And the big one: what happens when an agent you do not control registers and joins your runs? Every assumption above gets stress-tested by strangers. I suspect most of them break.

If you have tried to compose across MCP and A2A, or wrapped a LangGraph graph for someone else's runtime, I would genuinely like to hear where it broke first.

Sources and further reading: