A2A Protocol
article

What the A2A Protocol Gets Right (And Where It Needs Help)

The A2A protocol gives agents a common language, but it doesn’t solve trust, validation, or security. Here’s what it does right and what’s still missing.

Beon de Nood
September 24, 2025
3 min read
the foundation of a large construction project is like the a2a protocol for ai agents
“A2A gives agents a way to speak the same language. But it doesn’t tell you who’s speaking, or whether you should trust them.”

A2A is a step in the right direction

We’ve needed something like it for a while.

The A2A protocol gives AI agents a shared way to describe themselves. It defines a simple structure for how agents declare what they are, what they do, and how you can talk to them.

At the center of it all is the Agent Card.

That’s just a JSON file, but it carries the DNA of an agent’s identity. It includes:

  • The agent’s name, version, and description
  • A list of supported transports
  • Metadata like publisher info and contact
  • A list of capabilities the agent claims to support

That structure makes things predictable. It allows discovery. It helps orchestration tools understand what agents are capable of without guessing.

This is foundational work.
And it’s long overdue.

But A2A isn’t enough on its own

The spec is great at declaration. It defines a clean way for agents to describe themselves.

But it does not solve for trust.
It doesn’t verify anything.
And it doesn’t help you decide whether an agent is actually real, safe, or usable.

Let’s be specific. A2A doesn’t:

  • Check whether the publisher is legitimate
  • Require the card to be hosted from the same domain as the agent
  • Validate that the transport actually responds
  • Protect against spoofed or stale metadata
  • Support revocation or expiration
  • Include any scoring, attestation, or structural quality check

It defines a contract, but it doesn’t enforce it.

Why this matters right now

Today, most agents are hardcoded into apps and demos.
Developers are wiring them in manually.
That works for now. But it will not hold when agents start calling other agents in real-world workflows.

If there’s no standard for validation, you end up relying on:

  • Guesswork
  • UIs
  • Screenshots
  • Centralized gatekeepers

That’s a fragile trust model. It breaks down fast when things become dynamic or autonomous.

So what do we actually need?

We need tools that check:

  • Is the agent card valid according to the A2A spec?
  • Does it include the right metadata and capabilities?
  • Is the transport declared, reachable, and consistent?
  • Is the card served from the same domain the agent lives on?
  • Is it usable in production or just a placeholder?

None of these checks are enforced by the protocol itself. But without them, the entire idea of composability falls apart.

That’s where we stepped in.

What we built at Capiscio

We created a simple, open-source CLI to validate A2A agents.

It’s fast, offline, and zero-dependency.

TERMINAL
npx capiscio-cli validate https://your-agent.com/my-awesome-agent

The CLI runs a series of checks:

  • Does the card follow the A2A spec?
  • Are the required fields present and correct?
  • Is the transport valid and declared properly?
  • Is the metadata consistent?
  • Is the card hosted in a verifiable location?

No login. No UI. No fluff.

Just a signal — pass or fail — with a breakdown of what’s missing or misaligned.

This isn’t about gatekeeping. It’s about clarity.

A2A is the foundation, but trust needs structure on top

We are not here to compete with the spec.
We’re here to support it.

A2A solves for structure:

  • Metadata
  • Transport declarations
  • Capability exposure
  • Interoperability at the metadata level

Capiscio steps in where structure meets trust:

  • Validation tools
  • Registry visibility
  • Verification of publisher origin
  • Clear pass/fail output
  • Future support for attestation and revocation

It’s a handshake. Not a replacement.

Final thoughts

The A2A protocol is the right move. It gives agents a shared voice.

But in a noisy ecosystem full of unverified tools, claims, and scraped data, structure is not enough.
We need validation.
We need provenance.
We need tools that help developers and teams see what’s real.

That’s what we’re building, starting with the CLI.

You can try it in 5 seconds:

TERMINAL
npx capiscio-cli validate ./agent-card.json

It won’t solve every trust problem.
But it will tell you whether your agent is even in the conversation.

Beon de Nood
Written by Beon de Nood

Creator of Capiscio, the developer-first trust infrastructure for A2A agents. With two decades of experience in software architecture and product leadership, he now focuses on building tools that make AI ecosystems verifiable, reliable, and compliant by default.