Agent-to-Agent Communication: How AI Agents Work Together
How AI agents communicate and delegate work: internal hand-offs versus cross-system protocols, the A2A protocol's Agent Cards, tasks, messages and artifacts, how A2A relates to MCP, security and when it is worth it.
Quick answer
Agents communicate in two ways. Inside one application, an orchestrator passes structured tasks and results between agents through shared state, which is simpler and easier to control. Across teams, vendors or organizations, a protocol helps: A2A (Agent2Agent) lets an agent discover another through its Agent Card (served at /.well-known/agent-card.json), check its skills and authentication, send it messages and tasks, and receive results as artifacts. A2A complements MCP, which connects agents to tools and data. Treat every remote agent as an untrusted service.
Where This Fits
Whether you need several agents at all is covered in single-agent vs multi-agent systems, and coordinating them in one application in AI agent orchestration. Connecting agents to tools is MCP.
Internal Hand-offs vs Cross-System Protocols
| Internal hand-off | Cross-system protocol (A2A) | |
|---|---|---|
| Agents built by | One team, one codebase | Different teams, vendors or companies |
| Communication | Function calls, shared state | HTTP-based messages and tasks |
| Discovery | Known at build time | Agent Cards |
| Trust | Same security boundary | Separate boundaries; authenticate and authorize |
| Best for | Most multi-agent applications | Interoperability between independent agents |
How A2A Works
A2A is an open protocol introduced by Google in 2025 and hosted by the Linux Foundation since June 2025. In outline, as described in the A2A specification:
- Discovery: each agent publishes an Agent Card describing its identity, skills, endpoint, interaction modes and authentication requirements
- Messages: the client agent sends a message with parts (text, files, structured data)
- Tasks: longer work is tracked as a task with a lifecycle and status updates
- Artifacts: the remote agent returns outputs as artifacts
- Transport: standard web technologies, with streaming and asynchronous updates for long-running work
A2A vs MCP
MCP and A2A are often confused because both are about agents and interoperability. MCP standardizes how an AI application reaches tools, resources and prompts: deterministic capabilities. A2A standardizes how one agent asks another agent, which has its own reasoning, tools and policies, to do work. A travel agent might use MCP servers for flight search and payments, and A2A to delegate visa questions to a partner's specialist agent.
Connecting your agents to partners' or vendors' agents?
ZSpace Labs can assess whether A2A or a simpler integration fits, and build secure agent-to-agent connections where they add value.
Designing Agent Conversations
Whether internal or via A2A, agents communicate best with structured contracts: clear task descriptions, required inputs, expected output formats and deadlines. Avoid passing whole conversation transcripts; send what the receiving agent needs. Track task status explicitly so the caller knows whether to wait, retry or escalate.
Security and Trust
- Authenticate remote agents using the schemes in their Agent Cards and verify their identity
- Authorize every incoming task against your own policies
- Share the minimum data needed; never send credentials
- Treat returned artifacts and messages as untrusted input
- Validate artifacts against schemas before using them
- Log every exchange with both agents' identities
- Keep human approval for consequential actions that remote agents request
When A2A Is Worth It
A2A earns its complexity when agents genuinely belong to different owners: a company exposing a specialist agent to customers' agents, enterprises connecting agents across business units with separate platforms, or marketplaces of agents. For agents within one product, internal orchestration remains simpler and easier to secure.
Advantages and Limitations
Standard agent communication enables reuse and collaboration across organizational and vendor boundaries. The protocol and its ecosystem are still maturing, implementations vary, debugging spans systems you do not control and trust between agents must be established carefully. Start with a narrow, well-defined skill.
How to Implement Agent Communication Step by Step
- 1. Decide if agents share an owner; if so, use internal orchestration
- 2. Define skills and contracts for cross-boundary work
- 3. Publish or consume Agent Cards with authentication requirements
- 4. Implement tasks with status tracking and timeouts
- 5. Validate artifacts and limit shared data
- 6. Trace exchanges across both sides where possible
- 7. Pilot one skill before broadening
What an Agent Card Describes
An Agent Card is how one agent learns what another can do and how to reach it. The simplified example below shows the kind of information it carries; field names and structure follow the A2A specification, which has evolved across versions, so use the current specification and an official SDK rather than this sketch.
{
"name": "Shipment Exception Agent",
"description": "Investigates delayed or failed shipments and proposes resolutions.",
"url": "https://agents.example-logistics.com/a2a",
"version": "1.4.0",
"capabilities": { "streaming": true },
"authentication": "OAuth 2.0 (client credentials)",
"skills": [
{
"id": "resolve-exception",
"name": "Resolve shipment exception",
"description": "Given a shipment reference, returns cause, options and a recommended resolution.",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
}
]
}Use Cases for Cross-Organization Agents
| Scenario | Requesting agent | Remote agent |
|---|---|---|
| Logistics | Customer's procurement agent | Carrier's exception agent |
| Travel | Corporate travel assistant | Airline or hotel booking agent |
| Financial services | Business finance agent | Bank's account services agent |
| Enterprise IT | Department agent | Central IT provisioning agent |
| Software platforms | Customer's AI assistant | Vendor's product support agent |
Worked Example
An illustrative scenario, not a client case: a logistics provider exposes a 'shipment exception resolution' agent for large customers. Customers' procurement agents discover it through its Agent Card, authenticate with OAuth and submit tasks with shipment references. The logistics agent returns structured resolution artifacts; customer-side agents validate them and route anything involving cost changes to a person.
Common Mistakes
- Using a cross-system protocol for agents in one codebase
- Trusting remote agents' outputs without validation
- Sharing more data than the task needs
- No task status or timeout handling
- Confusing MCP and A2A roles
Exploring agent interoperability?
Talk to ZSpace Labs about multi-agent and A2A development and secure API infrastructure.
Conclusion
Agents work together through orchestration inside one system and through protocols like A2A across systems. Keep contracts structured, trust explicit and the simpler option first. Related: MCP, agent orchestration and single vs multi-agent.
Common questions
The exchange of tasks, messages and results between AI agents, either inside one application through an orchestrator or across systems and organizations through a protocol such as A2A.