Introduction

During these scorching August days, I took the opportunity to thoroughly read Google’s A2A protocol specification and try to understand how to use its concepts to design an enterprise Agent architecture, possibly free from technological or platform constraints.

What is A2A?

The Agent2Agent (A2A) Protocol is an open standard designed and publicly shared by Google to facilitate communication and collaboration among AI agents. The standardization of AI interoperability model is a topic that has been discussed since the very first moments when we started talking about Agents, and there are several reasons for this:

• extreme heterogeneity, both in terms of implementation, functionalities, and task execution models
• the trend towards specialization means that executing complex tasks will increasingly require collaboration between Agents
• many companies have already developed their first agent solutions, but to scale and extend them to new contexts, it’s essential to have a future-proof and open interoperability model. In the absence of a shared and stable standard, there’s a concrete risk of lock-in.

A2A identifies 5 fundamental elements to solve these problems:

The transport protocol

A2A provides 3 alternative transport protocols, all based on HTTPS, and establishes that an A2A-compliant agent must necessarily implement at least one of them

1. JSON-RPC 2.0
2. gRPC
3. HTTP+JSON/REST

The Agent Cards

This is the main tool for sharing the technical and functional features of agents according to a standard schema defined through the JSON language. The “Agent Cards” are like a sort of interface agreement exposed by the agent that, in addition to defining endpoints and technicalities for authentication and interoperability, also descriptively defines the agent’s purpose and capabilities (e.g., streaming support or push notifications). A2A requires that each agent must always expose its Agent Card so that it can be easily discovered and used by other agents and clients.

In a multi-agent context, a specific organization must therefore do 2 things:

1. define a way to expose these “Agent Cards” (as we’ll see, A2A suggests using a Well-known URI according to the RFC 8615 standard)
2. know at all times which AgentCards are available to the organization, where to find them, and possibly also their health status (healthy/inactive)

These 2 points can be synthesized through the concept of Discovery which, in my opinion, is not addressed exhaustively in the official specifications. These thoughts led me to consider the implementation of a home-made Agent Registry.

The task lifecycle

A2A classifies task types and defines their lifecycle. For example, a task could be completed with a single response message (stateless) or, more frequently, be a stateful object that transitions through different states. Clients can therefore refer to a task through a taskId returned by the agent throughout the lifecycle, which can also be long-lasting or require multiple interactions. Similarly, A2A provides that in the first response message, the agent also provides a contextId to manage the reference to the underlying LLM model context. The interesting thing is that the contextId can also go beyond the lifecycle of a single task. In this way, clients have the possibility to autonomously decompose some complex processes into simpler and self-consistent tasks referring to the same context known and stored by the agent.

Data exchange

A2A makes a distinction between:

• Messages: represent a single interaction or contextual information between a client and an agent. Messages always indicate the sender’s role (user or agent). They are mainly used for instructions, prompts, responses, and status updates.
• Artifacts: represent the actual output of the task and are therefore generated at the end of execution

Both messages and artifacts are composed of atomic units called parts, each of which can be of type TextPart, FilePart, or DataPart and can also contain metadata that helps describe their content.

Security and asynchronous interaction management

Agents must authenticate all requests, in compliance with the specifications defined in the SecurityScheme of their AgentCard. A2A provides that servers can implement authentication through the most common methods such as:

• OAuth 2.0
• API Key
• OpenAI
• HTTP Basic Auth
• Mutual TLS (mTLS)

The security theme is also important regarding Push Notifications, which is the mechanism that allows agents to send updates to clients proactively, through the setup of a dedicated Webhook by clients. A2A provides a Webhook validation process to prevent SSRF-type attacks.

Agent Discovery

Approaches for Agent Discovery provided in A2A

As mentioned before, according to A2A, each agent must produce an Agent Card according to the specifications indicated by the protocol itself. This document is therefore a foundational element for the Agent Discovery phase, which can be implemented in at least one of these 3 ways (but A2A also leaves room for other alternatives):

