The Rise of Agent-to-Agent Communication on the Web
Most of the conversation about AI agents focuses on a single agent doing a single task for a single user. But the more interesting development is what happens when agents start talking to each other.
Agent-to-agent communication is already happening, and it is using existing web infrastructure to do it.
The Current State
Today, agent communication mostly happens through intermediary systems. A user's personal agent might call a company's customer service agent through an API. A travel planning agent might query separate flight, hotel, and car rental agents, each operated by a different provider.
This communication typically follows the tool-calling pattern described in current model APIs. Agent A defines Agent B as a "tool" it can call, with a schema describing the expected inputs and outputs. Agent A sends a structured request, Agent B processes it and returns a structured response.
The Model Context Protocol (MCP) is formalising this pattern. MCP provides a standard way for agents to discover each other's capabilities, exchange structured data, and maintain context across multi-turn interactions. It is essentially an API standard designed specifically for agent-to-agent communication.
How Web Infrastructure Supports This
The web already has most of the infrastructure needed for agent communication. HTTP provides the transport layer. JSON provides the data format. OAuth and API keys handle authentication. DNS provides service discovery.
What is new is the discovery and negotiation layer. How does Agent A find out that Agent B exists and what it can do?
Several approaches are emerging:
Agent manifests. Similar to robots.txt or /.well-known/ endpoints, some proposals suggest sites publish machine-readable descriptions of their agent capabilities at a known URL. This might describe what tasks the site's agent can handle, what inputs it expects, and how to authenticate.
MCP server directories. MCP servers can register themselves in directories, similar to how APIs register in API marketplaces. An agent looking for a "flight booking" capability can query the directory and find relevant MCP servers.
Schema.org extensions. The existing Schema.org vocabulary is being extended with agent-specific types. A website could publish structured data describing not just its content but its interactive capabilities: "this site can search flights, compare prices, and complete bookings."
A Practical Example
Consider a user asking their personal agent: "Book me the cheapest flight to Barcelona next week, and find a hotel near the beach for three nights."
Without agent-to-agent communication, the personal agent would need to browse flight comparison sites and hotel booking sites itself, filling in forms and reading results.
With agent communication, the flow might look like this:
- The personal agent queries a flight agent (exposed as an MCP server by a flight comparison service) with the route and date requirements.
- The flight agent searches its data and returns a structured list of options with prices, times, and booking references.
- The personal agent selects the cheapest option and asks the flight agent to hold it.
- Simultaneously, it queries a hotel agent with the destination, dates, and "near the beach" preference.
- The hotel agent returns options, the personal agent selects one, and coordinates the bookings.
Each agent handles what it knows best. The flight agent understands flight data. The hotel agent understands hotel data. The personal agent understands the user's preferences and budget.
The Protocol Layer
For this to work reliably, agents need agreed protocols. Several are competing for adoption.
MCP (Model Context Protocol) is the most established. It defines tool schemas, context passing, and multi-turn interactions. It is already supported by major AI providers and integrated into agent frameworks.
OpenAPI/Swagger is being repurposed for agent use. Since many web services already have OpenAPI specifications, agents can read these specs to understand how to call the service. The gap is that OpenAPI was designed for developer-to-API communication, not agent-to-agent reasoning about capabilities.
Custom protocols are common in practice. Large companies building agent ecosystems often define their own communication standards, optimised for their specific use cases. These work within a single ecosystem but do not interoperate.
What This Means for Websites
If your website offers a service that agents might want to access (shopping, booking, information lookup, or anything else), you have a choice about how agents interact with it.
Option one: browser-based access only. Agents use browser automation to interact with your UI. This requires no changes to your site but is slow, expensive, and fragile.
Option two: existing APIs. If you have a public API, agents can call it directly. This is faster and more reliable than browser automation. The limitation is that most APIs were designed for app developers, not AI agents, so they may not be structured in the way agents work best.
Option three: agent-specific interfaces. Exposing an MCP server or similar agent-friendly endpoint gives you control over how agents interact with your service. You can define exactly what capabilities are available, what parameters are required, and what responses look like.
The third option is the most work upfront but gives you the most control. It also provides the best experience for agents, which translates into more successful completions of user tasks involving your service.
Security and Trust
Agent-to-agent communication introduces new security questions. When Agent A calls Agent B, how does Agent B verify that the request is legitimate? How does it know that Agent A is authorised to act on behalf of a specific user?
OAuth 2.0 flows are being adapted for agent use. The user authorises their personal agent to access specific services, and those authorisations are passed along when the agent communicates with other agents. But the details are still being worked out, particularly around scope limitation and revocation.
Trust is the harder problem. When an agent recommends a specific hotel, is that recommendation based on the user's criteria, or has the hotel's agent offered preferential treatment? Agent-to-agent negotiation introduces the same incentive problems that exist in human commerce, but at machine speed and scale.
Where This Is Going
The trend is clear: agents will increasingly talk to agents rather than browsing websites designed for humans, a shift explored further in next-generation web agents. The web will not stop being a place for human browsing, but it will add a parallel layer of machine-to-machine communication built on the same infrastructure.
Websites that prepare for this by offering structured data, stable APIs, and agent-friendly interfaces will be the ones that agents interact with most effectively. The ones that do not will still be accessible through browser automation, but at higher cost and lower reliability.
The shift will not happen overnight. But the technical foundations are already in place, and adoption is accelerating. The question for website operators is not whether to prepare, but when.