A2A: The forgotten protocol?

A2A: What Google's agent protocol actually says (and what it doesn't)

There's been a lot of noise about AI agents this year, most of it focused on tools and integrations. How do you give an agent access to your calendar, your files, your APIs. Useful stuff, but it's really about making agents more capable individually.

The thing I keep coming back to landed with almost no fanfare. Google's A2A protocol. Agent-to-agent communication. Not how an agent uses tools, but how agents work with each other. For hospitality, that's the interesting question, because a venue isn't a tool to be called on. It's a participant.

So I went through the actual spec, not the launch blog or the commentary, and the first thing to understand is that A2A doesn't solve agent discovery. It explicitly avoids it.

What it does solve is communication. Once two agents know about each other, A2A defines how they talk: how one agent sends a task to another, how they negotiate capabilities, how the receiving agent streams back progress or asks for clarification. The mechanics are solid. JSON-RPC 2.0 over HTTPS, support for long-running tasks, a clean state model (submitted, working, completed, failed). Well-designed infrastructure for a well-defined problem.

The interesting bit is the AgentCard, a JSON document at /.well-known/agent.json that describes what an agent can do. Skills, authentication requirements, supported modes. If you know where to look, you can fetch this and understand what you're talking to.

json

{
"name": "Hotel Booking Agent",
"description": "Books hotel rooms across partner properties",
"skills": [
{
"id": "check-availability",
"description": "Check room availability for dates"
},
{
"id": "make-reservation",
"description": "Create a confirmed booking"
}
]
}

At first glance, the AgentCard looks quite simple, a capability declaration not far from Schema.org. Name, description, list of skills. Basic stuff. But it's not. The spec allows for rich extension: authentication schemes, input/output schemas per skill, supported content types, rate limits, versioning. It's designed to carry a full machine-readable identity, not just a label.

That changes the picture. The AgentCard isn't just metadata about a venue, it's what makes a venue an agent. Something with capabilities, something that can be negotiated with, queried, transacted with. Not a listing, but a participant. A hotel with an AgentCard isn't data to be scraped. It's an agent to be discovered and worked with.

The spec draws a deliberate line at discovery though, and you can understand why. Discovery is messy, domain-specific, and commercially charged. Exactly the kind of thing specs tend to avoid.

For hospitality, that's the bit that matters most. A guest doesn't know which agents exist. They don't have a list of endpoints. They have intent: "somewhere to stay in Edinburgh next week, dog-friendly, under £150." The agent representing them needs to find relevant options before any communication protocol becomes useful.

Here's how I see the stack:

• A2A = transport and protocol. How agents communicate.
• AgentCard = identity and capability. What an agent is and does.
• Echo / Selfe = discovery and orchestration. How agents get found and matched to intent.

A2A solves the transport layer, and that's necessary. We'll likely adopt something compatible. But communication between known agents isn't what gets a venue booked.

This is what fed into Echo, the idea that venues can be agents, declaring their capabilities through something like an AgentCard. And the Selfe SDK as the orchestration layer, discovering those venue-agents and matching them to intent.

Protocols don't create markets. Discovery does.