1. Use of Well-Known URI: Follows the principles of RFC 8615 according to which a particular path (".well-known") is reserved within URIs for sharing metadata about a specific web resource. In other words, starting from a domain (e.g., www.example.com) and from a resource exposed within such domain (e.g., “my_resource”), the RFC 8615 standard defines the concept of “Well Known URI” for the resource equal to http://www.example.com/.well-known/my_resource. According to the A2A protocol, AgentCards could therefore be exposed natively by Agent Servers through URIs like: https://{server_domain}/.well-known/agent-card.json (see Section 5.3).
2. Agent Registry: Querying a centralized catalog of agents, which can be public or private.
3. Direct configuration: Client applications can be pre-configured with all the information present in the Agent Card of the Agent Servers they need access to (for example with direct mapping of the AgentCard information in the application code).

Brief comparison

Referring to the 3 methods above, the third seems like brutal hard-coding of point-to-point configurations and is certainly not elegant and not scalable. Solution 1 is a mere technicality that simply refers to a standard for integration between systems on the WEB and by itself does not solve the problem at all, because client applications (or agents) do not know a priori which are the resources (i.e., the Agents) to search for and towards which to direct HTTP calls to the “well-known” paths. In my opinion, the only real solution is number 2, which is the use of a centralized registry, which allows:

• to Agents: to be shared and made available to the organization
• to clients: to know which agents are available and their interface characteristics

From my point of view, alongside these 2 basic macro-requirements, the Agent Registry could also provide some auxiliary functionalities to make the entire A2A ecosystem work, such as:

• a healthcheck mechanism, to know the agent’s health status
• a search engine for skills, but also for capabilities, tags, description, or provider name, …
• authorization rules for consultation and access to agents
• direct purchase for access to “premium” agents (Agent Marketplace)

However, A2A doesn’t define anything more about how these Agent Registries should be made and the specifications they should have. In fact, in the protocol specification it’s clearly written

The A2A protocol does not currently define a standard API for such registries, though this is an area of potential future exploration and community standardization

Open solutions for Agent Registry

As I wanted to design an agnostic and possibly “open” architecture, I did some research to identify any market tool that offer this type of functionality and, surprisingly, I found nothing. Even in the leading market platforms that promote the development of multi-agent architectures and enterprise-level agent applications, it seems to me (but I could be wrong) that at the moment there are a very few signs of openness towards this part of the A2A protocol. On the other hand, it seems natural that in this transition phase, the big players in the sector (hyperscalers and big tech) are trying to create a closed ecosystem, where each customer develops, publishes, and runs their own agents. In this scenario, it’s easy to imagine that there’s some resistance to standardizing and opening access to truly open and interoperable Agent Registries.

Given these considerations, I thought: “Okay, I’ll put in some effort and moreover, a bit of vibe-coding, and I’ll just build it by myself” 🛠️

Introduction to Agent-Reg

What is Agent-Reg?

Agent-Reg is a minimal and open-source implementation of an Agent Registry, in compliance with A2A specifications. It provides a centralized solution for the discovery and maintenance of A2A-compliant agents in a simple and interoperable way. You can find the code here: Agent-Reg GitHub Repository

The solution can be deployed anywhere and has been designed maintaining complete openness and platform independence. At its core, Agent-Reg solves the Discovery problem through:

• Universal Agent Discovery: A searchable catalog of all available agents
• A2A Protocol Compliance: Support for the Agent2Agent specification and complete validation during registration
• Health Monitoring: Real-time tracking of agent availability and status (heartbeat)
• Advanced Search: Multi-criteria search for skills, capabilities, ownership, and other descriptive attributes

Architecture Overview

The architecture is extremely simple and, although some implementation choices are not yet optimized for scalability (for example, the usage of SQLite), it provides a starting point on which to build your own customizations.

Macro Components

Backend

The backend was developed using FastAPI, a modern Python framework that provides automatic API documentation, type validation, and excellent performance. Other notable features:

• SQLite with JSON Extension for Data Storage: a lightweight and battle-tested database with NoSQL support via JSON, requiring zero additional infrastructure configuration. This makes deployment simple and provides sufficient performance for at least a PoC or a working prototype capable of handling several thousand objects.
• Strict A2A Schema Validation: Each agent registration is validated against the official A2A JSON Schema to ensure protocol compliance
• RESTful API Design: Clean and intuitive endpoints that follow OpenAPI 3.0 specifications

Frontend

The web interface is built with React 18 and TypeScript, providing a modern and responsive experience for agent management:

• Tailwind CSS: Simple and clean CSS framework
• Real-time Updates: Live monitoring of agent status and health
• Advanced Filtering: Intuitive search interface with multiple criteria

