What Is the A2A Protocol for AI Agents? — Part 5

Most teams that adopt the A2A protocol still run more than one vendor's platform. That is the point. Google announced the project in April 2025, handed it to the Linux Foundation, and Microsoft now supports it in GitHub Copilot Studio and Azure AI Foundry. An agent on Google Cloud can serve an orchestrator running on Microsoft infrastructure.

Part 5 of a series. Start with What is the A2A protocol for AI agents?, then What Is the A2A Protocol for AI Agents?.

What problem does A2A solve?

A2A, short for agent-to-agent, is an open protocol that lets AI agents built by different vendors talk to each other directly. It fixes the isolation problem: a weather agent knows the forecast and a hotel agent knows room availability, but without a shared protocol they cannot combine that knowledge to answer one request. A2A gives them that shared language.

Think of it as HTTP for agents. HTTP is the language browsers and servers use to communicate; A2A does the same job for agents. An agent your IT team builds on Microsoft GitHub Copilot Studio can talk to an agent built by another company on Google Cloud, as long as both speak A2A.

The old workaround was custom code. You would write a bridge between the weather agent and the hotel agent, then another between the hotel agent and the flight agent, and another for the calendar agent. Every new agent adds another integration. Soon you have a spaghetti of point-to-point connections where one change breaks everything, and the productivity gains get eaten by maintenance work.

Which companies back A2A, and what version is stable?

A2A is sponsored by eight major companies, including Google, Microsoft, Cisco, Salesforce and SAP, and it is hosted by the Linux Foundation. That hosting matters: no single vendor controls the protocol. It is not a Google thing or a Microsoft thing; it is an industry thing. Version 1.0 is stable and ready for real use.

The design is deliberately simple. A2A builds on existing web standards like HTTP and JSON-RPC, tools every developer already knows. Nothing exotic or proprietary, which makes it easy for enterprises to adopt without ripping out their existing infrastructure. Authentication follows standard web conventions too: OAuth, API keys, bearer tokens. The agent card tells the client which method to use.

How does A2A differ from MCP?

MCP (Model Context Protocol) is agent-to-tool: it connects an agent to external data sources and APIs. A2A is agent-to-agent: it connects agents directly to each other. They are complementary, not competitors. Think of MCP as the vertical connection from an agent down to its tools, and A2A as the horizontal connection between agents side by side.

A2A also treats agents as opaque. When one agent talks to another, it does not see the other agent's internal reasoning, tools or private data. It only sees the task it sent and the result it gets back. That preserves privacy and intellectual property: a weather agent does not need to know how the hotel agent books rooms, it just needs to hand off the forecast.

What is an agent card?

Every A2A-compatible agent publishes an agent card, a machine-readable document at a standard URL on the agent's domain, specifically at /.well-known/agent-card.json. Think of it as a resume or business card. If you know where an agent lives, you can fetch its card and learn everything you need to work with it.

The card contains the agent's name, a plain-text description of its capabilities, and skill tags that help with discovery. It also lists the endpoint URL where it accepts requests, its authentication requirements, and its input and output formats. No secrets or internal logic are exposed, just a clear declaration of what the agent can do.

Discovery works like this: an orchestrator holds a list of known agent URLs, or you configure it with them. When a task comes in, the orchestrator fetches the agent cards, reads the descriptions and decides which agent is the best match. The weather card says weather, so weather tasks go there. No central registry is required: agents publish their card at a known location, and any agent that knows the URL can find them. That keeps the system decentralized, and you can add a new specialist by giving the orchestrator its URL.

How do agents hand off work?

The answers are simple: all communication happens over HTTP using JSON-RPC messages, the same standard that powers most web services today. Nothing custom, just standard web traffic. Not all tasks are the same, though, so A2A supports three interaction patterns.

Pattern	When it fits	How it works
Instant response	Quick lookups	The remote agent replies right away, e.g. today's forecast
Streaming	Longer tasks	Status updates via server-sent events until the final result lands
Async notification	Tasks taking minutes, hours or days	The client gets a task ID and moves on; the result arrives via webhook or polling

Every interaction is organized as a task. When the client sends a request, the remote agent creates a task and returns a task ID. That ID is the tracking handle for everything that follows: the client can poll it anytime. Messages inside the task have a role, telling you who sent it, and parts, which can be plain text, binary data like images or documents, JSON payloads or URLs pointing to files stored elsewhere.

What is the orchestrator-specialist pattern?

The orchestrator-specialist pattern is the most common architecture in production multi-agent systems today. A central orchestrator receives the user's request, figures out what needs to happen, and delegates each piece to a specialist. If a user asks to plan a trip to Seattle next week, the orchestrator does not book flights or check hotels itself. It breaks the request into flights, hotels and weather, and hands each to the specialist that owns that domain.

The important part: the orchestrator does not execute the tasks. It routes work and merges results. When you let the orchestrator start doing specialist work, you lose the whole benefit of the pattern and it becomes a monolithic mess again. Each specialist has a narrow focus, which keeps it simple, easy to maintain and easy to test. Need to swap out your hotel booking provider? Replace the hotel specialist without touching the orchestrator or any other agent.

Watch for one common mistake: overlapping specialist domains. If two agents both claim they can handle customer support or data lookup, the orchestrator does not know which one to pick and users get inconsistent results. The fix is straightforward: each specialist owns a clearly bounded domain, and if two agents can do the same thing, merge them or split the domain more cleanly.

How does Microsoft use A2A inside GitHub Copilot Studio and Azure AI?

