Give Your Agent a Door It Can Actually Lock

A2A has reached production at over 150 organizations, but most teams building agents haven't thought through what it means when an outside agent knocks on their door with a task. The trust model isn't optional.

Picture your support agent sitting quietly in Slack, waiting for a user to ask something. Now picture a different agent - one built by a vendor you use - sending it a task directly, no human in the loop. Should your agent accept? How does it know who sent the request? How does it know the request was not tampered with in transit?

That question is no longer hypothetical. The A2A (Agent-to-Agent) Protocol project, hosted by the Linux Foundation, recently passed 150 organizations supporting the standard, with deep integration across Google, Microsoft, and AWS platforms, and active production deployments across multiple industries.

In less than a year, A2A has moved from initial release to a production-ready open standard for seamless agent-to-agent communication. The protocol that started as a Google-incubated spec is now the plumbing a real number of enterprise agents run on.

If your team is building agents, this matters whether you have adopted A2A yet or not.

What A2A actually specifies

A2A is an open standard Google announced in April 2025 that enables AI agents built by different vendors to discover each other, delegate tasks, and coordinate work across enterprise systems.

Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements - analogous to a service descriptor in microservice architectures. Tasks represent units of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, and failed, carrying structured payloads that can include text, files, and structured data.

It uses HTTP, Server-Sent Events, and JSON-RPC 2.0 for transport. There is no exotic new protocol layer. If you have shipped a webhook or a REST API, you already understand the bones of this.

The part that matters right now is the Agent Card. It establishes a common semantic layer, allowing an autonomous agent to discover another agent, request an action, and receive structured data without relying on hardcoded, proprietary glue code. But a static JSON descriptor sitting at /.well-known/agent.json only tells you what an agent claims to be. The current spec revision - v1.2 - adds something more important: signed Agent Cards with cryptographic signatures for domain verification. That is the part most tutorial posts skip.

The problem bespoke integrations never had to solve

Before A2A, enterprise AI teams building multi-agent systems faced a fragmentation problem: agents from one vendor could not reliably hand off work to agents from another using a shared, open standard. Teams could write custom API integrations between specific agents, but every new agent pair required a new bespoke connector.

That NxM problem is real, and A2A solves it. Integrating every AI agent with every other agent creates an exponential matrix of API calls, custom authentication, and brittle endpoints, resulting in an unscalable ecosystem where agents cannot easily share context or negotiate complex tasks. A standard protocol collapses that matrix.

But bespoke integrations had one accidental security property: they were small. You wired up two specific systems, you knew exactly what could flow between them, and your firewall rules reflected that. When you join an open standard with 150 organizations, any agent that knows your Agent Card endpoint can try to send your agent a task. The surface area is qualitatively different.

A2A enables peer-to-peer agent collaboration with bidirectional communication. Bidirectional means your agent is not just a caller - it is a server. Treat it like one.

What the auth story looks like now

A2A is built on existing common standards, including Server-Sent Events, HTTP(S), and JSON-RPC, meaning it is easier to integrate with existing IT stacks and is designed to support enterprise-level authentication and authorization.

The practical checklist for a team exposing an A2A endpoint today:

  • Verify the Agent Card signature. The card should carry a cryptographic signature you can check against the sending domain. If an incoming request does not come with a verifiable card, reject it at the door.
  • Scope what the delegated agent can trigger. An external agent asking your internal HR agent to look up a salary record is a different risk than asking it to summarize an FAQ. Enforce capability scopes the same way you scope OAuth tokens.
  • Log task state transitions. A2A tasks move through submitted → working → completed (or failed). Each state change is an audit event. Capture them. When something goes wrong in a multi-agent flow, this is how you reconstruct what happened.
  • Set explicit timeouts and cancellation. A long-running task initiated by an external agent that never resolves is a resource leak at minimum, and potentially a denial-of-service vector at scale.

A multi-agent workflow is only as trustworthy as the least-scrutinized handoff inside it.

Vertical adoption spans supply chain, financial services, insurance, and IT operations, where organizations use A2A to coordinate autonomous systems across tools, vendors, and environments. In those domains, the stakes on a bad task delegation are high. A supply chain agent that accepts a forged task and triggers a purchase order is not a hypothetical catastrophe - it is the natural end state of treating protocol adoption as purely an integration exercise.

The governance move that changes the calculus

The Linux Foundation announced the formation of the Agent2Agent project with Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. With the formation of this new, independent entity, the companies will collaborate closely on fostering an open and interoperable ecosystem for AI agents with the A2A protocol and other interoperability technology.

Moving the spec to a neutral foundation matters for one specific reason: the protocol is now harder for any single vendor to steer in a direction that serves their platform over yours. This allows developers and organizations to unite agents from multiple sources and platforms, improving modularity and mitigating vendor lock-in. That promise is only real if the governance structure actually holds - which the Linux Foundation has a credible track record of doing.

Cloud providers have reinforced that momentum by embedding A2A directly into their platforms: Microsoft integrated A2A into Azure AI Foundry and Copilot Studio, and AWS added support through Amazon Bedrock AgentCore Runtime. When the three major clouds all ship native support, the protocol stops being an experiment and starts being an expectation.

What teams should do this week

If you are building agents that will eventually coordinate with other agents - even just internal ones - start by writing your Agent Card now, before anyone asks for it. Make it accurate. Scope the capabilities it advertises precisely to what you actually want external callers to invoke.

An AI teammate like Beagle, living inside Slack, already receives tasks from people. The next evolution is receiving tasks from other agents. The door is being built whether you participate in spec design or not. The question is whether you hang a lock on it first.