When agents talk to each other

For two years, the challenge was connecting AI to tools. That is almost solved. The new challenge is another: getting agents to communicate with each other, delegate tasks and cooperate without a human coordinating every step. And that frontier, which seems purely technical, drags a question engineering cannot dodge: when something fails in a conversation between machines, who is responsible?

The starting point: from the lone agent to the system of agents

An isolated AI agent is, at this stage, a solved problem. It knows how to use tools, query databases, execute bounded tasks. The missing piece was not making the individual agent more capable, but getting several agents to work together.

Sector figures suggest that transition is already underway. Gartner estimates that 40% of enterprise applications will incorporate specific agents in 2026, versus less than 5% in 2025. It is not a distant trend: it is the current year.

And here appears the problem a data engineer recognises immediately, because they have seen it before in other contexts. When you move from one component to many components that must coordinate, difficulty does not grow linearly. It grows with the number of possible interactions. Each new agent does not add a node: it adds all the conversations that node can have with the others.

Without a common protocol, each of those conversations demands custom integration. And custom integration, multiplied by a growing agent population, becomes unmanageable. It is exactly the problem that network standards, data interchange formats or messaging buses solved in their day. History rhymes.

Two protocols for two different problems

The most common confusion when approaching this ground is treating MCP and A2A as competitors. They are not. They solve different layers of the same system, and understanding that difference is the first step to designing well.

MCP: the agent and the world

The Model Context Protocol standardises how an agent accesses tools, APIs and data sources. It is the vertical layer: it connects the agent to the outside world.

Its adoption has consolidated unusually fast. The promise of “write it once, use it everywhere” is being fulfilled: an MCP server for a specific database works with any compatible AI client. That has made MCP a de facto standard for agent-tool connectivity.

But MCP has an explicit design limit worth being clear about: it was not designed for agents to talk to each other. Its model assumes a client-server pattern, a connection towards a capability. Agent negotiation, task delegation, coordinated work sharing — none of that is in scope.

MCP connects the agent to its tools. Not to its peers.

A2A: the agent and its peers

That gap —horizontal communication between agents— is what A2A (Agent-to-Agent) came to fill, introduced by Google in April 2025 and donated to the Linux Foundation shortly after.

A2A standardises something different: how agents discover each other, negotiate capabilities and delegate tasks, regardless of the framework they are built on. If MCP is the cable to the tool, A2A is the common language between agents that need to share work.

The central mechanism is the Agent Card: a structured description each agent publishes about what it can do. Other agents read it, discover what they can delegate, and pass tasks. No hand-written glue code for every agent pair that needs to collaborate.

The sector’s consolidation move has been notable. IBM’s Agent Communication Protocol was integrated into A2A throughout 2025, and in December of that year the Linux Foundation launched the Agentic AI Foundation —with OpenAI, Anthropic, Google, Microsoft, AWS and Block among the founders— as a permanent home for both A2A and MCP. Two protocols, two layers, one institutional roof.

The two-layer stack, seen from engineering

Placed in order, the two protocols draw a clear architecture:

The practical recommendation emerging from sector consensus is sober: adopt MCP for tool connectivity, adopt A2A when multi-agent flows appear, and —this is important— abstract the protocol layer behind clean interfaces, because both standards are still evolving and you want to update them without rewriting agent logic.

So far, the comfortable ground: architecture, layers, standards. Now comes the part sector enthusiasm mentions less.

What this changes in data engineering

Inter-agent communication is not just a new capability. It reorders how a system is designed, observed and governed. Four concrete consequences.

1. The system stops being inspectable at a glance

A traditional pipeline can be followed. Input, transformation, output. There is a thread to trace.

A system of agents that delegate to each other does not offer that thread. Execution branches: one agent discovers another, passes it a task, that one subcontracts to a third. The actual path a request followed only exists, reconstructable, if every hop has been deliberately logged.

That is why observability stops being a best practice and becomes an architectural requirement. Every MCP call, every A2A task state transition, every delegation: all of it must be traced. A multi-agent system without exhaustive logging is not an agile system. It is a black box that also moves.

2. The failure surface multiplies

When agents coordinate, failure modes appear that did not exist with a single agent. One agent publishes an Agent Card that describes what it does poorly. Another delegates on that wrong description. A third receives a partial result and builds on top.

The failure also propagates. And it propagates in a particularly hard-to-diagnose way: the symptom appears in an agent that did not commit the error, but inherited the consequences of another several hops back. Anyone who has debugged distributed systems recognises the pattern. The difference is that here nodes are non-deterministic: each agent is a model that may interpret the same task differently depending on context.

3. The external layer changes function

Here is a displacement worth anticipating. As protocols absorb coordination —discovery, delegation, task lifecycle management— hand-crafted orchestration architectures lose part of their reason for being.

