Most organisations won’t end up with a single AI agent. They’ll have dozens, built on different platforms by different teams, and none of them will understand each other unless someone decides they should.
That’s the problem the Agent2Agent protocol (usually shortened to A2A) is meant to solve. It’s an open standard that lets one agent hand off work to another, regardless of the platform either agent was built on.
Microsoft Copilot Studio now supports it, so a Copilot Studio agent can delegate tasks to agents that live outside it.
This guide explains what A2A is, how the connection works, where it fits alongside MCP and the other options, and what to settle before you let agents start passing work to each other.
Why Agents Need a Common Language
An agent that works alone is easy to reason about. It has one job, one set of tools and one owner. The trouble starts when a different team builds the useful agent for a task, on a different framework, or a supplier you don’t control.
The old answer was a custom integration for every pair of agents, which quickly becomes painful.
A shared protocol means any agent that speaks it can be reached the same way. We covered the tool side of this in our guide to connecting Copilot Studio agents to external data with custom MCP servers. A2A deals with the other half: agents talking to agents, not agents talking to data.
What Is the A2A Protocol?
According to Microsoft’s documentation, A2A is an open standard for communication and collaboration between agents. It defines a standard contract that lets an orchestrator send tasks to external agents, pass along structured metadata and receive responses in a predictable format.
The practical difference from a plain API call is that A2A is designed for agent workflows. It supports multi-turn interactions and carries rich context with each request, so the receiving agent knows more than a single question.
Microsoft’s own wording is that Copilot Studio can delegate tasks to another agent, not just call an API.
How A2A Works in Copilot Studio
In Copilot Studio, the agent you build acts as the orchestrator. When a user asks for something or a trigger fires, the orchestrator decides whether to handle it itself or hand it to a connected agent. If it selects an A2A agent, it sends the task over the protocol and waits for the result.
Every external agent publishes an agent card, a brief description of who it is and what it can do. Copilot Studio reads that card to understand the agent.
That’s why a valid card matters. If it’s missing or published in the wrong place, setting up the connection becomes much harder, and the orchestrator has less to go on when deciding whether to use the agent.
Connecting an A2A Agent Step by Step
The setup is short once the external agent is reachable. According to Microsoft’s guide to connecting an A2A-enabled agent, the steps look like this:
1. Open your orchestrator agent in Copilot Studio, then select Agents
2. Select Add an agent
3. Choose Connect to an external agent, then select Agent2Agent
4. Enter the agent’s endpoint URL. Copilot Studio retrieves the agent card and fills in the name and description
5. Select or create a connection, then select Add and configure
Before you start, check three things. The agent must be publicly reachable, or reachable via an on-premises data gateway if it is in a private network. You need permission to create solutions and agents in your Power Platform environment.
Because A2A connections use the custom connector infrastructure, Microsoft notes that you can also reach A2A agents running on-premises or within a virtual network.
For a hands-on example, the Copilot Studio community quickstart walks through connecting a sample agent and inspecting what Copilot Studio sends with each request.
A2A, MCP and the Other Ways to Connect
Copilot Studio gives you several ways to extend an agent, and they aren’t interchangeable. Microsoft’s guidance can be summed up like this:
| You want to connect | Best fit |
| An agent that already speaks A2A, built elsewhere or hosted outside Copilot Studio | A2A connection |
| Tools, data or resources | MCP server |
| An agent built with the Microsoft 365 Agents SDK | Activity Protocol |
| A basic API or HTTP service | Custom connector or HTTP tool |
You can combine these in a single Copilot Studio agent, so it isn’t an either-or choice. Our guide to the Dynamics 365 ERP MCP server shows the tool side in action, and A2A sits alongside it rather than replacing it.
Child Agents, Connected Agents and A2A
The word “agent” is used loosely here, so it helps to distinguish three ideas. Child agents are lightweight agents that run within your existing agent.
Connected agents are other agents in your environment, such as other Copilot Studio agents, Microsoft Foundry agents, Fabric data agents, or agents built with the Microsoft 365 Agents SDK. A2A agents are external agents accessed via the open protocol.
As a rough guide, keep things within a single agent where possible. Use connected agents when the capability already exists in your Microsoft estate.
Reach for A2A when the agent sits on another framework or belongs to another organisation. Microsoft’s multi-agent announcement describes the aim as agents working as a coordinated system rather than in isolated silos.
Security and Governance
This is the part we’d ask any security lead to read twice. Microsoft is explicit that when you connect to agents outside Copilot Studio, you’re responsible for how they’re used.
That includes ensuring that data flows and data sharing between agents are appropriate and meet your legal requirements, and that the agents meet suitable standards for quality, reliability, and security.
In plain terms, connecting an agent means trusting it with the task and with any context you pass along. Before you do, ask what data the orchestrator will send, who owns the receiving agent, and what that agent does with the information.
Give each agent its own identity, its own permissions and a record of what it did. We explain that in our guide to securing AI agents with Microsoft Entra ID, and the wider principles in responsible AI in practice.
Availability and Cost
Status labels have varied. Microsoft’s multi-agent announcements describe A2A support as generally available, while some pages in the Copilot Studio documentation still list connecting to A2A agents as public preview.
The honest answer is that it depends on your tenant and rollout, so check the current status in your environment and test in a non-production setup first.
Regarding cost, Copilot Studio agents run on consumption-based Copilot Credits, so each additional agent that joins a workflow can add to the bill. Someone needs to own that budget.
We haven’t included figures here because rates and terms change, so confirm the current position with your Microsoft partner.
What Has to Be Right First
Most of the work sits in the basics, as with any agent project.
- Clear agent descriptions. The orchestrator decides what to delegate based on what each agent says it does, so vague descriptions lead to poor routing
- A valid agent card. The external agent should publish one at the expected path so Copilot Studio can read it
- Reliable hosting and authentication. The endpoint must be reachable and secured, with keys or credentials handled properly
- Tight permissions. Each agent should access only what its job needs
- A named owner. Someone responsible for each agent, including the ones you didn’t build
- A narrow start. One orchestrator, one external agent and one workflow in a sandbox before anything touches live processes
If you’re building the agent side, our piece on building AI agents in the Power Platform covers the basics, and our guide to Copilot Cowork shows another place where delegated work is heading.
For the wider picture of agents in business systems, see our guide to agentic ERP in Dynamics 365, and you’ll find more on our blog.
Final Thoughts
A2A isn’t about building more agents. It’s about letting the agents you already have, or rely on, work together without a custom integration for every pair. Copilot Studio gives you a sensible way to add the endpoint, read the agent card, and start with one narrow workflow.
Success is rarely decided by the protocol. It’s clear descriptions, sensible permissions, honest testing, and a named owner for every agent in the chain.
If you’d like help planning and building multi-agent solutions, our D365 integration team can connect the systems, and our AI Enablement Programme takes teams from first experiment to production without the usual false starts.
As an ISO 27001-certified Microsoft partner, we ensure governance is in place before an agent touches live business data. Book a free assessment, and we’ll tell you honestly where to begin, no hard sell.
Frequently Asked Questions
What is A2A in Copilot Studio?
A2A is the Agent2Agent protocol, an open standard for communication between agents. In Copilot Studio, it lets your agent send tasks to external agents that support the protocol and receive responses in a predictable format.
How do I connect an A2A agent to Copilot Studio?
Open your agent, go to Agents and select Add an agent, then choose Connect to an external agent and select Agent2Agent. Enter the endpoint URL, and Copilot Studio reads the agent card and fills in the name and description.
What is the difference between A2A and MCP?
MCP connects an agent to tools, data and resources. A2A connects an agent to another agent so it can delegate tasks. You can use both in the same Copilot Studio agent.
Can I connect agents hosted on-premises?
Yes. A2A connections use the custom connector infrastructure, so agents on-premises or inside a virtual network can be reached, for example through an on-premises data gateway.
Is A2A in Copilot Studio ready for production?
Microsoft’s announcements describe multi-agent capabilities as generally available, but some documentation pages still label A2A connections as preview. Check the current status for your environment and test in a sandbox first.
