How do AI agents talk to each other without a server?

Two open protocols describe how AI agents connect to tools and to each other, and both assume something the caller can reach.

The Model Context Protocol (MCP) follows a client-host-server design. A host application creates clients, and each client talks to exactly one server. Servers expose tools, resources and prompts, and the specification says they can be local processes or remote services. Its two standard transports are stdio, where the client launches the server as a subprocess and they exchange messages over standard input and output, and Streamable HTTP, where each message is an HTTP POST to a single endpoint. The pattern is asymmetric: servers do not initiate JSON-RPC requests.

The Agent2Agent (A2A) protocol, an open project under the Linux Foundation, is built for agents to work with other agents. Each A2A server publishes an Agent Card, a JSON document describing its identity, skills, endpoint and authentication requirements. Clients find cards at a well-known HTTPS URL on the agent’s domain, through registries, or by direct configuration. The specification defines JSON-RPC, gRPC and HTTP+JSON bindings, and Agent Cards may be signed with JSON Web Signature so clients can check they have not been altered.

So “without a server” can mean three different things. A local MCP server over stdio already needs no network, because it runs on the same machine. Agents that use A2A need an IP route to each other’s endpoints. And an agent whose model runs in the cloud needs the internet for its own reasoning, whatever protocol it uses to reach other agents.

If agents share a local IP network but no DNS server or registry, they can use the same mechanism that lets computers, printers and smart TVs find each other on a home network. Multicast DNS, RFC 6762, performs DNS-like operations on the local link with no conventional DNS server, using names ending in .local. DNS-Based Service Discovery, RFC 6763, lets a client discover a list of named instances of a service type using ordinary DNS queries.

libp2p, a peer-to-peer networking stack, uses mDNS for peer discovery on the same local network without configuration. Its specification defines a DNS-SD service name, _p2p._udp.local, and peers answer a query with TXT records listing the addresses they listen on.

These methods are scoped to the local link. They need devices on the same network segment, with multicast allowed, and they say nothing about whether a discovered peer should be trusted. How do devices discover services without a server or DNS? covers the options in more detail.

Agents can also run on phones, handhelds, vehicles and robots. Two of them can be a metre apart with no shared Wi-Fi and no internet, and every method above stops working. What they may still share is a short-range radio such as Bluetooth Low Energy.

Device-to-device software can carry the same three steps agents need, over that radio and across several hops:

1. Advertise a capability, such as “I can read this equipment’s status”.
2. Discover which nearby devices offer it.
3. Invoke it with a request and receive a response.

Offline Protocol’s MeshServices follows this pattern: a device registers a service, others discover it and send requests across the mesh. In v0.27.0 those advertisements, requests and responses are signed plaintext. They are attributable and tamper-evident, but devices that relay or overhear them can read them, so confidential content belongs in MLS-encrypted messages instead.

Removing the server removes the place where policy lives in a client-server design. The application on each device has to take over three jobs.

• Authorization. Discovery tells you who offers a capability, not who may use it. Each provider needs its own list of approved callers, and each caller its own list of approved providers. A digital signature proves which device sent a message; it does not prove the device is allowed to ask.
• Confidentiality. Signing and encrypting are different properties. A signed request can still be read by every relay, and even encrypted traffic shows metadata such as timing and size.
• Failure handling. A request with no reply does not prove the work was not done. Give each request a deadline, retry only read-only operations freely, and use an operation ID so a retried action with side effects is applied only once.

None of this replaces MCP or A2A where a server is reachable. It covers the stretch where it is not, and a design can use both paths and pick whichever is available.