A little over a year ago, Google introduced the Agent2Agent Protocol (A2A) around a simple idea: if agents are going to work with other agents, they need a standard way to communicate.

A lot has happened since then. A2A reached version 1.0 in March 2026. More than 150 organizations now support the standard, according to the Linux Foundation, with integrations from Google, Microsoft, and AWS and production deployments across several industries. In August, A2A moved into the Agentic AI Foundation as a Growth Stage project.

By those measures, A2A is doing quite well. But something else happened over the same period. MCP became a much larger part of the agent infrastructure conversation, and MCP servers started exposing increasingly sophisticated capabilities. Agent runtimes got better at orchestration. Long-running work began moving into durable tasks and workflows. Some systems started coordinating agents through shared state rather than direct communication.

Each of those developments reduces the number of situations in which agents need to appear to one another as independently addressable agents.

That leaves A2A in an interesting position. There is clearly a real protocol, a real ecosystem, and real adoption. The question is how often agents need an explicit agent-to-agent relationship to work together. Here are some architectural trends that suggest the answer may be not very often.

Agents Are Disappearing Behind MCP Capabilities

A remote agent does not have to look like an agent anymore. It can simply look like a capability exposed through MCP, while the agent machinery, including inference, stays behind the interface.

Suppose an agent needs a detailed analysis of a company. A2A lets the research system present itself as an agent that the caller can discover and delegate work to. If the interaction can be reduced to a well-defined capability invocation, MCP lets the same system expose a ‘research_company’ capability instead.

Even with MCP, there can still be an agent on the other side. There may be even be several agents being that MCP interface, with separate workers handling research and synthesis. The provider can change those workers later without changing the interface presented to the caller. In many ways, MCP is a helpful abstraction.

With A2A, the caller interacts with a specific agent. With MCP, the caller interacts with research, and the agent that performs it can stay an implementation detail.

Subagents Are Now Internal Runtime Primitives

As harnesses take on more orchestration, more agent-to-agent communication happens entirely inside a single runtime. That runtime can spin up specialized subagents for specific parts of a task without exposing any of them externally. A2A fits most naturally with an architecture of independently addressable agents, while subagent-heavy harnesses are pushing more agents behind a single runtime boundary.

OpenAI’s new Agents API, for example, explicitly supports having an agent parallelize work with subagents. A coding agent can send repository exploration to one worker and ask another to investigate a failing test. A research agent can split one question across several workers and combine the results itself.

Those workers may exist for only a few minutes. They often have no identity outside the runtime that created them, and there is no reason for the user to discover or address them independently.

The harness already controls both sides of the relationship. It decides when a subagent runs, what context it receives, and what happens with its output. An external agent protocol would add a boundary where the runtime already has one.

One Agent As the Interface to Many Agents

Another pattern many systems are building toward is placing an entire group of agents behind one coordinating agent. The outside world gets one stable agent to talk to, while that agent decides which specialists need to participate.

LangGraph’s supervisor pattern is a direct implementation of this architecture. A supervisor manages specialized agents and chooses which one to invoke for the current task. An enterprise assistant could use the same pattern across finance and support, while a development agent could coordinate workers for testing and code review.

The user never needs to discover any of those agents. Communication between them can use internal function calls or a native subagent architecture because the whole group belongs to one system.

LangGraph pushes the idea even further with its tool-based supervisor pattern, where specialized agents effectively appear as tools to the coordinating agent. The hierarchy still contains several agents, but only one of them needs an external identity.

In other words, more agents inside the system does not necessarily mean more agents on the network.

Software Factories Coordinate Work Rather Than Agents

Software factories are taking a different route. They organize their architecture around the software work and treat agents as workers assigned to it. If anything, the factory model is pushing agents toward being more ephemeral. The factory keeps track of the work and coordinates execution rather than relying on a network of persistent agents.

OpenAI’s Symphony shows this architecture clearly. Symphony watches a project management board such as Linear, creates an isolated workspace for an active issue, and launches a Codex agent against the work. OpenAI describes the issue tracker as the control plane rather than requiring developers to manage a collection of persistent agent sessions.

Factory takes a similar approach with its software factory model. Work can enter through bug reports or customer feedback, then move through planning and implementation before reaching review and release. Different agents can participate at different points without needing a persistent relationship with one another.

Software factories shift the focus away from relationships between agents and toward the work they operate on. If one agent writes a patch and another verifies it, the verifier does not need to establish a relationship with the original worker.

Traditional Workflow Orchestrators Are Coordinating Agents From the Top

Workflow orchestrators already have mature platforms for coordinating distributed work, so they can treat agents as another kind of step. The execution graph decides what runs next instead of asking agents to negotiate the sequence themselves. Yes, it's more deterministic coordination, but that might be exactly what's needed at scale .

Apache Airflow’s Common AI Provider adds native LLM and agent operators to Airflow. Prefect’s agent orchestration places agents inside its existing durable workflow model. Dagster is similarly extending its orchestration layer to run and observe AI workloads.

A workflow can run a deterministic extraction step, invoke an agent for analysis, and then pass the result to another agent later. The workers do not need to discover each other because Airflow or Prefect already knows the execution plan.

This is different from the software factory model because it starts from an execution graph that defines dependencies from the top. But both approaches remove coordination responsibility from the individual agents.

Communication through Durable State

Agents can also communicate by leaving state behind for the next agent instead of sending messages directly. In memory and other agent state architectures, persistent objects carries the state between workers even when those workers never overlap in time. We could think about governing and federating global durable access to state instead.

One agent might create an artifact that another agent reviews later. It might update a task that causes a different worker to run. The state could live in a database record or some other service that tells the next agent what has already happened and what remains open.

Agents can be swapped in and out while the representation of the work remains stable. If agents can reliably read and write persistent work, direct agent relationships are not required for many handoffs.

More of the innovation may shift toward how work is represented and separated from the execution of that work, which is one of the areas we are exploring with ThruWire.

Existing Distributed Systems Still Work

A lot of agent coordination can also run on infrastructure companies already have, such as queues to distribute jobs, event buses for work, and databases for state between independent processes.

Companies may not want to fully re-invent the wheel to move to A2A. An agent can use the same distributed systems patterns we already rely on at scale: consume a job from a queue and write the result somewhere durable. Another agent can react to that result later without either worker knowing the other one exists.

From the agent’s perspective, work has moved between intelligent systems. From the infrastructure’s perspective, it is still a familiar distributed workflow.

Companies already know how to operate this infrastructure. They have built security and observability around it, and much of their production software already depends on it.

That gives A2A a high bar inside existing systems. An agent-specific protocol needs to provide something that the queue, workflow engine, or event system cannot already handle adequately.

A2A Is Competing With Architectures That Hide Agents

A2A's strongest case is communication across organizational and vendor boundaries, where neither side controls the other's runtime. But even there, it is not obvious that the remote system needs to expose an agent rather than a stable capability backed by agents internally.

If anything, we're seeing overall trends to architectures that hide agents rather than giving them front row seats.

That makes the biggest pressure on A2A architectural rather than competitive. We still need agents to work with other agents, and that activity is growing quickly. The open question is how often those agents need to appear across the boundary as agents at all.

A2A Progress Report: Do We Still Need an Agent-to-Agent Protocol?

Job breakdowns