# A2A: Adversary to Adversary? > Source: > Published: 2026-08-20 16:39:41+00:00 The Agentic AI Foundation recently [announced that Agent2Agent, better known as A2A, is joining AAIF](https://aaif.io/blog/a2a-joins-aaif) as a hosted project. This places A2A in the same foundation as MCP, along with projects such as AGENTS.md, goose, and agentgateway. The arrangement implies that MCP and A2A occupy different parts of an emerging agentic stack, although the distinction between them can be difficult to explain. MCP allows an agent to discover and invoke remote capabilities, and its newer [Tasks extension](https://modelcontextprotocol.io/extensions/tasks/overview) supports long-running operations, requests for additional input, cancellation, and deferred results. Given those capabilities, it is reasonable to ask when a remote system needs to be treated as another agent rather than as an MCP server exposing tools. If you prefer video, I made [a version of this article for YouTube](https://youtu.be/Ci_QP4CuDk8). My first attempt at an answer involved an internal design-review workflow. One agent could produce a technical design and send it to two reviewers: a supportive agent responsible for strengthening the proposal and a critical agent responsible for finding weaknesses. A neutral orchestrator could revise the design and circulate it again until the reviewers stopped finding significant problems or a fixed number of rounds had elapsed. This is a plausible multi-agent system, but it does not establish much of a need for A2A. If the orchestrator owns the workflow and each reviewer performs one narrow function, the reviewers can be modeled as tools such as `steelman_design` and `adversarial_review` . Their implementations may contain models, tools, memory, and complicated reasoning, but none of that changes the contract presented to the orchestrator. Long-running work does not provide a reliable dividing line either. Current MCP task support allows a tool call to return a durable handle that can be polled, cancelled, and supplied with additional input. An MCP server can therefore place a sophisticated agent behind a tool without forcing the caller to wait on one synchronous request. The choice between MCP and A2A has less to do with the intelligence of the remote implementation than with the relationship between the two systems. The strongest use case for A2A begins when the remote agent operates independently, represents a different principal, and has meaningful discretion over whether or how it fulfills the request. Consider a manufacturer that needs to purchase 10,000 components by November. The manufacturer has a procurement agent with access to its technical requirements, inventory forecasts, approved suppliers, budget, and internal purchasing policies. A supplier has its own sales agent with access to inventory, production capacity, pricing rules, existing customer commitments, and the approvals required for large orders. These agents are participating in the same transaction, but they represent different organizations. Neither organization wants to expose its internal systems or decision-making process to the other, and neither agent has authority over its counterpart. “Counterparty-to-counterparty” would be more precise than “adversary-to-adversary,” although it would make for a considerably worse title. The procurement agent might begin by requesting ten thousand units of a particular component, along with a required delivery date and a set of technical specifications. The supplier agent checks its systems and determines that it can deliver 6,000 units in October and the remaining 4,000 in December. It could satisfy the full order in November using an alternative component, although that component costs more and has slightly different characteristics. The supplier returns those options rather than a simple success or failure. The procurement agent then needs to determine whether engineering has approved the substitute component, whether split delivery would affect production, and whether the higher price falls within its purchasing authority. The agents may exchange several proposals before reaching an agreement. The manufacturer might accept the alternative component in exchange for a lower price, while the supplier might offer that discount only if the manufacturer agrees to a longer-term commitment. Either side may need to pause while a human approves a commercial term. They may also exchange specification sheets, compliance certificates, shipping schedules, quotes, and purchase orders during the process. The supplier agent retains control over how it calculates pricing and allocates inventory, while the procurement agent retains control over its budget and approval process. Their interaction requires communication and coordination without requiring either organization to reveal the internal machinery behind its decisions. The supplier could expose this process through MCP. It might publish tools such as `request_quote` , `check_inventory` , `propose_shipping_schedule` , `submit_purchase_order` , and `accept_offer` . For a mature and predictable purchasing process, that may be exactly the right design. The tool schemas would give both parties explicit contracts, and the MCP Tasks extension could handle operations that require time or additional information. As the interaction becomes more open-ended, however, each possible turn requires another operation or another convention layered onto the existing operations. The alternative is a broad tool such as `negotiate_with_supplier` that accepts a prompt and returns whatever the remote agent decides to produce. That approach works, but it has effectively placed an agent behind a function-shaped interface that contributes very little structure of its own. [A2A provides a general message-and-task model](https://a2a-protocol.org/latest/topics/key-concepts/) for this kind of relationship. The supplier publishes an Agent Card describing its identity, service endpoint, authentication requirements, supported communication formats, and skills. An A2A skill is largely descriptive. It tells potential clients what the agent is likely to be capable of, provides examples, and identifies supported input and output formats without turning every capability into a separately callable operation. The procurement agent can discover that the supplier handles product inquiries, commercial proposals, and order fulfillment without learning how those activities are implemented internally. The procurement agent sends a message containing its goal and can attach structured requirements, specification documents, or other context. The supplier may answer with another message or create an A2A Task representing the ongoing transaction. That task has its own lifecycle and can accumulate messages, status changes, requests for additional information, and concrete artifacts. A quote is an artifact. So are a compliance certificate, shipping schedule, and purchase order. The negotiation can remain flexible while its important outputs become structured objects associated with a durable unit of work. MCP still fits naturally into this architecture. The procurement agent may use MCP to query the manufacturer’s ERP, inspect inventory forecasts, or initiate an internal approval workflow. The supplier agent may use MCP to check production capacity, calculate pricing, reserve inventory, and create an order. Those tool interactions occur within each organization’s environment, where the agent is authorized to use a known set of capabilities. A2A carries the interaction across the organizational boundary, where each participant retains its own authority and implementation. The same transaction can use both protocols because the agent-to-tool relationship inside each organization differs from the relationship between the two organizations’ agents. This distinction is architectural rather than absolute. A supplier can expose an API or an MCP server, and many suppliers should continue doing exactly that. Adding an agent to a familiar business process does not automatically improve the process or justify a more flexible protocol. A2A becomes useful when the remote party needs enough discretion that representing the entire relationship as a catalog of caller-controlled operations starts working against the design. Administrative independence is the important characteristic: the remote agent has its own identity, policies, systems, lifecycle, and authority to reject or counter the request. A2A also does not make this interaction trustworthy by itself. The protocol allows an Agent Card to declare authentication requirements, while authorization remains the responsibility of the server. The supplier must determine which products, prices, tasks, and artifacts a particular caller may access. The manufacturer must decide what its procurement agent is allowed to request or accept, and consequential commitments will often require human approval. Credentials, task visibility, audit records, and tenant boundaries remain ordinary security and governance responsibilities even when the participants communicate through an agent protocol. Natural-language flexibility should receive similar treatment. Messages are useful for expressing goals, clarifying requirements, and discussing proposals, but they should not become the sole representation of a commercial commitment. Quantities, currencies, prices, delivery dates, approvals, and signatures belong in structured and auditable artifacts. A2A messages can carry structured data and files alongside text, so the protocol does not require an organization to choose between flexible communication and precise records. The agents can negotiate in language while the resulting agreement remains suitable for software systems, auditors, and humans who would prefer not to infer the final price from a transcript. A2A had already [moved from Google to the Linux Foundation in 2025](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents), so joining AAIF is primarily an organizational consolidation rather than the protocol’s first move into neutral governance. It does, however, make the intended architecture easier to see. MCP provides a standard way for agents to use tools and data. A2A provides a standard way for independently operated agents to communicate, delegate work, and exchange results. Housing both projects in AAIF reflects an institutional view that mature agent systems may need both relationships. None of this guarantees that A2A will become the standard for communication across organizational boundaries. Interoperability will depend on implementations, conformance, security, and whether organizations find enough value in exposing agents rather than conventional APIs. The protocol also brings unnecessary overhead when all of the participants belong to one application and perform narrow roles controlled by one orchestrator. In those systems, internal subagents, framework-level orchestration, or MCP tools are usually easier to understand and operate. The boundary that makes A2A useful is the presence of another principal. A remote capability that belongs to your workflow can usually be represented as a tool. A remote agent that controls its own systems, follows its own policies, and has the authority to negotiate or refuse a request presents a different kind of interface. Agent-to-Agent is the official name for that relationship. Adversary-to-Adversary may occasionally be the more revealing one.