In April 2025, Google introduced the Agent2Agent (A2A) protocol at Google Cloud Next. Two months later, it contributed the protocol to the Linux Foundation, with AWS, Microsoft, Cisco, Salesforce, SAP, and other major players joining the working group. The group quickly grew past 100 participants. Around the same time, the field was crowded with similarly named protocols: Anthropic's MCP, the community-driven ANP, and IBM's ACP. Everyone wanted to become the HTTP of the AI era.

After the initial land grab, ACP joined forces with A2A under the Linux Foundation in August 2025. MCP and A2A also settled into a rough division of labor: MCP connects agents to tools and context; A2A connects agents to other agents. Each claimed its own layer of the stack.

Big companies love standards because standards are the fastest way to grow an ecosystem. But looking back a year later, A2A — unless otherwise noted, I use "A2A" here to mean agent-to-agent collaboration broadly, not only Google's protocol — has moved more slowly than almost anything else in AI over the past three years.

The protocol itself only scratches the surface. It solves a communication-layer problem: how agents talk to each other. The real monster, and the much harder universal problem, is a business problem no standard can solve on its own: when agents belong to different owners, how much should they actually share?

A2A Starts as a Group Chat

Start with the most obvious product pattern. If you want humans and agents to collaborate today, what is the path of least resistance? The answer is right in front of us: put them in a group chat.

Once an agent stops being a passive tool waiting to be called and becomes an active node of information and action — able to send messages, initiate workflows, and pick up work — it becomes, in every practical sense, a teammate. Group chat is one of the most natural places for teammates to work.

As early as October 2024, powered by Salesforce's platform capabilities, Slack shipped Agentforce, allowing agents to join channels like users, read shared context, receive @mentions, and even @mention other people or agents. They could participate in discussions and take on tasks like coworkers. Slack was not alone. Products such as Adapt, Runbear, Glue, and Slock have taken similar approaches.

The strength of this pattern is that it requires almost no user education. Group chat is one of the most familiar collaboration interfaces we have. Create a group, state the goal, @mention the right people, and iterate through messages until the work moves forward. Now a few of the participants happen to be agents, but the user's mental model barely changes: @mention the agent when you need it.

A2A collaboration follows the same logic. When one agent cannot handle a task, it @mentions another agent better suited to the job. The goal of A2A is to extend the same collaboration mechanism from human-to-human and human-to-agent work into agent-to-agent work, enabling agents to discover one another and exchange information in a shared conversational space.

This works because group chat is a natural context hub. Everyone can see the same history. Rich context improves reasoning quality; when something goes wrong, the full conversation becomes the debugging surface. As Slack has put it:

Unlock conversational context for every agent.

But Is A2A Really Just Group Chat?

Now imagine a Slack channel that includes not only your own team, but also outside collaborators and agents supplied by third-party vendors. You do not know how those external agents work internally. Would you still speak freely in that channel? Would you let your own agent expose its full reasoning process, including which proprietary RAG sources it used?

Probably not. More likely, you would hash things out first in a private channel with your own team, then selectively share conclusions back into the external channel.

That is the real challenge in pushing A2A collaboration further. Once agents with different owners participate, you can no longer put all your cards on the table. Full context sharing and full runtime visibility go out the window.

The right trust model for external A2A collaboration looks like the classic honest-but-curious model from information security. Participants will not actively sabotage each other, but they will look at anything they are allowed to see. Under that assumption, proprietary context has to be protected.

An agent's value does not come from which model it runs. Today, commercial and open-source frontier models are strong enough that almost no private model can outperform them on tasks requiring broad generalization. An agent's real value comes from what is baked into its runtime: proprietary data, proprietary knowledge, domain-specific workflows, and hard-won thinking frameworks. Those are the differentiators. They are scarcer than general model intelligence and harder to copy than orchestration logic.

That is the part of an agent owner's value AI cannot simply replace. It is also exactly the part that must be protected.

This need for isolation means A2A collaborators are strange bedfellows with shared goals. They are working toward the same objective, but each side is keeping something up its sleeve. That is not an artificial barrier. It is the natural result of protecting intellectual property and individual value.

Agents Need Ground Rules

If holding some things back is both legitimate and unavoidable, the question becomes: what should be shared, and what should stay private, so that the work can move forward without exposing proprietary context?

A practical answer is for agents to set ground rules before they start.

There are two layers. The first is a set of hard boundaries written into the agent at design time — an unbreakable firewall for proprietary context. The second is task-level negotiation: before a specific task begins, the agents agree on inputs, outputs, permissions, and expected artifacts. Anything is fair game as long as it does not cross the hard boundaries.

Once that contract exists, internal execution can be opaque. If the final deliverable conforms to the agreed interface, the deliverable is what gets shared. The runtime environment does not need to be.

Why not negotiate disclosure dynamically at runtime? Two problems.

First, runtime boundary negotiation is almost impossible to make reliable because there is no trusted referee. To decide whether information can be disclosed, someone has to inspect it. But in a semi-trusted environment, the moment someone inspects it, the risk has already materialized. A centralized referee is not trustworthy enough. The other party is not trustworthy enough. And the agent itself cannot always be trusted to make the call either: in long-running task chains, it cannot fully predict downstream needs, and under-sharing can cause the workflow to fail halfway through.

Second, runtime negotiation is expensive and expands the attack surface. The negotiation itself becomes a probing channel. A curious agent can keep pushing, nudging, and reframing until the other side reveals more than it should.

Once you define how shared context and intermediate artifacts are stored, how events are logged, and how disagreements are reconciled, agents can collaborate on that foundation. This is the old software engineering principle — depend on the interface, not the implementation — applied to agents. Agents should treat each other like APIs.