How Agent Registration Works

The agent registration process on Agent-Reg ensures that only valid agents compliant with A2A specifications can join the registry. Below is a sequence diagram illustrating the end-to-end registration flow:

When an agent wants to register with Agent-Reg, it must provide its Agent Card. The platform performs Agent Card validation to ensure compliance, rejecting the request if protocol requirements are not met. If validation is successful, the agent is registered in the system and a unique identifier is returned, which the Agent can later use to perform operations on the registry (e.g., heartbeat).

At the frontend interface level, registration occurs by uploading an Agent Card or providing the network path to the /.well-known/agent-card.json descriptor

Smart Agent Discovery

Agent-Reg provides a very simple search engine that allows users to discover agents of interest based on various criteria. The following diagram illustrates the search engine architecture and applied filters:

Search Capabilities

The search criteria are the following:

• By Name: Simple textual search based on agent name
• By Skills: Find agents that declare specific skills (e.g., “route-planning”, “image-processing”, etc.)
• By Capabilities: Filter agents based on capabilities declared in the agent card according to the A2A protocol (streaming, push notifications, etc.)
• By Owner: Show agents managed by specific teams or organizations
• By Liveness: Show only agents that are currently active according to periodic heartbeat.

Health Monitoring

In a realistic scenario, agents will be a lot and potentially unstable due to their continuous evolution and maintenance (just think of a change in prompt or model), but also due to the complex network of dependencies. For example, an Agent can depend on external services or APIs but also on other Agents. Agent-Reg provides a heartbeat mechanism, where registered agents periodically notify the registry of their health status. This allows the registry to:

• Provide clients with real-time health status information
• Automatically filter unresponsive agents from search results
• Enable proactive monitoring and alerting for critical agents

Data Model and A2A Compliance

Agent-Reg adheres to the A2A protocol specification for agent card structure, but it’s obviously a simplified and extensible model. For example, it doesn’t include specific SecurityScheme definitions in their 5 variants. Below is a class diagram illustrating the logical data model:

Backend APIs

Agent-Reg provides a complete REST API with some methods that implement the main operations:

Real-World Usage Example

Let’s see how Agent-Reg works in practice. Imagine you’re building a travel planning application that needs to find a route planning agent with real-time traffic capabilities:

# Search for agents with route planning skills and streaming capability
curl "http://localhost:8000/agents?skill=route-optimizer-traffic&capabilities=streaming&only_alive=true"

The registry will return only active agents that match these criteria, complete with their invocation URLs, security requirements, and capability details.

At the user interface level, you can do the same thing through the search bar.

Why Agent-Reg?

Agent-Reg tries to solve the Discovery problem within an A2A-compliant agents ecosystem and can be potentially useful also for addressing security and governance issues in agent-based applications. I tried to summarize the main pillars on which I would like to make the tool evolve:

1. Interoperability: heterogeneous agents that adhere to the standard can work together without the need for point-to-point connections or complex and redundant integrations
2. Discovery: Organizations can maintain a complete and constantly updated catalog of their Agents
3. Reliability: The heartbeat mechanism ensures that clients interact only with responsive agents
4. Scalability: The architecture can handle thousands of agents without complex infrastructure requirements
5. Openness: It’s an open-source solution that can be distributed anywhere, prevents vendor lock-in, and encourages innovation

Getting Started

Agent-Reg still lacks several functionalities and optimizations necessary before being able to actually use it in a production enviroment (e.g., authentication and authorization, error handling, logging, notifications, support for other NoSQL DBs, …), but it’s a foundation on which to build a small open and extensible ecosystem. Starting it’s very simple:

# Backend setup
cd backend/app
pip install -r requirements.txt
python src/main.py

# Frontend setup
cd frontend
npm install
npm start

Conclusions

In this period of strong acceleration about AI, the A2A protocol takes a very important step, because it brings together some basic concepts on which to build real standardization, but from this point of view, in my opinion, we are not yet in a maturity phase. The specifications themselves are not badly written, but they are quite generic (try yourself comparing them with other standards, like the HTTP/2 to understand what I mean…) and still leave many opportunities for extensions or integrations. One of the important points that seems to have been overlooked is Discovery, for which I’ve tried to imagine a centralized and open solution.

I’m making it available to the community, hoping that some volunteer can help me by contributing to its development! 😊