A2A protocol: interoperability needs a task contract

Google introduced Agent2Agent on 9 April 2025 as an open protocol for agents built by different vendors or frameworks. The launch described support from more than 50 technology partners and framed interoperability as a way to connect siloed enterprise applications. That participation established an ecosystem ambition, not evidence that every partner had a production-compatible implementation. 1

The important unit is delegated work. One agent asks another to perform a task without needing access to its internal reasoning or implementation. Procurement should therefore distinguish protocol support from proof that a particular pair of products can complete the intended business transaction.

An agent card describes capabilities and how a remote agent can be contacted. Treat that description as discovery metadata, not permission to send confidential material. A claimed skill does not establish the provider’s data-handling terms or the requesting user’s authority. Validate the endpoint and organizational ownership before delegation.

For example, a purchasing agent might discover a supplier-checking agent. It should send only the fields needed for that check, not the entire procurement file. Broader deployment strategy belongs in enterprise agents; this integration requires a specific agreement about inputs, outputs and responsibility.

A remote task may take longer than one request-response exchange. The requesting application needs to know whether work is queued, running, waiting for input, finished or failed. A conversational acknowledgement is not a business completion signal. Decide which returned state permits downstream action and which requires human intervention.

Preserve the task identifier across retries and reconnects. If an approval request arrives after the originating browser closes, someone must still own it. Test interrupted connections and delayed responses before assuming that a successful short demonstration represents a durable cross-company workflow.

MCP commonly connects an AI application to tools and resources. A2A addresses collaboration with another agent that can manage its own work. They can coexist: the remote agent may use MCP internally while exposing a delegated task through A2A. Neither protocol removes the need for ordinary APIs underneath.

Choose based on responsibility. A database lookup often needs a tool contract; an external specialist producing a review may need a task contract. Company knowledge explains why connected information matters, but transferring information and transferring ownership of work are separate design decisions.

Define the artifact before commissioning the task: a structured assessment, source list or updated business record. A polished answer should not count as completion if required evidence is absent. Validate identifiers and required fields in ordinary application code before accepting the remote result.

Set a time budget and escalation path when agents disagree or ask for more information. Agent safety covers the wider permission model. The distinctive interoperability control is a verifiable acceptance condition shared across organizations, so that the requester and provider do not silently use different meanings of done.

Pilot a single task between independently operated systems rather than a large mesh of agents. Include rejected access, malformed artifacts, cancellation and a remote endpoint upgrade. Record whether the workflow recovers without repeating consequential actions. These are recommended tests, not measured guarantees of the protocol.

The output should be an interoperability record covering versions, ownership, data categories and accepted failure behavior. Use advisory to frame the evaluation if needed. The 2025 announcement opened a collaboration layer; operational value depends on whether a specific business boundary can now be crossed predictably.