In most companies, AI agents still work on their own: one agent, one tool, one task. One summarizes meeting notes, another answers customer service requests, a third prepares quotes. They don't talk to agents in other systems, let alone in other companies. When information needs to flow between them, there's usually still a person in the middle who copies, checks and passes it on.
That is changing right now. Two open standards are meant to let agents work together, even across company boundaries: A2A and ARD. You'll hear both abbreviations more often over the coming months. In this post I want to explain what's behind them, how mature the standards are and which questions they leave open. Because those open questions don't end up with the developers. They end up on the desks of companies.
Why this is a topic right now
Over the past months, the big vendors realized that everyone was building their own agents that couldn't work with each other. That slows everybody down. So in December 2025 the Agentic AI Foundation was founded under the umbrella of the Linux Foundation. Its job is to develop open, vendor-neutral standards for AI agents. One of its first projects was Anthropic's Model Context Protocol (MCP), which agents use to access tools and data. Its members include companies such as AWS, Google, Microsoft, Anthropic and OpenAI.
It reminds me of my ICANN days: companies that compete with each other agree on common rules. (For companies using AI, that's good news. The more consistent the standards, the lower the risk of getting locked into a single vendor.)
A2A: how agents talk to each other
A2A stands for Agent2Agent. The protocol defines how two AI agents exchange messages, hand over tasks and report back results, even if they come from different vendors and run on different platforms.
To do this, every agent describes itself in a so-called agent card, a kind of digital profile. It states what the agent can do, at which address it can be reached and what kind of sign-in it expects. The communication itself runs on familiar web technologies, which makes getting started relatively easy for IT teams.
It's important to distinguish it from MCP: MCP connects an agent to tools and data sources, such as a database or a calendar. A2A connects agents to other agents. So the two standards complement each other.
Google introduced A2A in April 2025. Version 1.0 is now the first stable release of the specification. According to industry reports, more than 150 organizations are involved, and the protocol runs on platforms from Microsoft and Amazon, among others. Since August 2026, A2A itself has been a project of the Agentic AI Foundation.
ARD: how agents find each other
Before two agents can talk, they first need to know about each other. That's exactly what ARD, Agentic Resource Discovery, is meant to solve.
The idea is simple: a company places a file on its own domain that describes which agents, tools and interfaces it offers. It can list A2A agents as well as MCP servers or classic programming interfaces. Directories, so-called registries, read these files and make them searchable. You can think of it as a phone book for agents, except that everyone maintains their own entry and publishes it under their own address.
Google published ARD in June 2026. According to Hugging Face, Microsoft, GoDaddy and Hugging Face were among the contributors. AWS supports ARD in its Agent Registry, and Snowflake has announced support as well. One important caveat: at version 0.91, the specification is still a draft, so details may change.
First discover, then talk
Together, the two standards create a sequence. An example to make it tangible: a company's purchasing agent is looking for an agent that can check delivery times at a supplier. Through an ARD registry it finds the supplier's agent. The two then talk to each other directly via A2A, without anyone having to write an email or reconcile a spreadsheet.
So ARD answers the question “Where is the right agent?”, and A2A answers the question “How do we understand each other?”.
As simple as that sounds: in this example an agent makes a decision that used to be made by a person. It chooses whom to talk to, and may pass on information in the process. That's exactly why it's worth looking at how trust is established in this system.
Evidence instead of promises
I find ARD's approach to trust interesting. It's based on the company's own domain: whoever publishes under a domain has to control it. On top of that, publishers can attach evidence, for example a SOC 2 report, information on the provenance of their software according to SLSA, or a bill of materials listing the components used (SBOM).
It's a familiar logic: evidence instead of promises. Two limitations come with it, though. ARD doesn't define its own procedure for verifying such evidence; it refers to existing ones. And the order in which a registry shows results is explicitly not a statement about how trustworthy an agent is. An agent at the top of the list is not automatically a good partner.
It's also interesting how AWS has set up its registry: administrators create registries, publishers submit entries, and a curator approves them, rejects them or takes them down again. At its core, that's an approval process like the ones we know from organizations. The technology provides it, but people have to fill it with life.
What's still missing
If you're looking for a certification, you'll be disappointed. There is currently no official certification program for either standard. For ARD there is a test tool that checks whether a file or a registry conforms to the specification. That shows whether an agent speaks the protocol correctly. It doesn't show whether you can trust it.
On top of that, A2A defines how agents communicate, but not who is allowed to do what. A framework for permissions is not part of the protocol, and there is no central, verified directory of all agents either. Researchers have already shown that manipulated agent cards, for example, can be exploited (security analysis on arXiv). That's no reason to avoid the standards. But it shows that security doesn't come built in.
What this means for companies
The technology for agents working together is arriving very quickly. What neither standard addresses are the organizational questions:
- Which agents are approved in our company, and who decides?
- Which data may they see and pass on to other agents?
- Which external agents may they talk to?
- Who blocks an agent again if something goes wrong?
These aren't purely IT questions. They're about approvals, responsibilities and control, which is exactly the interplay I describe in my formula Technology × People × Security. If one of the three factors is missing, there's no impact. Or worse: a risk emerges that nobody notices.
I think three steps make sense already, even while the standards are still evolving:
- Take stock: Which agents are already running in your company, officially and unofficially? If you don't know what's in the house, you can't steer it.
- Extend your policies: Add rules for agents to your existing AI policies, especially on which data may be passed on.
- Clarify responsibility: For every agent, it must be clear who approves it, who monitors it and who switches it off.
Outlook
A2A is stable, ARD is still a draft, and there are no certifications yet. That makes now a good time to look into the topic, before the first external agent comes knocking. I'll keep following the developments and report back here.
Information as of October 27, 2026. Both standards are evolving quickly.