GitHub Copilot Studio supports A2A natively and has been generally available since April 2026, not as a preview or beta. Your main GitHub Copilot acts as the orchestrator while child agents and connected agents act as specialists, so you do not have to code the orchestration logic from scratch.

Connecting an external agent takes a few steps:

1. In GitHub Copilot Studio, create a connected agent.
2. Paste in the agent's endpoint URL.
3. GitHub Copilot Studio fetches the agent card from /.well-known/agent-card.json automatically.
4. It reads the agent's capabilities, authentication requirements and input/output formats.
5. It builds a custom connector behind the scenes, and your orchestrator can start delegating tasks.

The orchestrator does not care where the agent lives or what framework built it. Azure AI Foundry Agent Service also supports A2A, with a dedicated A2A API endpoint that lets open-source orchestrators such as AutoGen, LangChain and Semantic Kernel invoke Foundry agents. If you built agents with those frameworks, you can plug them into the Microsoft ecosystem without rewriting anything.

What are the limitations of A2A in practice?

Three constraints are real, though manageable. First, every extra orchestration hop adds latency. If your main agent calls a connected agent and that agent calls another specialist, each hop adds network time, and for real-time conversations too many hops make the experience feel sluggish. Second, overdelegation creates routing chaos: too many specialists with overlapping domains lead the orchestrator to make bad routing decisions, so keep the specialist count manageable and the domains clearly separated. Third, Fabric data agents do not work when the main agent is deployed to Microsoft 365 GitHub Copilot, so plan accordingly if your deployment targets Microsoft 365.

What does A2A look like in a real workflow?

Take a simple request: plan a trip to Seattle next week. In the old way, a single assistant would have to know weather, flights, hotels and restaurants all at once, which means giant bloated prompts that break constantly. With A2A, the orchestrator sends a task to a weather specialist for those specific days, a flight specialist for flights arriving Tuesday morning and returning Thursday evening, and a hotel specialist for three nights near downtown. Each specialist works independently with its own data sources and tools. The orchestrator collects the results and merges them into one answer. The user sees a single response; behind the scenes, three agents worked together without any custom integration code.

In a business scenario, a ticket arrives: "My laptop won't connect to the VPN." The orchestrator identifies a network issue and hands it to a runbook specialist that knows the standard steps (check VPN client status, verify network credentials, restart the service). That specialist returns the steps, and the orchestrator passes the result to a ticket writer specialist that logs the resolution. All of this happens in seconds, and the IT team only gets involved if the automated steps don't fix the problem.

Employee onboarding takes days instead of seconds. The orchestrator triggers an IT specialist to create accounts and assign hardware, an HR benefits specialist for enrollment forms, and a facilities specialist for desk and badge access. Each runs its own long-running task, and the orchestrator tracks progress using the task IDs. If the facilities specialist is delayed, the orchestrator follows up. Coca-Cola Beverages Africa already uses GitHub Copilot Studio agents with Dynamics 365 to automate planning cycles. Their planners used to spend up to an hour and a half every day on repetitive tasks; with multi-agent orchestration those cycles run on their own, saving over an hour per person per day. As Mir Peters puts it in the walkthrough, you are not building one super-smart agent that knows everything. You are building a flexible workforce of specialists you can rearrange as your needs change.

Turn a spoken walkthrough into a written reference

A2A is easiest to understand as three moving parts working together: a card that describes an agent, a task that tracks a handoff, and an orchestrator that decides who does what. A good explanation follows that same order: someone walks through the pieces, and the listener comes away with a mental model they can reuse. Gustavo Doido covers this ground in his knowledge-nugget format, and the pattern holds for any technical walkthrough.

If you have already recorded that kind of walkthrough, the explanation exists in audio rather than in text where a team can search it, cite it, or hand it to a new colleague. The same holds for interviews, internal demos, and conference talks that never became a document.

You can paste a YouTube URL into Skala Blog, let the tool transcribe the video, and generate a structured article from the transcript. The recording becomes something a reader can skim and quote, while you keep the original talk as it was. Skalablog turns a YouTube video into a private draft you review before publishing, so the protocol explanation your audience needs can start as the conversation you already had.

Frequently asked questions

• What does A2A stand for? Agent-to-agent. It is an open protocol that lets AI agents built by different vendors talk directly to each other, pass work around and complete tasks as a team, hosted by the Linux Foundation.
• Is A2A the same as MCP? No. MCP connects an agent to tools and data sources; A2A connects agents to each other. They are complementary: MCP is the vertical link down to tools, A2A is the horizontal link between agents.
• Do agents need a central registry to find each other? No. Each agent publishes an agent card at a standard URL on its own domain, and an orchestrator that knows the URL can fetch the card and discover capabilities.
• Is A2A production-ready? Yes. Version 1.0 is stable, and GitHub Copilot Studio has supported A2A natively since its general availability in April 2026.
• What is the biggest pitfall when adopting A2A? Overlapping specialist domains and overdelegation. Keep each specialist's domain clearly bounded, let the orchestrator route rather than execute, and watch latency as orchestration hops accumulate.

Where to go next

Pick one repetitive process with clear handoffs (ticket resolution, employee onboarding, expense reporting) and build a prototype with one orchestrator and two specialists. You don't need a grand architecture, just a working example you can learn from. Map out where information currently passes between people or systems: every handoff is a candidate for an agent.

If you have a walkthrough like this one sitting in a video, the knowledge is already there, just not yet in a form your team can search and cite. Bring the video to Skala Blog and turn it into a written reference.

Source video