[3/x] Model Context Protocol (MCP) and Agent-to-Agent (A2A) - A2A architecture (AI column)

Continuing the story of protocols (1 and 2)This is how Google’s A2A protocol works. A2A architecture The client-server model also follows, but at the agent level. Here, the A2A client is one agent that initiates the task, and the A2A server is another agent that can perform the task. Unlike MCP, where the server is simply a data connector, in A2A, both ends of communication are intelligent agents with the potential for autonomous behavior. The A2A protocol defines a standard for how one agent can detect another, find out what the agent “can” do, and then transfer the task to the agent to perform the task and then obtain the result.

Technically, A2A is based on HTTP and JSON-RPC, complemented by the SSE event protocol for asynchronous messaging and streaming status updates. Every A2A agent exhibits an HTTP endpoint. (For example, a small web server) with the standard A2A API. So that agents can find each other and handle each other correctly, A2A introduces the concept of Agent Card. Agent Card is a JSON document published by the agent, where his name, address are indicated. (URL for connection), version, and most importantly - a list of his skills / abilities (Agent Skills) Describe what tasks he is able to perform. Other agents can get this carte blanche and figure out which agent to turn to.

Task sharing in A2A is done through Task, a standardized job description that the client-agent forms for the remote agent. The task includes context (e.g. user request)The required action and format of the expected response. Agents exchange messages (Messages) In the process of solving the problem, these can be implementation steps, clarifying questions, intermediate results. In the final response, so-called Artifacts can be transmitted – artifacts, such as files, images or other results of the agent’s work. The protocol supports streaming: if the task is long, the remote agent can send intermediate updates. (Performance status, partial results) via SSE until the task is completed.

Key A2A technical principles announced by Google and its partners: 1. Relying on existing standardsNot to invent new transport, but to use HTTP for compatibility with any web technologies, JSON-RPC for structured calls, SSE for streaming. This facilitates the integration of A2A into existing enterprise IT infrastructure. 2. Security by defaultThe protocol was originally developed with corporate security requirements in mind – it supports authentication and authorization of agents, similar to OpenAPI security schemes. Each agent may require verification of the key or token before receiving tasks, set permissions for actions to be performed, etc., to prevent unauthorized access. 3. Supporting long-term tasksArchitecture recognizes that agency interactions can take considerable time (hours or days if there is a person in the cycle). Thanks to the event model, A2A allows agents to maintain a dialogue about the progress of the task, notify about intermediate progress, expect external actions and then continue to work. 4. MultimodalityA2A is not limited to text – it provides for the transmission of audio and video streams if the agents work with these types of data. This is important, for example, for agents processing voice requests or video data. (They can also work together through a single protocol.).

Architecturally, A2A creates a superstructure over individual agents, transforming them into a single orchestra. For example, if the user assistant (agent) He can, through A2A, delegate subtasks to specialized agents: one agent books tickets and hotels, another handles payment, a third checks the compliance of the trip with corporate policy.

#AI #Engineering #Architecture #DistributedSystems #ML #Software