A2A (Agent-to-Agent Protocol)

For AI agents to reach their full potential, some will need to be able to collaborate. But today there’s no standard way for agents to discover each other or communicate.

A2A (Agent-to-Agent Protocol) aims to fix this. Google released the initial spec in April 2025, then donated it to the Linux Foundation in June. By September, IBM’s ACP (Agent Communication Protocol) merged in, signaling serious industry commitment.

At time of writing, the Technical Steering Committee includes Google, Microsoft, AWS, IBM, Salesforce, SAP, and others. With this backing, A2A has real momentum.

Let’s look at how it works.

Think of A2A as a common language. It doesn't tell agents what to do, just how to introduce themselves and communicate.

{
  "name": "Travel Booking Agent",
  "description": "Books flights and hotels",
  "url": "https://travel-agent.example.com",
  "skills": [
    {
      "id": "book-flight",
      "name": "Book Flight",
      "description": "Search and book flights"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "securitySchemes": { ... }
}

Discovery methods: Direct URL, /.well-known/agent.json, or registry lookup.

The Agent Card is self-asserted. The agent claims its own capabilities. There's no verification.

Unlike simple API calls, tasks model real work that takes time and may need back-and-forth.

A2A doesn't reinvent authentication. It delegates to existing standards via the Agent Card's securitySchemes:

The spec says authentication is "out-of-band": you obtain credentials however you normally would, then include them in A2A requests. The Agent Card tells you what's required.

"securitySchemes": {
  "oauth2": {
    "type": "oauth2",
    "flows": {
      "clientCredentials": {
        "tokenUrl": "https://auth.example.com/token",
        "scopes": { "agent:invoke": "..." }
      }
    }
  }
}

This is the On-Behalf-Of (OBO) pattern. It preserves user identity through the agent chain, enabling:

• Audit trails: Agent 2 knows Alice requested this, via Agent 1
• Fine-grained authorization: Policies can consider both user and agent
• Least privilege: Tokens are scoped to specific resources

The demo below shows the OBO flow in practice. For deep dive on the pattern, see my OBO Explainer.

A2A solves discovery and communication. But cross-domain scenarios expose real gaps:

Agent gateways like AgentGateway are adding auth portals to provide a single enforcement point for these external connections.

DPoP (Demonstrating Proof of Possession) binds tokens to key pairs, preventing token theft. Within a trust domain, OBO + DPoP works fine for Agent 1 → Agent 2.

The problem is multi-hop chains:

• User → Agent 1 → Agent 2: OBO gives Agent 2 a token with user context
• Agent 2 → Agent 3: Now Agent 2 has delegated authority it can pass on
• A compromised Agent 2 can misuse the OBO token from Agent 1's flow

DPoP proves who holds the token, but not whether they should be passing it along. The further down the chain, the harder it is to verify the original delegation was intended.

DIDs and Verifiable Credentials offer a path forward:

• Discoverable identity without centralized registries
• Verifiable capability claims issued by trusted parties, not self-asserted
• Delegation chains that can be cryptographically verified across boundaries

TSP (Trust Spanning Protocol) from the Trust over IP Foundation is the emerging implementation of this vision, with work on running A2A over TSP (TA2A) already underway.