The Other Half of the Interop Stack: A2A and the Agent Internet

A year ago, the hard problem in agent engineering was getting an agent to use things — to call a tool, read a database, hit an API without a bespoke integration for each one. The Model Context Protocol solved that, and we wrote about how MCP became the universal standard for connecting an agent to the world’s tools and data. But MCP only ever addressed one axis. It connects an agent downward, to its tools. It says nothing about how one agent talks to another agent.

That’s the other half of the stack, and in 2026 it has a standard of its own: the Agent2Agent protocol (A2A). If MCP is how an agent reaches its tools, A2A is how an agent reaches its peers — and the two together are quietly assembling the plumbing of something larger: an internet of agents that can find and delegate to each other across vendors, frameworks, and organizations.

What A2A actually is

A2A was released by Google in April 2025 and donated to the Linux Foundation in June 2025, where it’s now governed as a vendor-neutral open project — its founding governance members include AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. That governance detail matters more than it looks; we’ll come back to it.

Technically, A2A is deliberately unglamorous. Its design principle, in the spec’s own words, is to “reuse existing, well-understood standards (HTTP, JSON-RPC 2.0, Server-Sent Events)” — with a gRPC binding as an option. There’s no exotic new transport to learn; it’s the boring, battle-tested web stack, which is exactly why it’s easy to adopt.

The piece that makes coordination possible is the Agent Card — per the spec, “a JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.” An Agent Card is how one agent discovers what another can do and how to talk to it, without a human wiring them together in advance. Around that, A2A defines a small set of primitives — a Task (the unit of work, with status and history), Messages (the back-and-forth), and Artifacts (the outputs) — enough to support stateful, multi-turn collaboration between two independent agent systems that have never met.

MCP and A2A: two axes, one stack

The cleanest way to hold this is as two perpendicular axes. MCP is vertical: it connects an agent down to tools, data, and resources. A2A is horizontal: it connects an agent across to other agents as peers. The A2A spec is explicit enough about this division that it includes a dedicated section — “Appendix B. Relationship to MCP” — spelling out that the two are complementary, not competing.

You want both, because they solve different problems. MCP lets a single agent act on the world. A2A lets a system of agents divide labor: a planning agent delegates a research subtask to a specialist agent, which itself uses MCP to hit the tools it needs, and returns an Artifact. This is the multi-agent pattern we explored in the code agent orchestra — except A2A standardizes the part where the agents are no longer all built by you, in one framework, on one machine. They can be built by different vendors, run by different organizations, and still coordinate, because they speak the same protocol and advertise themselves with the same kind of Agent Card.

That’s the leap. Multi-agent systems used to mean your sub-agents talking to each other inside your harness. A2A makes “agents talking to agents” a property of the open network, not of a single codebase.

Make it concrete. Imagine an enterprise procurement agent that needs a supplier-risk assessment. Today, that capability would be a hard-coded integration — if it exists at all. With A2A, the procurement agent reads the Agent Card of a specialist risk-assessment agent (built by a different company, running on a different cloud), opens a Task, sends the supplier details as a Message, and receives a structured risk report as an Artifact. The procurement agent never needed to know how the risk agent works, what framework it’s built in, or which model it runs — only that its Agent Card advertised the capability and the endpoint. The integration that used to take a quarter of engineering becomes a runtime discovery.

From integrations to an agent internet

Standards only matter if people adopt them, and this is where A2A stops being a spec and starts being an ecosystem. According to the Linux Foundation, in A2A’s first year “the number of supporting organizations has grown from more than 50 to over 150.” It’s been integrated into the major cloud agent platforms — Microsoft’s Azure AI Foundry and Copilot Studio, AWS’s Amazon Bedrock AgentCore Runtime, and Google Cloud — and the Foundation reports active production deployments across supply chain, financial services, insurance, and IT operations.

The reason this compounds is the same reason the web did: discovery plus a shared protocol produces network effects. Every agent that publishes an Agent Card becomes something other agents can find and delegate to. Every platform that speaks A2A becomes a place those agents can interoperate. Past a threshold, the value isn’t any single agent — it’s the network of agents that can now reach each other. That’s the shape of an internet: not a product, but a substrate that no one owns and everyone can build on. MCP gave us the tool layer of it; A2A is giving us the agent layer.

The new trust surface

It would be naive to celebrate this without naming the cost. The moment agents can discover and delegate to other agents — including ones built by people you’ve never met — you’ve opened a genuinely new security surface, and it’s the natural sequel to the concerns we raised about MCP’s security problem.

The questions are sharp. When your agent delegates a task to a remote agent, what is it trusting that agent with — what data travels in the Message, and where does it go? How do you authenticate the agent behind an Agent Card, and verify it is what it claims to be rather than an impostor advertising attractive capabilities? A2A builds on standard web auth and the Agent Card declares its authentication requirements, which is the right foundation — but the hard part is policy, not transport: deciding which agents you’re willing to delegate to, what they’re allowed to receive, and how you audit what they did. An open network of delegating agents is powerful precisely because it’s open, and that openness is exactly what has to be governed. The protocol gives you the mechanism; the trust decisions are still yours to engineer. And the failure modes compound across hops — if your agent delegates to a remote agent that itself delegates onward, a prompt injection or a misbehaving peer three steps out can still reach back to you, which means the same scrutiny we apply to a single agent’s tool calls now has to extend across the whole delegation chain.

Why this favors Southeast Asia

Here’s why this matters most for the teams we keep writing for, and it comes back to that governance detail. A2A is an open, vendor-neutral standard under the Linux Foundation — not a proprietary network owned by one company that can change the rules, raise the price, or revoke your access. That is the whole point, and it’s the same argument we made for open standards as Southeast Asia’s foundation: when the substrate is open, a small team participates on the same terms as a giant.

Concretely, it means a Cambodian or Vietnamese team can build an agent — a Khmer-language document processor, a local logistics coordinator, an agricultural advisory service — publish an Agent Card, and have it discoverable and usable by the global network of agents without anyone’s permission. No platform gatekeeper decides whether you’re in. You don’t need to be acquired, partnered, or approved; you need to speak the protocol. And because A2A runs on the ordinary web stack, standing up an A2A agent is cheap — it’s HTTP and JSON, not capital-intensive infrastructure.

That’s the durable, capital-light position again: own your agent, speak the open protocol, and plug into a network that no single vendor controls. The frontier labs will build impressive agents, and the cloud giants will host them. But the network that connects all of them is, for now, an open commons — and being early and fluent in how to participate in it is exactly the kind of leverage a region without a frontier lab can actually hold. The agent internet is being wired right now. The teams that learn to speak its protocol don’t have to ask to join it.