A2A Protocol: Cross-Platform Agent Collaboration

What is the A2A protocol?

Simple explanation

Think of A2A like a universal translator for AI agents.

Right now, agents from different companies speak different languages — a Salesforce agent cannot talk to a Copilot Studio agent because they were built on different platforms. A2A (Agent-to-Agent) is an open standard that gives every agent a “business card” (called an agent card) describing what it can do. Any agent that reads the card knows how to start a conversation.

It is like international diplomacy: ambassadors carry credentials, speak through a common protocol, and can collaborate even though they come from different countries. A2A does the same for AI agents across Google, Microsoft, Salesforce, SAP, and anyone else who adopts the standard.

A2A core concepts

Four building blocks make the protocol work. Understanding these is essential for the exam.

Concept	What it is	Analogy
Agent card	A JSON file hosted at a well-known URL (e.g., `/.well-known/agent.json`) describing the agent’s capabilities, supported tasks, and authentication requirements	A business card — tells you what the agent does and how to contact it
Task	A unit of work with a lifecycle: submitted, working, completed, failed, cancelled	A work order — created by the requesting agent, processed by the receiving agent
Message	Structured communication between agents within a task — questions, updates, results	An email thread — back-and-forth within the context of a task
Artifact	Output produced by a task — files, data, structured results	A deliverable — the finished work product attached to the completed task

Deep dive: what is in an agent card?

An A2A agent card is a JSON document at a well-known URL that includes:

name and description — what the agent does
capabilities — what tasks the agent can perform (e.g., “CRM lookup”, “lead scoring”)
authentication — how to authenticate (OAuth, API key, etc.)
endpoint — where to send task requests
supported content types — what data formats the agent accepts and returns

When Copilot Studio connects to an A2A agent, it reads this card to understand what the agent can do and how to communicate with it. The agent card is the discovery mechanism — without it, agents cannot find each other.

Connecting an A2A agent in Copilot Studio

The integration is straightforward because A2A is a standardised protocol:

Get the agent card URL from the external agent’s team (e.g., https://agents.salesforce.com/.well-known/agent.json)
In Copilot Studio, open your agent and go to Settings then Connected agents
Add then A2A agent — paste the agent card URL
Copilot Studio reads the agent card and discovers the agent’s capabilities, authentication, and endpoint
Configure authentication — provide credentials if the external agent requires OAuth or API keys
Set trigger descriptions — define when your orchestrator should route to the A2A agent
Test the connection — send sample requests and verify task lifecycle (submitted → working → completed)

Scenario: Priya connects to a client's Salesforce A2A agent

AgentForge’s recruitment client uses Salesforce as their CRM. The Salesforce team has built an A2A-compliant agent that can look up candidate records, update pipeline stages, and pull hiring analytics. Instead of building a custom connector to replicate Salesforce’s CRM logic, Priya takes a smarter approach.

She asks the Salesforce team for their agent card URL: https://crm.recruiting-corp.com/.well-known/agent.json. In her Copilot Studio orchestrator, she adds this as an A2A connected agent. Copilot Studio reads the card and discovers the agent can handle “candidate lookup”, “pipeline update”, and “hiring analytics” tasks.

Priya configures the trigger: “CRM queries, candidate records, pipeline status, hiring metrics.” Now when a recruiter asks “What stage is the Sarah Chen application at?”, the orchestrator routes to the Salesforce A2A agent, which queries the CRM and returns the result — all through the Teams interface.

The beauty: if the Salesforce team updates their agent’s capabilities (adds “interview scheduling”), the agent card automatically reflects it. Priya’s integration picks up new capabilities without code changes.

A2A vs MCP — two protocols, different purposes

The exam expects you to distinguish between A2A and MCP. They solve different problems.

A2A vs MCP — agent-to-agent vs agent-to-tool
Feature	Purpose	Communication pattern	Discovery	Use case
A2A (Agent-to-Agent)	Agent talks to another agent — peer collaboration	Task-based: submit task → agent processes → return result with lifecycle tracking	Agent cards (JSON at well-known URL) describe capabilities	Cross-platform agent orchestration — Copilot Studio agent routes to Salesforce agent, SAP agent, etc.
MCP (Model Context Protocol)	Agent talks to a tool — extending what an agent can do	Tool invocation: agent calls a function → tool returns result	Tool manifests (JSON) describe available functions and parameters	Giving an agent new abilities — file system access, database queries, API calls, code execution

Exam tip: A2A = agents talking to agents, MCP = agents using tools

The simplest way to remember: A2A connects agents that think; MCP connects agents to tools that do. If the exam describes connecting to an external AI agent (Salesforce bot, Google agent, SAP assistant), A2A is the answer. If it describes giving an agent access to a database, file system, or API function, MCP is the answer.