What Is Hidden Is Exactly What Agents Need to See

A pre-negotiated interface is basically two agents saying: "Here is what I need" and "Here is what I can give." That solves part of the isolation problem, but it creates another one.

Models reason better with richer context. The ability to inspect prior conversation and use it to shape downstream output is central to an agent's generalization, reasoning, and self-healing. But in A2A collaboration, agents often have different owners, which usually means different data owners. We are forced to hide parts of the runtime and generation process. In doing so, we also lock away part of the agent's capability. You cannot make bricks without straw: the less context an agent has, and the more constrained its environment becomes, the worse its understanding and reasoning quality will be.

The situation gets even messier when an agent receives an input whose provenance it cannot inspect.

Take hallucination. Within a single generation pass, hallucination is normal and common. Once it appears, it can compound across multi-turn conversations. Beyond improvements in the foundation model itself, the main way to fight hallucination is to audit context. Reasoning models have gained some self-healing ability by catching and correcting themselves midstream.

In agent systems, the toolbox is richer. Multiple models from the same or different providers can run repeated passes over the same input. Review agents, orchestration agents, and summarization agents can cross-check each other. These techniques can reduce hallucination during generation, though they can never eliminate it.

External A2A collaboration changes the game. Those hallucination-reduction techniques usually assume a single owner with full visibility into the generation process and runtime environment. When an external agent wants to audit the generation process, the data it needs is often buried inside the very proprietary context that must remain isolated.

Reasoning quality has the same problem. Modern agents do not simply dump all context into a prompt. They summarize, compress, recall relevant information, and inject it as needed. That mechanism helps agents perform high-quality reasoning on open-ended tasks and gives them more material for self-correction. But when a conclusion comes from an external input whose generation process is invisible, the receiving agent's reasoning quality is inherently capped.

An agent's power depends on being able to see the process. A2A isolation takes away exactly that: the process. The information hidden to protect proprietary value is often the same information another agent needs to maintain reasoning quality and self-correct in long-running, open-ended tasks.

This is not a bug you can patch away. It is a hard tradeoff — a whack-a-mole tension between collaboration and protection.

If You Cannot Solve the Problem, Change the Problem

Under isolation, full context auditing is gone. That is the price of protecting proprietary context. A good mechanism does not have to eliminate the tension, especially when the tension is structural. If no mechanism can provide both full context disclosure and strong proprietary protection, layered governance is the more realistic answer.

Consider hallucination again. Cross-agent hallucinations and factuality hallucinations are relatively easy to catch. If a downstream agent invents something the upstream agent never said, the shared artifacts are right there. If every input must cite its source, mismatches against shared artifacts are straightforward to detect.

The hard case is hallucination inside an agent's private process: faithfulness hallucination. If an agent goes off the rails in its own sandbox, drifts away from instructions, builds on hallucinated content, and then returns a perfectly formatted, internally consistent deliverable, the outside world cannot truly audit what happened.

For that category, we cannot design a hard mechanism-level guarantee. We can only reduce risk probabilistically. An agent can run a full self-review before submitting final output. The same input can be run again, and major discrepancies can trigger alerts. Neither approach is cheap. Neither is bulletproof.

So isolation should not be a rigid, one-size-fits-all rule. It should be a dial users can adjust based on the scenario.

At one extreme is weak isolation: share more of the process, reclaim more auditing, self-healing, and error-correction capability, and accept greater proprietary exposure. This fits scenarios where mutual trust is high and quality sensitivity is extreme.

At the other extreme is strong isolation: protect all private processes and compensate with redundant auditing mechanisms. The tradeoff is accepting some miss rate. This fits scenarios where proprietary value matters more than speed, cost, or maximum reasoning quality.

Every A2A collaboration is a search for the right balance between those two extremes. There is no optimal solution and no universal solution. There is only the solution that best fits the value profile of the task at hand.

Finding that balance means weighing six factors:

- Input

- What input does the agent need? What are its freshness, provenance, and confidence requirements?

- Output

- What must the agent produce? This is not just format, schema, and citations, but also the source or verification method that can validate the output.

- Boundaries

- What can the recipient do with the deliverable? Can it store it, share it, reuse it, or train on it?

- Audit

- Which events, artifacts, and decisions must be logged so the collaboration is traceable and verifiable?

- Quality

- For private processes that cannot be externally audited, what quality-assurance methods are required? Did the agent self-check before submission? Were critical steps rerun for verification? Will conclusion divergence trigger an alert?

- Failure

- What counts as failure? When a run fails, does it escalate to a human? The worst outcome in a long-running task chain is not a single failed step. It is an agent stubbornly producing an answer anyway and sending bad output downstream.

When these six factors are clear, the boundaries, capabilities, and risks of the collaboration are clear too. This framework does not resolve the tension between collaboration and protection, but it tells you where the task sits on the weak-to-strong isolation spectrum, and what you are paying for.

The Next Leap

We have gotten used to one assumption: the richer the context you give AI, the better the result. But in real-world A2A collaboration, complete context and full runtime exposure are luxuries. Sometimes they are liabilities.

We are at a turning point. Agent populations are exploding. Capabilities are diverging. Agents are moving from cookie-cutter general-purpose assistants into specialized actors with unique data, know-how, and hard-to-replace expertise.

A2A is almost certainly a key part of the next leap in AI capability. But that leap probably will not come from making any single foundation model a little smarter. It will come from designing collaboration spaces where agents can work together while maintaining their own boundaries.

Strange bedfellows do not have to end in deadlock.

- A2A

- AI agents

- agent-to-agent collaboration

- multi-agent systems

- agent protocols

- MCP