Coding Agent Swarms, Part 5: Running the Fleet From Your Phone
The Last Mile Is the Operator The first four parts of this series built the substrate: foundation, fleet, multi-fleet …
The Plumbing Problem Nobody Solved
Everyone’s building agents. Every vendor demo shows an AI that can “reason,” “plan,” and “take action.” The pitch decks are gorgeous. The live demos are carefully choreographed. And behind the curtain, every single one of these agents is a silo.
Your Salesforce agent can’t talk to your SAP agent. Your internal coding assistant doesn’t know your compliance agent exists. Your customer support bot and your inventory management system occupy the same enterprise but live in completely different universes.
This is the actual state of “agentic AI” in most organizations: a collection of impressive but isolated capabilities, stitched together with bespoke integrations that break every time someone updates an API.
Two protocols are changing that. And if you’re building anything with agents, you need to understand both of them.
MCP: How Agents Talk to Tools
The Model Context Protocol started at Anthropic in November 2024 and has since moved to the Linux Foundation. The idea is deceptively simple: create a universal standard for how AI agents connect to external tools and data sources.
Before MCP, every integration was custom. Want your agent to query a database? Write a connector. Want it to read files from cloud storage? Write another connector. Want it to call an internal API? Another one. Multiply that by every agent framework, every LLM provider, and every enterprise tool in your stack, and you get a combinatorial nightmare of bespoke glue code.
MCP replaces that with a client-server architecture. Data sources and tools expose themselves as MCP servers. AI applications connect as MCP clients. One protocol, one interface, universal compatibility.
The adoption has been fast. Pre-built MCP servers exist for GitHub, Slack, Google Drive, Postgres, and dozens of other systems. Development tool companies like Zed, Replit, Codeium, and Sourcegraph have integrated it. Block and Apollo adopted it early for their enterprise systems. The SDK download numbers are in the tens of millions per month.
MCP answers a fundamental question: how does an agent interact with the world outside itself?
But it doesn’t answer the next question.
A2A: How Agents Talk to Each Other
Google launched the Agent2Agent Protocol in April 2025, and it joined the Linux Foundation two months later in June. Where MCP handles agent-to-tool communication, A2A handles something harder: agent-to-agent communication.
This matters because real enterprise workflows don’t involve a single agent using a bunch of tools. They involve multiple agents — built by different teams, running on different frameworks, possibly from different vendors — that need to discover each other, negotiate what they can do, and coordinate on shared tasks.
A2A is built on standards that already run the internet: HTTP, Server-Sent Events, and JSON-RPC 2.0. That’s a deliberate choice. It means A2A works with existing enterprise infrastructure — proxies, load balancers, API gateways, observability tools — without requiring anything exotic.
Here’s how it works.
Agent Cards
Every A2A-compatible agent publishes an Agent Card — a JSON metadata file describing what it can do. Think of it as a machine-readable resume. The card includes the agent’s name, description, endpoint URL, supported modalities (text, audio, video), authentication requirements, and the specific skills it offers.
When a client agent needs to find a remote agent for a particular task, it reads Agent Cards to figure out who can help. No hardcoded endpoints. No human-maintained service registries. Agents discover each other programmatically.
Task Lifecycle
A2A is oriented around tasks, not just messages. A task is a unit of work with a defined lifecycle: submitted, working, input-required, completed, or failed. This matters because real work isn’t a single request-response cycle. A procurement approval might take days. A compliance review might need human input halfway through. A data analysis might stream results incrementally.
A2A handles all of this natively. Short tasks complete immediately. Long-running tasks use push notifications via secure webhooks. Streaming tasks use Server-Sent Events for real-time updates. The protocol doesn’t assume your work fits in a single HTTP round-trip.
Data Opacity
This is the feature that makes A2A enterprise-viable: agents collaborate without revealing their internals. An agent’s memory, reasoning chain, tool implementations, and proprietary logic stay private. Only the inputs, outputs, and status of the task are shared.
That’s not a limitation — it’s a requirement. No enterprise is going to expose the internal workings of their competitive intelligence agent to a partner’s supply chain agent. A2A lets them work together without opening the hood.
UI Negotiation
Agents can negotiate how to present information to humans. One agent might produce structured data. Another might render an iframe. A third might stream video. A2A’s message format supports different content types — TextPart, FilePart, DataPart — so agents can exchange rich content without assuming anything about the rendering environment.
The Stack: MCP Below, A2A Above
Here’s the mental model that matters.
MCP is vertical. It connects an agent downward to the tools, databases, APIs, and file systems it needs to do its job. An inventory agent uses MCP to query the warehouse database. A coding agent uses MCP to read the Git repository. A financial agent uses MCP to pull data from the ERP system.
A2A is horizontal. It connects agents laterally to other agents. The inventory agent uses A2A to tell the procurement agent that stock is low. The coding agent uses A2A to ask the security agent to review a pull request. The financial agent uses A2A to coordinate with the compliance agent on a regulatory filing.
Together, MCP and A2A define the full communication stack for multi-agent systems. MCP tells agents what tools exist. A2A tells agents what other agents exist. An agent without MCP is blind to the world. An agent without A2A is alone in it.
Who’s Behind This
The backing for both protocols is unusually broad.
A2A launched with over 50 technology partners including Atlassian, Box, Salesforce, SAP, ServiceNow, PayPal, Workday, Intuit, MongoDB, LangChain, Cohere, Elastic, Datadog, Neo4j, and JetBrains. The consulting firms are in too: Accenture, Deloitte, McKinsey, PwC, Capgemini, and others.
Under the Linux Foundation, A2A has founding support from Google Cloud, AWS, Microsoft Azure AI, Cisco, Salesforce, SAP, and ServiceNow. That’s every major cloud provider and a cross-section of enterprise software.
MCP has similar breadth in the developer tooling space, with adoption across IDE makers, cloud platforms, and enterprise software vendors.
Both protocols being under the Linux Foundation matters. It means vendor-neutral governance, open contribution models, and long-term stability that doesn’t depend on any single company’s roadmap. Google can’t unilaterally change A2A. Anthropic can’t unilaterally change MCP. The standards belong to the community.
What This Means If You’re Building Agent Infrastructure
If you’re building or deploying AI agents in an enterprise context, here’s the practical takeaway:
Support both protocols. MCP for tool integration, A2A for agent coordination. They’re complementary, not competing. Picking one and ignoring the other leaves you with half a communication stack.
Design agents with Agent Cards in mind. Your agents should be discoverable and their capabilities machine-readable. If another team’s agent can’t programmatically figure out what your agent does, your agent is invisible to the broader system.
Treat task lifecycle seriously. Not everything is a chat completion. Enterprise workflows involve long-running tasks, human approvals, partial results, and failure handling. A2A’s task model was built for this. Use it.
Assume opacity by default. Your agents should be able to collaborate without sharing internal state. If your architecture requires agents to share memory or expose their reasoning chains to work together, you’ve built something that won’t survive contact with a real multi-vendor environment.
Keep your agents on your infrastructure. Protocols like MCP and A2A define how agents communicate — they don’t dictate where those agents run. At Calliope , we’ve built our platform around the principle that your agents, your models, and your data should stay on infrastructure you control. Open protocols make that possible without sacrificing interoperability.
The Bigger Picture
We’re at the point where the agent hype is colliding with the agent reality. The reality is that isolated agents, no matter how capable, don’t solve enterprise problems. Enterprise problems span systems, teams, vendors, and organizational boundaries.
MCP and A2A are the first credible answer to the interoperability question. Not because they’re theoretically elegant — though they are — but because they’re backed by the companies that actually build the systems enterprises run on, governed by a neutral foundation, and built on protocols that already work at scale.
The plumbing isn’t glamorous. It never is. But it’s what determines whether “agentic AI” stays a collection of impressive demos or becomes something that actually works in production.
The protocols are here. The governance is in place. The partner ecosystem is broad. The only question left is whether your agent infrastructure is ready to speak the common language.
