A2A: Infrastructure for the Agentic Age?

A2A is increasingly thought of as infrastructure for the agentic age. The A2A landing page claims: “A2A provides the definitive common language for agent interoperability.” Whereas MCP connects agents to tools, A2A connects agents to each other. A2A, initially developed by Google in 2025, is now a project of the Agentic AI Foundation (AAIF), part of the Linux Foundation, and its list of supporters reads like a who’s who of the tech industry.

Is A2A the language for agent communication? A fundamental component of agentic infrastructure?

Not really.

Not even close.

A2A is a protocol for delegating tasks, which is only one kind of interaction among a potentially limitless variety. An infrastructure for agents must be more general, supporting the expression of whatever patterns of interaction the application at hand demands.

The conceptual nature of interactions

Consider the interactions involved between agents representing buyers and sellers (the principals) in a procurement setting.

• RFQ: the buyer invites offers.
• Quote: the seller makes an offer.
• Reject: the buyer rejects an offer.
• Order: the buyer places an order.
• Shipment: the seller delivers the goods.
• Payment: the buyer makes the payment.
• Refund: the seller refunds the payment.

Each of the above interactions is a first-class communicative act. Performing an act changes the social state of the system. At a basic level, the social state is simply the set of acts that have occurred.

We may additionally specify the high-level meaning of acts in terms of how they change the normative relationships between the agents, e.g., in terms of how commitments between them evolve. Since the normative state of the system is a view over (is inferred from) the social state, we may think of it as higher-level social state.

Let’s make this concrete by specifying the meanings of the procurement interactions in terms of commitments. In the following, the notation C(debtor, creditor, antecedent, consequent) means that the debtor is committed to the creditor to bring about the consequent if the antecedent holds.

• C_ship = C(seller, buyer, Payment, Shipment). C_ship is the seller’s commitment to the buyer that if Payment happens, Shipment will happen too.

• C_pay = C(buyer, seller, Shipment, Payment). C_pay is the buyer’s commitment to the seller that if Shipment happens, Payment will as well.

• C_refund = C(seller, buyer, violated C_ship, Refund). C_refund is the seller’s commitment to the buyer that if C_ship is violated (Payment but no Shipment), Refund will happen.

Commitments, as you would expect, have a lifecycle. When the antecedent holds, the commitment is detached, that is, it becomes unconditional. When the consequent holds, it is discharged. If the antecedent holds, but the consequent fails to hold, the commitment is violated. If the antecedent fails to hold, the commitment expires. (For simplicity, assume that something fails to hold when the deadline for it has passed without it happening.)

With this background, we can now map the communicative acts to their effects on C_ship, C_pay, and C_refund.

The following sequence diagrams capture some reasonable enactments in our procurement setting. Each enactment is annotated with how its acts change the commitments between the agents.

Notice the following points about the enactments.

1. They are not client-server. Either agent can initiate an interaction. E.g., contrast Enactment 1 with Enactment 2.
2. They are not request-response. E.g., Enactment 2 features the buyer performing Order and Payment without any intervening “response” from the seller. Enactment 6 features concurrent Payment and Shipment.
3. Together, they indicate the flexibility with which real world interactions may progress, which contrasts with the regimented manner (ever heard of the “happy path”?) in which interactions are implemented in current approaches.
4. The occurrence of an act changes the social state. E.g., in Enactment 1, the occurrence of Quote means that Quote and active C_ship and C_refund commitments are now all in the social state.

A2A: Built for delegation

A2A’s purpose is task delegation. One agent, the client, hands a task to another agent, the remote, and tracks its progress until it is done or failed. The remote may refuse the task and the client may cancel it. The remote may produce one or more artifacts that reflect the result of performing the task and along the way it can ask the client for clarifications.

Can a protocol with task delegation as its basic facility serve as an adequate foundation for agent communication?