But they do not disappear. They change jobs. The external layer stops dealing with how agents talk —the protocol does that— and moves to what the protocol does not cover: integration with the organisation’s real systems. Databases, queues, business APIs, access rules, the limits of what each agent can touch.

Coordination goes down to the protocol. Governance goes up to the infrastructure.

4. Security becomes a machine-to-machine identity problem

If an agent can discover another and delegate a task, the security question is immediate: which agent has permission to ask what of which? Authentication and authorisation between agents —still evolving in both protocols— stop being an implementation detail. They are the perimeter.

A system where agents delegate tasks without clear identity and permission control is not an autonomous system. It is a system without doors.

What the protocols do not solve

Be precise: MCP and A2A solve interoperability. They make agents from different manufacturers understand each other. That is valuable and real.

But interoperability is not the same as control. That two agents can talk says nothing about whether they should, who supervises that conversation, or what happens when it produces a wrong result. Protocols standardise the channel. They do not standardise responsibility.

And that distinction is what opens the second half of this article.

The other side: responsibility that dilutes

So far, engineering. But a system where machines delegate tasks to each other touches something beyond architecture: it touches the question of who answers.

When a single agent failed, the responsibility chain was locatable. There was a model, an input, an output, a point where something went wrong. With several agents cooperating, that chain becomes diffuse. And the word “diffuse” is not rhetoric: it is the precise description of what happens.

On the authorless failure

Imagine a multi-agent system that produces a wrong decision. One agent misinterpreted a task. Another delegated it trusting an imprecise Agent Card. A third integrated a partial result without detecting it was partial. No agent “failed” in the strict sense. Each did what its design contemplated. And still, the system produced an error with consequences.

Whose error is that? The question has no comfortable answer. There is no guilty component. There is an emergent system property: a failure born from interaction, not from any of the parts. And legal systems, organisations and professional customs are built to attribute responsibility to concrete actors, not to interactions.

On the delegation no one sees

There is a second, subtler effect. When an agent delegates to another via A2A, that delegation is invisible to the end user. The person who initiated the request sees an input and an output. They do not see that, in between, the task passed through four agents from three different manufacturers, each with its biases, its limits, its criteria.

The result arrives clean, unified, seamless. And that seamlessness is precisely the problem: it hides the decision chain that produced it. The user cannot ask “who decided this?” because the interface presents the result as if it had a single author. It does not. It has an assembly of agents no one introduced to them.

On the pace of autonomy

And there is a third, most structural question. These protocols are designed, in their own words, to enable agents to collaborate “without human intervention.” That is the stated goal, and from efficiency it makes complete sense: human intervention is slow, expensive, a bottleneck.

But human intervention was also where responsibility anchored. Every time a human reviewed, approved or supervised, someone answered. Removing the human from the loop does not just remove a bottleneck: it removes the anchor. And a system of agents coordinating at full speed, without supervision points, is a system where errors also propagate at full speed, with no one arriving in time to stop them.

The question for the designer is not whether agents should be able to coordinate on their own. It is where to deliberately place the points where a human still looks — not from distrust of the machine, but because those points are what keep responsibility locatable.

Open questions

• When a multi-agent system fails and no agent committed the error, who answers to the affected party?
• Does a user have the right to know how many agents —and from which manufacturers— intervened in the response they receive?
• If efficiency pushes to remove the human from the loop, where does responsibility re-anchor?
• Are we designing systems of agents that cooperate, or systems where blame has no address?
• Interoperability is almost solved. Who is working with the same intensity on responsibility traceability?

None has a closed answer. But an idea worth closing with: getting agents to understand each other was an engineering problem, and it is being solved well. Keeping that conversation auditable, attributable and supervisable is a different problem — and it is still waiting for someone to take it seriously.

References

• DEV Community — MCP vs A2A: The Complete Guide to AI Agent Protocols in 2026 (March 2026). dev.to
• OneReach.ai — MCP vs A2A: Protocols for Multi-Agent Collaboration 2026. onereach.ai/blog
• OneReach.ai — A2A Protocol Explained: Secure Interoperability for Agentic AI 2026. onereach.ai/blog
• AI Magicx — MCP vs A2A vs ACP: The Complete Guide to AI Agent Communication Protocols in 2026 (March 2026). aimagicx.com/blog
• OptinAmpOut — MCP vs A2A vs ACP: The 2026 Guide to AI Agent Communication Protocols. optinampout.com/blogs
• DigitalApplied — AI Agent Protocol Ecosystem Map 2026 (March 2026). digitalapplied.com/blog
• Ruh.ai — AI Agent Protocols 2026: The Complete Guide (January 2026). ruh.ai/blogs