Main Components of A2A
Learn about the primary components that form the backbone of A2A architecture.
We'll cover the following...
When agents collaborate, everything depends on structure. Without a shared way to discover, communicate, and coordinate, even the most intelligent agents can talk past each other or work at cross-purposes. A2A solves this by providing every agent with a predictable way to introduce itself, exchange information, and manage work, regardless of who built it or what framework it runs on.
These three ideas: Agent Cards, communication patterns, and the task and message model form the backbone of the A2A architecture. Each plays a distinct role, but they provide agents with a common foundation to build upon. Once you understand these building blocks, everything from simple one-off calls to complex multi-agent workflows, starts to make sense.
We’ll break down the core architecture and walk through its main components.
How does A2A work?
Before proceeding, let’s review what happens in an A2A interaction once again to clarify any misunderstandings. As mentioned below, there are two primary roles.
A2A client (client agent): The agent or application that initiates a request on behalf of a user. This “orchestrator” agent determines what needs to be done and identifies which other agent has the necessary skills. It formulates tasks and sends requests using the A2A protocol.
A2A server (remote agent): The agent that exposes an HTTP endpoint implementing the A2A protocol (often running as a web service). It listens for incoming client requests, processes the task, and returns results or status updates. The remote agent can be considered an opaque service as the client doesn’t need to know how it works internally, only what capabilities it offers. This makes treating another agent as an opaque-box “service” or tool easy.
This architecture is analogous to a client-server model: any agent can act as a client to request help from another agent acting as a server. Notably, an agent can be both; for example, a coordinator agent might accept user requests (server role) and, in turn, call other agents to fulfill subtasks (client role).
In UML sequence diagrams, an “alt” box indicates that the enclosed interactions are conditional or optional; they may or may not happen depending on the circumstances.
To make this more tangible, think about what happens ...