1.3.2. Agent-to-Agent Protocol (A2A)
💡 First Principle: A2A does for agents what HTTP did for websites — it lets strangers cooperate. Two agents built by different teams, on different platforms, with different internal designs can still discover each other's capabilities and exchange work, because the protocol standardizes the conversation between them without standardizing what is inside them.
A2A is open and cross-vendor — originated by Google and now stewarded under the Linux Foundation, with Microsoft among its backers. Its core ideas: each agent publishes an agent card, a machine-readable description of its identity, capabilities, and endpoint; a client agent reads the card, then sends a task to the remote agent; the protocol manages the task's lifecycle — submitted, working, completed — including multi-turn exchanges where the remote agent asks for clarification. The remote agent remains a black box: it advertises what it can do, never how.
Why should a Copilot Studio builder care? Because enterprises are not single-vendor. Your procurement agent in Copilot Studio may need to negotiate with a supplier's ordering agent built on an entirely different stack. A2A is the answer the exam expects whenever collaboration must cross platform or organizational boundaries — reserve same-tenant, same-platform collaboration for connected agents, which Phase 2 covers in depth.
⚠️ Common Misconception: A2A is a Microsoft-proprietary protocol. It is deliberately the opposite — an open standard whose whole value is that no single vendor owns the space where agents meet.
Reflection Question: Why does A2A need agent cards at all — what breaks in cross-platform collaboration if capability discovery is left to documentation and manual configuration?
