When two agents built by different companies need to work together, they face the same problem two computers faced at the dawn of the internet. Without a shared protocol, a common set of rules for how to speak, they cannot understand one another at all. The reason any browser can open any website is that everyone agreed, long ago, on a handful of protocols. The agent economy needs the same thing, and two standards have emerged to provide it. They solve two different halves of the problem, and they fit together.

The downward connection: an agent and its tools

The first half is how an agent connects to its own tools, the resources it uses to get work done, such as a database it must read, a search service it must query, or an internal function it must call. The widely adopted standard for this is the Model Context Protocol, usually shortened to MCP, introduced by Anthropic. Before a standard like this, every connection between an agent and a tool had to be wired up by hand, in its own particular way, which meant endless custom work and brittle results. MCP gives an agent a consistent way to discover a tool, learn what that tool can do, and use it. Think of it as a universal adapter. Once a tool speaks MCP, any agent that speaks MCP can pick it up and use it without bespoke plumbing.

The sideways connection: an agent and its peers

The second half is how one agent talks to another agent, including one built by a company it has never heard of. The emerging standard here is the Agent-to-Agent protocol, or A2A, introduced by Google and now developed in the open under the Linux Foundation with the support of a large number of major technology companies. A2A lets an agent do the things cooperation requires. It can publish a description of what it is able to do, discover other agents that offer what it needs, agree on the terms of a task, and hand that task off, whether the work takes a second or several days. If MCP is the adapter that connects an agent downward to its tools, A2A is the common tongue that connects an agent sideways to its peers.

The agent card, and why discovery matters

A2A leans on a simple and powerful idea called the agent card. An agent publishes a machine-readable description of itself, a kind of business card, that states what it does, how to reach it, and what it needs in return. Other agents read these cards to find a suitable partner for a job, the way you might scan a directory of services. Discovery, the act of one agent finding another, is largely handled by this mechanism, and it works well. The harder question, which the Identity page takes up, is not how one agent finds another but whether it can believe what the card says.

How they work together, in one picture

Imagine an inventory agent at a small shop that notices stock is running low. It uses MCP to check its own stock database, confirms the shortage, and then uses A2A to reach a supplier's ordering agent, negotiate the order, and place it. Two protocols, two directions, one smooth chain of work that crosses a company boundary without a human lifting a finger. Multiply that by every routine task a business runs, and you begin to see why a shared language for agents is not a technical footnote but the thing that makes the whole economy possible.

An honest boundary

It is worth being clear about what these standards do and do not provide, because it is easy to assume that solving communication solves everything. A shared language lets agents talk. It does not, by itself, prove that the agent on the other end is who it claims to be, decide what that agent should be allowed to do, or settle who answers when something goes wrong. Those are separate and harder problems, and they are the subject of the Identity page and the Rules of Engagement. Because adoption of these standards moves quickly, the newest figures and integrations live in the Analysis section rather than here, which keeps this explanation steady as the field changes around it.