Agentic AI · BraivIQ AI Engineering Playbook

Agent Interoperability In Code: The A2A Protocol, Agent Cards And How Agents From Different Vendors Actually Talk To Each Other

The first wave of enterprise agents was built one at a time, each a closed world. The second wave has a different problem: a typical large organisation now runs agents from its CRM vendor, its service-desk vendor, its own engineering team and a handful of specialist providers, and none of them can hand work to each other. Making agents interoperate - discover one another, delegate tasks, exchange results, across vendors and frameworks - has become the defining infrastructure question of agentic systems, and the Agent2Agent protocol (A2A), now open-governed under the Linux Foundation and shipping as enterprise-grade in frameworks like CrewAI, is the emerging standard for it. This playbook is a code-side guide to A2A and to architecting a multi-vendor agent estate: agent cards published at a well-known URL for discovery, the task lifecycle as the unit of collaboration, messages and artifacts, streaming and push notifications for long-running work, how A2A complements MCP rather than competing with it, and the registry, delegation, authentication and governance patterns that stop cross-agent handoffs becoming an unaudited chain.

September 21, 2026 · 13 min read · By BraivIQ Engineering

Open-governed - The Agent2Agent protocol is stewarded under the Linux Foundation, with contributions across vendors · Enterprise-grade - Frameworks such as CrewAI now report A2A integration suitable for production multi-agent communication · Agent cards - Machine-readable descriptions of an agent’s capabilities, auth and endpoint, published at a well-known URL for discovery · Complements MCP - MCP connects agents to tools and data; A2A connects agents to agents - two layers, not rivals

The first generation of enterprise agents was built one at a time, and each was a closed world: an agent with its own tools, its own memory, its own interface, that did its job and talked to nobody. That was fine when an organisation had one or two. The second generation has a different and harder problem. A typical large organisation in 2026 runs agents from its CRM vendor, its service-desk vendor, its finance platform, its own engineering team and a handful of specialist providers - and none of them can hand work to each other. The sales agent that qualifies a lead cannot ask the contracts agent to draft terms; the support agent that diagnoses a billing issue cannot delegate the refund to the finance agent; each handoff is a human copying context between silos. Making agents interoperate - discover one another, delegate tasks, exchange results, across vendors and frameworks - has become the defining infrastructure question of agentic systems, and a standard has emerged for it: the Agent2Agent protocol, A2A, originated by Google, now open-governed under the Linux Foundation with contributions across the industry, and shipping as enterprise-grade in frameworks like CrewAI for production multi-agent communication. As an AI Agency Developer London that increasingly builds agents that must live alongside other vendors' agents, we think interoperability is the layer that determines whether an organisation's agents compound or fragment - and this playbook is A2A and multi-vendor agent architecture in code.

A2A And MCP: Two Layers, Not Rivals: A common confusion is to see A2A and the Model Context Protocol as competitors; they solve different problems and a mature architecture uses both. MCP connects an agent to tools and data - it is how an agent reads a database, calls an API or reaches an enterprise system, the vertical integration between one agent and the resources it uses. A2A connects an agent to other agents - it is how one agent discovers another, asks it to take on a task, and receives the result, the horizontal collaboration between peers that may be built by different teams on different frameworks with different models. In practice an agent exposes an A2A endpoint so others can delegate to it, and internally uses MCP to reach the tools it needs to do the delegated work. Getting the layering right matters architecturally: tool access is a permission question about a single agent, while agent delegation is a trust and accountability question between parties - and conflating them produces systems where a delegated task silently inherits tool permissions it should never have had.

The Protocol In Code: Cards, Tasks, Messages, Artifacts

A2A is deliberately built on ordinary web technology - HTTP, JSON, and standard authentication - so that an agent endpoint is just another service, and its core concepts are few. Discovery starts with the agent card: a machine-readable JSON document, published at a well-known path on the agent's host, that describes what the agent is, what it can do (its skills, with descriptions and examples that let a caller or a router decide whether it is the right agent for a task), how to authenticate to it, what its endpoint is, and which capabilities - streaming, push notifications - it supports. A calling agent fetches the card, decides whether to delegate, and authenticates according to the card's declared scheme. The unit of collaboration is the task: the caller creates a task on the remote agent with an initial message, and the task moves through an explicit lifecycle - submitted, working, input-required (the remote agent needs something from the caller before it can continue), completed, failed or cancelled - that both sides can observe. Communication within a task is by messages, each carrying one or more parts (text, structured data, files), and the remote agent's outputs are delivered as artifacts - the results of the work, distinct from conversational messages, so a caller can tell a status update from a deliverable. For long-running work the protocol supports streaming of task updates over server-sent events and push notifications to a caller-supplied webhook, so a delegating agent need not hold a connection open while a remote agent works for minutes or hours. That is the whole surface: discover by card, collaborate by task, converse by message, deliver by artifact, and stay informed by stream or push. Everything else is architecture.

