How A2A (Agent2Agent Protocol) works in practice
Enterprise environments rarely run on a single agent framework: one department builds in LangGraph, another uses Microsoft Semantic Kernel, and external vendors run proprietary stacks. A2A provides an HTTP, JSON-RPC 2.0, and Server-Sent Events (SSE) communication layer so opaque agents can collaborate as peers without exposing their internal prompts, memory, or proprietary weights.
Discovery starts with an Agent Card, a standardised JSON metadata document typically hosted at `/.well-known/agent.json`. The Agent Card declares the agent's identity, version, supported input/output modalities, authentication requirements, and specific skills. When a client agent needs outside help, it reads the remote Agent Card and initiates a Task lifecycle (`submitted`, `working`, `input-required`, `completed`, or `failed`), exchanging structured Messages and output Artifacts over streaming or webhook push notifications.
For instance, a UK retail bank's internal procurement agent can use A2A to negotiate software renewal terms with a vendor's licensing agent, while simultaneously tasking an internal legal-review agent to verify FCA outsourcing clauses, with each agent operating inside its own security boundary.
Why it matters and trade-offs
Architecturally, A2A and MCP are complementary halves of the agentic stack: MCP is vertical plumbing (connecting an agent to tools, databases, and APIs), whereas A2A is horizontal plumbing (connecting specialist agents to other agents). Standardising on A2A prevents enterprises from building brittle, point-to-point REST wrappers every time two departmental agents need to hand off a long-running task.
The operational trade-offs involve network latency, distributed tracing complexity, and cross-boundary trust. Multi-agent conversations over HTTP multiply token consumption and make root-cause debugging harder when a task stalls in an `input-required` state. Teams should only use A2A when agents genuinely cross trust, runtime, or vendor boundaries; within a single codebase and process, local in-memory handoffs are faster and simpler to test.