- MCP standardizes how an agent reaches tools and context; A2A standardizes how agents delegate tasks to each other. They are complementary layers, not rivals.
- As of mid-2026 the agent mesh is early: most production multi-agent systems run inside one organization under a single framework, and cross-org meshes remain pilots.
- Prepare without betting the farm: task-shaped agent contracts, an internal agent registry, identity for non-human actors, and protocol adapters kept at the edges.
Why agent interop is the next integration problem
Enterprise integration has a habit of repeating itself one abstraction level up. The 2000s wired applications together with middleware and service buses; the 2010s did it again with REST APIs and event streams. The next round is already visible: agents. Every major SaaS vendor now ships an agent inside its product, every platform team is building internal ones, and procurement is starting to see agentic line items from ISVs and consultancies alike. Each of these agents is useful alone. Almost none of them can work together.
That matters because the tasks enterprises actually care about cross boundaries. Closing a customer incident might involve a support agent triaging the ticket, an engineering agent inspecting logs, and a finance agent issuing a credit. Today that flow either runs inside a single vendor's walled garden or is stitched together by hand: custom glue code, brittle handoffs, or a human copying context between chat windows. Agents built without interoperability become the new silos, and the glue between them becomes the new legacy.
The alternative vision is usually called the agent mesh: a fabric of specialized agents, owned by different teams, vendors, and eventually organizations, that discover each other, delegate tasks, and return results over shared protocols. In that world an agent is less a monolithic assistant and more a service with judgment: narrow, well described, composable. Whether the mesh arrives in two years or seven, the direction of travel is hard to argue with, because it is the direction integration has always traveled: away from bespoke point-to-point links, toward shared contracts.
The protocol map: MCP vs A2A
Two protocols dominate the conversation, and they solve different problems. The Model Context Protocol (MCP), announced by Anthropic in November 2024, standardizes how an agent connects to tools and context: databases, file systems, SaaS APIs, internal services. It answers the question of how one agent reaches the things it needs to do its job. One agent, many tools, a common connector format instead of a bespoke integration per pair.
Agent2Agent (A2A) sits one layer up. It standardizes how an agent talks to another agent as an opaque collaborator: you hand a peer a task, it works with its own tools, models, and internal logic that you never see, and it returns status updates and results. The remote agent is not a function you call; it is a counterpart you delegate to. That opacity is deliberate. It lets organizations expose capability without exposing implementation, which is the only realistic basis for cross-vendor and cross-company collaboration.
+---------------------------------------------------+
| Your agent / orchestrator |
+--------------+---------------------+--------------+
| |
MCP | tools and A2A | peer agents
| context | (opaque)
v v
+-------------------+ +----------------------+
| Databases, APIs, | | Another team's agent |
| files, SaaS, | | Vendor product agent |
| connectors | | Partner-org agent |
+-------------------+ +----------------------+
Treating the two as competitors is a category error, and notably it is not how Google frames A2A either: its own positioning presents A2A as complementary to MCP. A plausible future stack uses both, MCP inside each agent for tool access and A2A between agents for delegation. The architecture question is not which one wins but where each belongs in your estate.
A2A anatomy: agent cards, tasks, artifacts
A2A was announced by Google in April 2025 with an unusually broad partner list spanning software vendors and system integrators, and was donated to the Linux Foundation in mid-2025 to put it under open, vendor-neutral governance. That move matters to enterprise buyers: a protocol controlled by one vendor is a dependency; a protocol under foundation governance is closer to infrastructure. The specification is still evolving, so treat what follows as the shape of the design rather than a frozen contract.
Discovery starts with the agent card: a machine-readable description of what an agent can do, where to reach it, and how to authenticate, typically published at a well-known URL. Work then flows through a task lifecycle: a client agent submits a task, the remote agent reports status transitions as it works, exchanges can run long and asynchronously, and completed work comes back as artifacts, durable outputs distinct from the conversational messages traded along the way. Everything rides on boring, proven web standards: HTTP for transport, JSON-RPC for the call format, and server-sent events (SSE) for streaming updates. For an enterprise architect that is a feature, not a limitation, because existing gateways, proxies, and observability tooling already understand this traffic.
| A2A concept | What it is | Closest enterprise analogue |
|---|---|---|
| Agent card | Machine-readable capability, endpoint, and auth description | Service catalog entry or API spec |
| Task | Unit of delegated work with an explicit lifecycle | Ticket or work order |
| Message | A turn exchanged while a task is in flight | Comment thread on the ticket |
| Artifact | Durable output of a completed task | The deliverable attached at closure |
The mental model that sticks: A2A turns "call my API" into "open a ticket with my agent." Tasks can run for hours, can require clarification mid-flight, and end with deliverables. That maps far better to how real work moves between teams than a synchronous request-response call ever did.
Discovery, identity and trust
Discovery is the easy half. Agent cards give you a standard way to advertise capability, and inside one organization a registry of cards is a straightforward build. The hard half is everything that follows discovery: should this agent trust that one, with what authority, on whose behalf, and with what evidence afterward?
Agents are non-human actors that behave more like employees than like services. They hold credentials, exercise judgment, and act with delegated authority. Most enterprise identity stacks were built for humans and static service accounts, and agents fit neither category cleanly: a service account does the same thing every day, while an agent's next action depends on a model's reading of the situation. When a procurement agent negotiates with a supplier's agent, the identity questions compound across three layers at once.
- Identity for the agent itself: a first-class, per-agent identity in your directory, not a shared service account, so access and revocation are individually controllable.
- Delegated authority: every task should carry a verifiable statement of who or what the requesting agent acts for, not just a bearer token that amounts to an unsupported claim of trust.
- Scoped credentials: short-lived, task-scoped, least-privilege grants; an agent handling one purchase order does not need standing access to the whole ERP.
- Audit trails: every delegated task, status change, and artifact should land in a log a human can reconstruct, because someone will eventually explain an agent's decision to an auditor.
Inside one company these are tractable engineering problems, and the patterns from workload identity and zero-trust programs carry over. Across organizational boundaries they are the genuinely unsolved part: there is no mature answer yet for how two companies establish that each other's agents are competent, authorized, and accountable, nor for who bears liability when a delegated task goes wrong. The protocols define the envelope; the trust fabric around it is still being invented.
The enterprise reality check
An honest status report, as of mid-2026: early. The specifications exist, the governance story has improved, reference implementations and vendor announcements are plentiful. Deployed cross-organization agent meshes are not. Most multi-agent systems actually running in production are intra-organization and orchestrated by a single framework: one team, one runtime, agents that are really components of one application. That is multi-agent architecture, and it is often the right choice, but it is not an agent mesh, and the distinction matters when a vendor deck blurs it. See Multi-Agent Patterns for that intra-org layer.
Where open standards will bite first is predictable from every prior standards cycle: at the seams you do not control. Cross-vendor product integration, where the CRM vendor's agent must hand work to the ITSM vendor's agent and neither will adopt the other's proprietary interface. And B2B integration, where two companies want their agents to transact and need a neutral contract neither side owns. Inside a single estate, a well-chosen orchestration framework remains simpler than a protocol mesh, and will for some time.
None of this argues for ignoring the space. It argues for calibrated timing: the standards are worth tracking closely and piloting cheaply, and not yet worth re-platforming around. The cost of being six months late to a maturing protocol is small; the cost of hard-wiring an unstable one into production systems is not.
Architecture implications today
You do not need to adopt A2A to benefit from its discipline. The moves that make a future mesh cheap to join are the same moves that make today's agent estate governable, which is why they are worth making now regardless of how the standards race resolves.
- Task-shaped contracts. Expose each agent behind a clean, task-based interface: submit work, observe status, receive artifacts. If the internal contract already looks like a task lifecycle, mapping it onto A2A or any successor later is a transport swap, not a redesign.
- An internal agent registry. Keep a catalog of every agent in the estate: owner, capabilities, data touched, model dependencies, escalation path. This is your future discovery layer and your present governance tool, and it is embarrassing how few organizations can produce the list.
- Centralized outbound agent traffic. Route agent calls that cross your boundary through a gateway you control, so policy, rate limits, data loss prevention, and audit apply in one place instead of being reimplemented per agent. The integration patterns playbook applies directly.
- Protocol at the edges only. Keep MCP and A2A specifics inside adapter layers. Business logic that imports protocol types directly is business logic you will rewrite when the specification changes, and at this maturity level the specification will change.
Seasoned architects will recognize the shape: these are the API-era lessons restated. Contracts before transports, catalog everything, control the perimeter, and never let a wire format leak into the domain model.
Preparing without betting the farm
Three moves are safe today because they pay off under every plausible outcome. First, adopt MCP for tool and context access now: it is the more mature layer, the ecosystem of servers and clients is real, and it removes bespoke integration work whether or not a mesh ever materializes. Second, shape your agents' interfaces as tasks with lifecycles and artifacts, as described above. Third, start the identity groundwork for non-human actors, because directory schemas, credential issuance, and audit pipelines take quarters to change and will be needed by any interop future whatsoever.
For A2A itself, pilot rather than standardize. Stand up one bounded experiment, ideally at a real seam such as a vendor product you already run or a single willing partner, and treat it as a learning vehicle. A sandbox like the Agent Studio in the Lab is the right scale for this: big enough to surface the operational questions, small enough to discard.
- Vendor adoption: do platforms you already pay for expose A2A endpoints in shipping products, not roadmap slides?
- Governance maturity: specification stability, conformance test suites, and multiple independent implementations under the Linux Foundation process.
- Security patterns: visible consensus forming on agent identity, delegated authority, and cross-org trust, the thinnest parts of the story today.
Review those signals quarterly and adjust posture accordingly, the same cadence you would apply to any emerging standard. The organizations that do well in the mesh era will not be the ones that guessed the winning protocol in 2026. They will be the ones whose agents were built as composable, well-described, accountable services all along, for whom adopting the winner is a small adapter, written late, on purpose.