Agent card - a JSON description at a well-known URL: identity, skills with examples, auth scheme, endpoint, supported capabilities; the basis of discovery and routing.
Task - the unit of delegation, with an explicit lifecycle (submitted, working, input-required, completed, failed, cancelled) both parties can observe.
Messages and parts - the conversation within a task; parts carry text, structured data or files so content is typed, not free-form prose.
Artifacts - the deliverables of a task, distinct from status messages, so callers can separate results from chatter.
Streaming and push - server-sent events for live updates and webhooks for long-running tasks, so delegation never blocks on an open connection.

Architecting A Multi-Vendor Agent Estate

A protocol makes interoperation possible; architecture makes it manageable, and a multi-vendor estate needs four things beyond the wire format. The first is a registry: an internal catalogue of the agent cards your organisation trusts - your own agents and the vendor agents you have approved - so that discovery is a lookup against a governed list rather than an open crawl, and so that a new agent must be registered, reviewed and scoped before anything can delegate to it. The second is an orchestration layer that delegates by capability: rather than hard-wiring 'send refunds to the finance agent', a workflow or orchestrating agent asks the registry for an agent whose skills match the task and delegates through A2A, which keeps the estate loosely coupled and lets you swap or add agents without rewriting callers - the same logical-name indirection an AI gateway provides for models, applied to agents. The third is authentication and scoped authorisation between agents: every delegation carries an identity, the remote agent verifies it, and - critically - the permissions of a delegated task are the intersection of what the caller was allowed to ask for and what the remote agent is allowed to do, never the union, so that delegation cannot be used to launder a permission neither party had. The fourth is observability across handoffs: a task delegated from one agent to another to a third must carry a correlation identifier so that the whole chain can be traced, audited and debugged as one unit of work, and so that a failure or a policy violation three hops away can be attributed. Without these, interoperability is a liability - an easy way for work to flow through agents nobody is accountable for; with them, it is the foundation of an agent estate that compounds.

The governance trap: delegation chains nobody can audit: The specific danger of agent interoperability is that it makes delegation cheap, and cheap delegation without governance produces chains - agent A asks B, which asks C, which calls a tool - where no single party understands the whole, where consequential actions happen several hops from the human who initiated the work, and where an injected instruction in one agent's input can propagate through the others. The disciplines that prevent it: bound the depth of delegation and make every hop carry the originating context and a correlation identifier; treat messages from other agents as untrusted input, exactly as you treat retrieved content, and never let them expand a task's scope; require that consequential actions - money, contracts, deletions, external communications - resolve to an explicit approval regardless of how many agents are in the chain; and keep the registry the single source of which agents may be delegated to, with scoped permissions per agent. An interoperable estate must be more governed than a single agent, not less, because the blast radius of an unaudited chain is the whole organisation.

The Bottom Line

The problem of the second wave of enterprise agents is not building one but making many - from different vendors, teams and frameworks - work together, and the Agent2Agent protocol, open-governed under the Linux Foundation and enterprise-grade in frameworks like CrewAI, is the emerging standard for it. In code it is small and web-native: agent cards at a well-known URL for discovery, the task with its explicit lifecycle as the unit of delegation, typed messages and distinct artifacts for conversation and deliverables, and streaming and push notifications so long-running delegation never blocks. It complements rather than competes with MCP - MCP connects agents to tools and data, A2A connects agents to agents - and keeping those layers distinct is what stops a delegated task inheriting permissions it should never have. What turns the protocol into a manageable estate is architecture: a governed registry of trusted agent cards, orchestration that delegates by capability through logical indirection, identity and scoped authorisation on every hop with permissions intersected rather than unioned, and observability that traces a chain of handoffs as one unit of work. The trap is cheap delegation without governance - unaudited chains where consequential actions happen hops away from any accountable human - and the disciplines against it are bounded depth, untrusted treatment of inter-agent messages, mandatory approval for consequential actions, and a registry as the single source of trust. Interoperability is the layer that decides whether an organisation's agents compound or fragment, and building agent estates that compound safely is exactly the work we do.

References & Further Reading

A2A Protocol - official specification and documentation (agent cards, tasks, messages, artifacts, streaming): https://a2a-protocol.org/
Linux Foundation - the Agent2Agent protocol project (open governance): https://www.linuxfoundation.org/
CrewAI - documentation on agent-to-agent (A2A) integration for production multi-agent systems: https://docs.crewai.com/
Model Context Protocol - specification (the tools-and-data layer that A2A complements): https://modelcontextprotocol.io/
AI Agent Store - AI Agents News, week of September 22 2026 (agent infrastructure and protocols): https://aiagentstore.ai/ai-agent-news/this-week