2.3.4. The A2A Protocol in Practice
💡 First Principle: Every integration so far assumed Microsoft plumbing on both ends. A2A removes that assumption: it is the connected-agent mechanism for peers your platform does not control — an agent on another vendor's stack, in another company's tenant — cooperating through a protocol instead of shared infrastructure.
Phase 1 gave the protocol's shape: the remote agent publishes an agent card describing identity, capabilities, and endpoint; your agent sends it tasks; the protocol manages the task lifecycle, including multi-turn clarification, while the remote agent stays a black box. In Copilot Studio, that materializes as adding an external A2A agent as a connected agent — the orchestrator then delegates to it exactly as it would to a Copilot Studio peer, and the protocol handles the distance.
Selection logic for the exam: within your environment, prefer child or connected Copilot Studio agents; for Microsoft pro-code and data specialists, connect Foundry and Fabric agents; the moment collaboration crosses platform or organizational boundaries — a supplier's ordering agent, a partner's logistics agent, an internal agent built on a non-Microsoft framework — A2A is the mechanism built for exactly that hop. Trust boundaries do real work here: you extend the remote agent no credentials to your systems; it acts entirely on its own side of the fence, which is precisely what makes cross-organization delegation governable.
| Connected agent type | Lives where | Best for | Watch out for |
|---|---|---|---|
| Child agent | Inside the parent | Grouping tools/intents, routing accuracy | Shares parent auth/config — no independence |
| Copilot Studio agent | Same platform | Cross-team reuse, separate ALM | Citations may not pass through; no dual parent/child roles |
| Foundry agent | Microsoft Foundry | Fine-tuned models, pro-code logic | Preview-era; Azure-side ownership |
| Fabric data agent | Microsoft Fabric | NL analytics over lakehouse/warehouse/KQL | No topic redirect/instructions reference; not for M365 Copilot deployment |
| A2A agent | Any platform, any org | Cross-vendor, cross-company delegation | Black-box trust — govern by contract, not configuration |
⚠️ Exam Trap: "The partner's agent runs on a different platform" is the A2A cue. Connected Copilot Studio agents require both agents in the Copilot Studio ecosystem; MCP is agent-to-tool, not agent-to-agent — both are planted distractors on cross-platform collaboration questions.
Reflection Question: Design the delegation chain: your Teams-deployed agent must answer warranty questions (your knowledge), check repair capacity at a partner's service network (their agent, non-Microsoft stack), and query your Fabric warehouse for purchase history. Name the mechanism for each hop and one constraint you must design around.
