A2A Protocol Hit v1.0. Does Your Small-Team Bot Actually Need It?

What A2A covers, and what it doesn't

A2A is a protocol for agent-to-agent communication: one agent discovers another, authenticates, and delegates a task to it, without either side exposing its internal reasoning, memory, or tool implementations. That is a different problem from an agent calling a tool it already knows about and trusts. If your bot's job is to call a calendar API, a database, or a file system, that's a tool call, and protocols built for tool access are the right fit, not A2A.

The protocol reached a stable 1.0 release in 2026 under Linux Foundation governance, with official SDKs in multiple languages. Three protocol bindings ship with it: JSON-RPC 2.0 over HTTPS, gRPC, and HTTP+JSON/REST, and each agent's supported interfaces are advertised in its Agent Card. A complete A2A interaction moves through discovery, authentication, and task initiation before any work happens.

That matters for the decision in front of you. A2A exists to let agents built by different vendors, on different frameworks, for different organizations, find each other and delegate work without a prior integration agreement. If you already know which bot you're talking to, already control both ends, and already have a way to authenticate between them, you don't have the problem A2A was built to solve.

Sources: Agent2Agent (A2A) Protocol Specification, A2ABreak: Systematic Security Analysis of the A2A Protocol.

The Agent Card is a claim, not a credential

A2A's discovery step centers on the Agent Card: a JSON document that declares an agent's identity, capabilities, skills, and endpoint. In the v1.0 architecture this card serves as the sole trust anchor for everything that follows, but it is self-asserted, and signing it is optional. An agent you've never dealt with can present a card claiming whatever capabilities it wants; nothing in the base protocol forces you to verify that claim before you act on it.

Authentication happens in a separate step, using whatever scheme the card declares, OAuth 2.0, API keys, or mTLS, and credentials are carried at the transport layer on a hop-by-hop basis. That's a reasonable design for a network of agents run by different organizations that need a common handshake. It is overhead you don't need if your bot's only counterpart is another bot you deployed yourself, because you can skip the discovery step entirely and hardcode the endpoint and credential.

The practical risk shows up when teams adopt A2A by default because it's the named standard, then treat an Agent Card from an unfamiliar agent as if it were verified. Don't. If you do end up accepting connections from agents outside your control, require signed Agent Cards where the implementation supports them, and treat an unsigned card the same way you'd treat an unauthenticated webhook: useful for routing, not sufficient for granting access.

Sources: A2ABreak: Systematic Security Analysis of the A2A Protocol.

Worked example: two bots, one team

Illustrative case: a small team runs a research bot that drafts summaries and a scheduling bot that books meetings. The research bot occasionally needs the scheduling bot to check availability before recommending a meeting time. Both bots are built in-house, run on infrastructure the team controls, and never need to talk to an agent outside the team.

Under the decision rule above, this pair doesn't need A2A. The team can give the scheduling bot a scoped API endpoint, authenticate the research bot's calls with a credential they issue and can revoke, and skip Agent Card discovery entirely because there's nothing to discover, the endpoint is a known constant in the research bot's config. Adding A2A here would mean standing up Agent Cards, a discovery step, and a protocol binding for a relationship that a single authenticated HTTP call already handles.

Now change one fact: the scheduling bot is replaced by a third-party scheduling agent the team doesn't operate, offered by a vendor who publishes an Agent Card and supports A2A. The team no longer controls the other end, can't hardcode trust, and may need to delegate to other vendors' agents later without custom integration work each time. That's the point where A2A's discovery and delegation model earns its complexity, because the problem has become exactly the one it was designed for: talking to an agent you don't own and didn't build.

The decision, and what breaks if you get it wrong

Ask one question before reaching for A2A: does the other agent belong to someone else, with no existing integration agreement? If no, use a direct authenticated connection between the two bots you control; it's less code, fewer moving parts, and nothing to verify beyond the credential you already issued. If yes, A2A's discovery and signed-identity model is the better fit, because you need a way to establish trust with an agent you didn't build.

The failure path in the wrong direction is cheap to describe. Adopting A2A for a fixed pair of bots you control adds a discovery layer and an Agent Card that nobody else will ever need to read, and gives you one more surface, the card itself, that must be kept accurate as the bot changes. Skipping A2A when you actually need cross-organization delegation is worse: without it, every new partner agent means a custom integration, and without a standard discovery and authentication step, you end up either trusting unverified claims about a stranger's agent or building your own weaker version of what A2A already specifies.

The protocol's governance has also shifted since its 2025 launch, moving from a single-vendor specification to Linux Foundation stewardship, with a public process for spec changes. That's relevant if you do adopt it: pin to the released 1.0 specification for present-tense claims about behavior, and check the release notes before assuming an older version's rules, like the earlier unsigned-only Agent Card model, still apply.

Sources: Agent2Agent (A2A) Protocol Specification, 2026 - A2A Protocol, A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year.