Returning to our procurement scenario above, the first thing to notice is that none of the above acts naturally maps to an A2A delegation. Consider RFQ, which at least is a request and therefore perhaps best-suited to a delegation-oriented framing. The meaning of an RFQ is an invitation for offers; it is inherent to the idea of an RFQ. No additional value accrues by framing it as a delegation from the buyer to the seller. Also, consider how a seller may respond to the invitation. It may respond with a Quote but that is not the only possibility. The seller may, alternatively, perform a Shipment to win the buyer over. Or it may keep mum. Such flexibility undermines the notion of RFQ being a delegation. Analogous arguments hold for the other communicative acts.

An alternative to delegation would be to use A2A’s Message abstraction to send the acts as payloads of messages. But if A2A is merely transporting messages, you are left with the question: What is the point of A2A?

Say A2A is part of the infrastructure for all multiagent applications. The social state is what matters for decision making by agents. A2A contributes nothing to its computation, which must still be done at higher layers. All A2A does is contribute to higher complexity and inefficiencies in the architecture.

A fixed vocabulary is not enough

The idea of a universal communication language has a rich history in multiagent systems. In the late 90s, there was wide interest in coming up with agent communication languages (ACLs). The FIPA ACL and KQML were the leading candidates. Drawing upon speech act theory, both identified (different) fixed sets of communication acts. For example, KQML has around 30 acts, such as tell, achieve (a goal), and so on. In 2013, Munindar Singh, expanding upon his 1998 critique of agent communication languages, pointed out that no fixed set of acts can capture the variety of acts—as distinguished by their meanings—that arise in applications. Therefore, what happens in practice is that the real act becomes a payload for whatever acts are available in the language. For example, in KQML, the acts enumerated above for the procurement scenario would likely end up being encoded as payloads for tells.

A2A is the extreme case of the fixed-vocabulary problem. KQML and FIPA ACL had dozens of communicative acts. A2A has one—delegate.

Application-specific interaction protocols

OK, so A2A is out. In fact, any particular set of protocols that features a fixed set of communicative acts is out.

So are we ruling out any general-purpose infrastructure for agent communication?

No, absolutely not.

What we need are protocol languages and associated infrastructure components that enable the expression and performance of application-specific protocols that specify application-specific communicative acts and their meanings. For example, a group of stakeholders with expertise in procurement may specify a procurement protocol. Another group (such as FINOS) may specify financial trading protocols featuring acts such as Offer, Execute, Confirm, Settle, Assign, Delegate, and so on. In health, a group (such as HL7) may specify protocols featuring acts such as Diagnosis, TestResult, Prescription, Dispense, and so on. Indeed, if you wanted to, you could specify A2A itself as a protocol in these languages, only it would have no special status.

More on this in another post because this goes to the heart of systems, but feel free to look at our software.

Objections

A possible objection to the framing here is that A2A is not meant for multiprincipal settings. It supports orchestration, which is typically within a single organization.

Raising such an objection amounts to a major concession with regard to A2A’s scope and applicability.

But here’s the deal. Multiprincipal or cross-organizational is the hardest case because you are forced to take arms-length, loosely-coupled interactions to heart. The technology stack that addresses the cross-organizational case will also naturally address the intraorganizational case in a loosely-coupled manner. Consider the example of an agent needing approvals from a manager agent before committing to external procurement. We can simply think of RequestApproval, Approval, Decline, and RevokeApproval, as communicative acts. You don’t need different stacks, one for interorganizational interactions, another for intraorganizational. And, in any case, you will find that the intraorganizational cases don’t map to task delegation anyway because within an organization too you have autonomous principals and their interactions have normative meaning. So A2A cannot be the universal protocol for intraorganizational interactions.

Conclusion

A2A is no infrastructure for the agentic age. A2A hard-codes one pattern of interaction, task delegation, and distorts every interaction that is not a delegation, which is most of them. Infrastructure for agents must instead support whatever interaction protocols applications demand, and that means implementing protocol languages, not privileging any one protocol.

A2A may well succeed anyway—it has major backing and virtually everyone interested in agentic AI has heard about it. If it does succeed, every application built on it will pay for it in terms of increased needless complexity and inefficiencies.

Exercises for the Reader

The end-to-end argument guided the design of the Internet. What conclusion about A2A would you draw from it?