Why architecture matters here
A2A architecture matters because agents in isolation cannot cover every domain. A travel agent that needs to check a hotel's availability, a payment agent that needs to charge a card, a legal agent that needs to check a contract — each becomes vastly more useful when it can call peer agents. A2A is the plumbing that makes cross-vendor collaboration safe and standardized.
Security dominates the architecture. Every A2A call gives one agent power to invoke another. Without strict authentication, budget caps, and policy enforcement, one compromised agent takes down its counterparties. The standardized protocol makes it possible to enforce policy consistently instead of per-integration.
Cost accounting is the third driver. Cross-vendor calls cross billing boundaries; both sides need to attribute cost to the requesting agent, tenant, and workflow. Signed messages plus standardized headers make this tractable.
The architecture: every piece explained
Walk the diagram top to bottom.
Agent A (sender). Has a goal that requires capability not in its own toolkit. Discovers a peer that can help.
Discovery. Well-known URLs (/.well-known/agent.json), public agent registries, or direct configuration. The sender fetches the recipient's agent card.
Agent B (receiver). Advertises itself via the agent card. Runs an HTTPS endpoint accepting A2A messages.
Agent Card. JSON metadata: name, description, capabilities (tools + skills), auth requirements, service endpoints, versioning. This is what a sender consults to know if it can talk to the receiver.
Auth Handshake. Depending on the card, OAuth 2.0 (for user delegation), JWT with signed claims, or mTLS. Auth binds the request to a specific requesting identity and tenant.
Task Message. Sender posts the task with a JSON payload: goal, inputs, budget limits, deadline. The receiver validates the request and returns either an immediate result or a task ID for async work.
Streaming Updates. For long-running tasks, the receiver streams progress via SSE or streaming JSON-RPC. The sender can display status, cancel, or provide feedback.
Task Result / Error. Final artifact, structured error, or partial result depending on outcome. Result includes attribution: which agent did the work, cost, duration.
Signed Message Bus. Every A2A message is signed. Audit trails record the chain of delegation. Non-repudiation protects both sides during disputes.
Policy + Guardrails. Which agents in your organization are allowed to call which external agents? Per-agent budget caps. Per-call rate limits. This is the layer that prevents runaway or malicious agent-to-agent calls.
Observability. Cross-agent traces (extend W3C Trace Context beyond your walls with vendor-neutral IDs), cost attribution, SLAs enforced by both sides.
End-to-end A2A call flow
Trace an A2A call. A travel-planning agent needs to book a hotel. The agent knows a peer agent at Booking has a "search_and_book_hotel" skill.
The travel agent fetches Booking's agent card. It confirms the capability exists, notes the required OAuth scope, and initiates OAuth if not already authorized. The user (upstream) approves the delegation.
The travel agent posts an A2A task: goal = book hotel in Munich for 2 nights, budget = $400, deadline = 30 seconds. Booking receives, validates budget against user's account, and confirms.
Booking begins the task. Every 2 seconds it streams a progress update: "searching properties", "found 15 candidates", "checking availability", "confirming booking". The travel agent shows the user a spinner with real-time status.
Booking finishes: returns a task result with confirmation number, price, and receipt. The signed message goes through the audit bus. The travel agent presents to the user; upstream accepts.
Cost attribution: Booking bills the travel-agent's tenant $2 for the search + booking; the travel agent's cost tracker records this. The user sees the total. Everyone knows where money went and who did what.