AI Agents Built by Different Teams Can Finally Work Together Without Custom Glue Code

While researching multi-agent pipeline architectures, one failure pattern kept showing up. The orchestration agent and the data retrieval agent would both run fine independently. The moment one needed to hand a task off to the other, someone wrote a function. When the result needed to come back, another function. When a third agent from a different framework entered the picture - a LangGraph agent sitting next to Pydantic AI agents - the number of custom handoff functions being maintained started becoming its own engineering surface area. Teams were spending real time on glue code. Not on the agents themselves. Not on the tasks they were doing. On the pipes between them. That pattern showed up consistently enough that it has a name now. And A2A is the protocol the industry built to solve it. What A2A Actually Is Google announced A2A at Google Cloud Next in April 2025 as an open standard designed to enable AI agents to discover each other, exchange information securely, and coordinate actions regardless of their underlying frameworks. The cleanest way to think about it is the contrast with MCP. MCP, introduced by Anthropic in 2024, is the standardization layer for AI applications to communicate with external tools and data sources. A2A focuses on agent collaboration, facilitating communication between AI agents themselves. Both are meant to complement each other. MCP is the tool layer. A2A is the cross-agent layer. An agent uses MCP to query a database or call an API. It uses A2A to delegate a subtask to another agent and get the result back. The protocol uses HTTP, Server-Sent Events, and JSON-RPC 2.0 for transport familiar web infrastructure with Agent Cards for capability discovery and Tasks for work delegation. An Agent Card is how an agent advertises what it can do. It is a JSON document hosted at a well-known URL that describes the agent's capabilities, supported input and output formats, authentication requirements, and task types it handles. When your orchestration agent needs to find an agent that can process invoice data, it reads Agent Cards. No hardcoded routing tables. No custom discovery logic. Just a standardized document at a predictable endpoint. A Task is the unit of work. Your client agent creates a Task, sends it to the remote agent via A2A, and gets back status updates and an artifact the result through the same channel. The remote agent's internal implementation is completely invisible to the client. It could be LangChain, CrewAI, a custom Python script, or a Vertex AI agent. None of that matters. The Task interface is the same regardless. Where It Stands Right Now Here is the honest picture as of mid-2026, because the hype and the reality deserve to be separated. By April 2026, the Linux Foundation reported that the A2A project had passed 150 supporting organizations, gained major cloud platform integrations, and reached production deployments across multiple industries. But "supported by" is not the same thing as "deeply used in production by most developers." Protocol ecosystems often look larger in press releases than they feel in day-to-day engineering work. Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively into their platform offerings. That is the signal worth paying attention to. When the three major cloud platforms all ship native support for the same protocol, it stops being optional for teams building on those platforms. It becomes the default. IBM's independently developed Agent Communication Protocol merged with A2A in 2025, with DeepLearning.AI and IBM Research co-building an official A2A course with Google Cloud in February 2026. Protocol mergers are rare. When a competing standard with real enterprise backing folds into yours, it is a meaningful signal that the ecosystem is consolidating. MCP hit 97 million monthly SDK downloads and 10,000 deployed servers by its first anniversary in November 2025. The April 2026 shift is that the ecosystem is now acting like real infrastructure: registries, working groups, auth, task lifecycle, and enterprise rollout details are getting more attention than protocol hype. A2A is about 12 to 18 months behind MCP on that maturity curve. Which means now is the right time to understand it, not after it is the default assumption in every job description and architecture diagram. What It Looks Like in Code Here is the minimal A2A interaction between two agents. A client agent discovers a remote agent via its Agent Card and delegates a task: python import httpx import json # Step 1: Discover the remote agent's capabilities via its Agent Card async def discover_agent(agent_url: str) -> dict: async with httpx.AsyncClient() as client: response = await client.get(f"{agent_url}/.well-known/agent.json") return response.json() # Step 2: Send a task to the remote agent async def delegate_task(agent_url: str, task_input: dict) -> dict: payload = { "jsonrpc": "2.0", "method": "tasks/send", "id": "task-001", "params": { "id": "task-001", "message": { "role": "user", "parts": [ { "type": "text", "text": json.dumps(task_input) } ] } } } async with httpx.AsyncClient() as client: response = await client.post( f"{agent_url}/a2a", json=payload, headers={"Authorization": f"Bearer {get_oauth_token()}"} ) return response.json() # Step 3: Check task status and retrieve artifact async def get_task_result(agent_url: str, task_id: str) -> dict: payload = { "jsonrpc": "2.0", "method": "tasks/get", "id": "get-001", "params": {"id": task_id} } async with httpx.AsyncClient() as client: response = await client.post(f"{agent_url}/a2a", json=payload) result = response.json() # artifact contains the remote agent's output return result["result"]["artifacts"][0] # Usage: orchestration agent delegates to invoice processing agent async def process_invoice_workflow(invoice_data: dict): invoice_agent_url = "https://agents.internal/invoice-processor" # discover what the agent can do card = await discover_agent(invoice_agent_url) print(f"Agent: {card['name']} {card['description']}") # delegate the task task = await delegate_task(invoice_agent_url, invoice_data) task_id = task["result"]["id"] # retrieve the result artifact = await get_task_result(invoice_agent_url, task_id) return artifact["parts"][0]["text"] The orchestration agent does not know anything about how the invoice processing agent is implemented. It knows the URL, the interface, and the OAuth token. That is the whole integration surface. Compare that to the custom handoff functions we were writing before functions that knew about the internal data structures of both agents, broke every time either agent changed its output format, and had to be updated in sync across both codebases. The Agent Card that the invoice processing agent hosts looks like this: json { "name": "Invoice Processor Agent", "description": "Processes invoice data and returns structured line items, totals, and vendor information", "url": "https://agents.internal/invoice-processor", "version": "1.2.0", "capabilities": { "streaming": false, "pushNotifications": false }, "skills": [ { "id": "process-invoice", "name": "Process Invoice", "description": "Accepts raw invoice data and returns structured extraction", "inputModes": ["text"], "outputModes": ["text"] } ], "authentication": { "schemes": ["oauth2"] } } Any A2A-compatible client can read that card and know what to send and what to expect back. No documentation required. No Slack message asking "what format does your agent expect?" The card is the contract. The Real Friction Points Nobody Mentions in the Announcement Posts Early adopters report compliance blind spots who approved that token and when latency added by cross-agent orchestration, and the operational overhead of adding another standard into pipelines. The token problem is the one worth spending time on. When Agent A delegates to Agent B, which token does Agent B use to call downstream services? Does it use its own service identity? Does it propagate Agent A's token? If Agent B's token grants broad access because it was scoped for Agent B's full range of capabilities, and Agent A delegates a narrow task to it, you have an over-permission problem that does not exist in a single-agent architecture. The security architecture includes OAuth 2.0, PKCE to eliminate authorization code interception vulnerabilities, dynamic client registration, and Resource Indicators from RFC 8707 to close the token leakage vulnerability where a rogue server could trick a client into obtaining tokens valid for other services. These controls are in the spec. Actually implementing them correctly in your agent infrastructure is still real engineering work. The latency point is also real. Every A2A handoff adds an HTTP round-trip. For tasks that take seconds anyway, that round-trip is noise. For tasks that are latency-sensitive anything in a synchronous user-facing flow you need to think carefully about which delegations are worth the overhead and which should stay in-process. Many AI agent demos in 2025 did not need A2A at all. They needed better prompts, better tools, better permissions, better retry logic, and better logs. That is probably the most useful line in the whole A2A discourse. If you have two agents that you control, run in the same codebase, and never need to swap out independently, A2A is overhead. The protocol earns its value when agents come from different teams, different vendors, or different frameworks and need to interoperate without anyone writing custom glue code every time the integration changes. MCP and A2A Together: The Full Picture The cleanest mental model for where these two protocols fit: MCP connects an agent to the world outside itself databases, APIs, tools, file systems, external services. When your agent calls a tool, that is MCP. A2A connects agents to each other delegation, coordination, parallel workstreams, specialist handoffs. When your orchestration agent asks a specialist agent to handle a subtask and waits for the result, that is A2A. A production multi-agent system in 2026 needs both layers. MCP so each agent can do meaningful work. A2A so agents can divide that work between them without custom integration code holding the whole thing together. The cleaner way to think about the market now: MCP is the tool layer, A2A is the cross-agent layer, and both are still early enough that you should keep your implementation thin. That last part matters. The spec is stable enough to build on. The ecosystem is still maturing. Keep your A2A integration surface minimal, verify signatures and tokens properly, and do not abstract it so heavily that when the protocol evolves you cannot update your implementation without a rewrite. What to Do With This Right Now If you are running a single agent or a small fixed set of agents that you fully control, A2A is not urgent. Monitor it. Read the spec. Build an opinion. If you are building a platform where multiple teams will deploy agents that need to interoperate, or if you are buying agent capabilities from vendors who might be building on different frameworks, A2A is worth implementing now. The cost of retrofitting interoperability into a multi-agent system after it is in production is significantly higher than building to the standard from the start. The glue code problem is real. We wrote it. We maintained it. We watched it break every time either end of the integration changed. A2A is not magic it still requires real engineering, real token management, and real latency awareness. But it is a standard, and building to a standard beats building custom bridges to every agent you will ever need to connect. References Apono What Is Agent2Agent (A2A) Protocol and How to Adopt It? (October 2025) https://www.apono.io/blog/what-is-agent2agent-a2a-protocol-and-how-to-adopt-it/ IBM Think What Is the Agent2Agent Protocol? (November 2025) https://www.ibm.com/think/topics/agent2agent-protocol Galileo Google Agent2Agent Protocol Explained (January 2026) https://galileo.ai/blog/google-agent2agent-a2a-protocol-guide Atlan Google A2A Protocol: How Agent-to-Agent Coordination Works (May 2026) https://atlan.com/know/google-a2a-protocol/ Rost Glukhov Google A2A Protocol in 2026: Adoption, Hype, and Reality https://www.glukhov.org/ai-systems/comparisons/a2a-protocol-2026-adoption DEV Community Building Multi-Agent AI Systems in 2026: A2A, Observability, and Verifiable Execution (April 2026) https://dev.to/chunxiaoxx/building-multi-agent-ai-systems-in-2026-a2a-observability-and-verifiable-execution-10gn DEV Community Google's A2A Protocol: How AI Agents Communicate Across Frameworks (April 2026) https://dev.to/agentsindex/googles-a2a-protocol-how-ai-agents-communicate-across-frameworks-52jj BuildMVPFast 2026 AI Engineer Stack: MCP and A2A Protocol Guide for Builders (April 2026) https://www.buildmvpfast.com/blog/ai-engineer-stack-2026-mcp-a2a-protocol Zylos Research Agent Interoperability Protocols 2026: MCP, A2A, ACP and the Path to Convergence (March 2026) https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence/ Platform Engineering Google Cloud Unveils Agent2Agent Protocol: A New Standard for AI Agent Interoperability (December 2025) https://platformengineering.com/editorial-calendar/best-of-2025/google-cloud-unveils-agent2agent-protocol-a-new-standard-for-ai-agent-interoperability-2/ Ruh.ai AI Agent Protocols 2026: Complete Guide (May 2026) https://www.ruh.ai/blogs/ai-agent-protocols-2026-complete-guide arxiv.org Security Threat Modeling for Emerging AI-Agent Protocols: A Comparative Analysis of MCP, A2A, Agora, and ANP https://arxiv.org/pdf/2602.11327 \