Agent-to-agent discovery and invocation without a server in the middle
MCP and every major agent framework assume client-server and connectivity. Service Discovery is the peer-to-peer alternative: agents advertise capabilities, discover peers multi-hop, and invoke request/response, authenticated with OfflineID sessions.
Peers discover and invoke each other multi-hop over the mesh
No registry service, no DNS, no round trip to a data center
BLE to WiFi Direct switch with no coordination gap
The same mesh runs across 80+ countries
On-device AI has outrun its coordination layer
Every framework assumes a server
MCP, tool registries, and orchestration layers are client-server designs. Two agents on adjacent devices still coordinate through a data center that may be seconds away or unreachable.
Inference moved on-device, coordination didn't
Models run locally for latency, cost, and privacy. Routing every tool call back through the cloud gives all three back.
No trust model between peer agents
When agents do talk peer-to-peer, authentication is improvised. There is no standard way for one agent to verify another without a lookup service.
On-device coordination for on-device AI
Agents advertise capabilities
An agent registers what it can do, a tool, a model, a data source, and peers within 8 hops discover it through multi-hop routing. No registry service, no DNS.
Invocation is request/response
Calling a peer agent's capability looks like calling an API endpoint, with acknowledgment, retry, and deduplication handled by the transport. A device five hops away is invocable directly.
Sessions are authenticated by default
Every invocation runs inside an OfflineID-authenticated, MLS-encrypted session. Agents verify each other device-to-device with Ed25519 keys that never leave the device.
This is the only discovery-and-invocation primitive in production that survives losing the internet. How Service Discovery works →
What you can build for agent-to-agent coordination
Concrete peer-to-peer agent capabilities you can integrate today on the SDK primitives, no named-customer required.
You can build peer-to-peer tool calls with no server
An agent registers a tool through Service Discovery, and any peer within 8 hops discovers and invokes it request/response. Calling a peer looks like calling an API endpoint, with acknowledgment and retry at the transport, and no cloud broker in the middle.
You can build local inference shared across devices
A device with a loaded model advertises an inference capability. Nearby agents discover it and send classification or generation requests with no cloud access, so one model serves many devices over the mesh.
You can build authenticated agent sessions offline
Every invocation runs inside an OfflineID-authenticated, MLS-encrypted session. Agents verify each other device-to-device with Ed25519 keys that never leave the device, so peer-to-peer agent communication has a trust model without a lookup service.
How offline AI agents find and call each other
- Discovery
- Multi-hop broadcast over BLE and WiFi Direct. No registry service, no lookup API, no round trip to a data center.
- Invocation
- Request/response with acknowledgment and retry handled by the transport, correlated so many calls run at once.
- Trust
- Ed25519 identities verified device-to-device. The credential is the keypair, checked with local math.
- In practice
- An agent registers a capability once with metadata and a version; any peer within 8 hops discovers it, compares providers by hop distance and version, and invokes the closest inside an MLS-encrypted session. The same TypeScript-over-Rust SDK coordinates autonomous fleets in GPS-denied environments. Start building →
Client-server versus peer-to-peer agent coordination
An on-device AI agent discovers and invokes a tool on a peer agent over the mesh, peer to peer with no cloud broker, no server, and no internet between the devices.
Figure 1. The caller agent discovers the tool on a peer device, verifies the provider with OfflineID, and invokes it request/response over the mesh. No cloud broker, no registry server, no internet between the two devices.
The primitives behind peer-to-peer agents
Discovery and invocation without a broker
Agents advertise capabilities, discover peers multi-hop, and invoke request/response. This is the peer-to-peer alternative to MCP client-server, and the two can coexist with the mesh as the transport.
How service discovery works →Peer-to-peer transport under the agents
DORS routes agent traffic over BLE and WiFi Direct with automatic failover. The internet is one transport among several, not a requirement, so adjacent agents coordinate directly.
How mesh networking works →Agents verify each other offline
Every agent carries an Ed25519 self-sovereign identity verifiable device-to-device with no connectivity, and every session is MLS-encrypted. A caller proves who it is before an invocation runs.
How offline identity works →What your team can implement
Each capability is a shipped SDK primitive. Follow the link to the reference.
Peer-to-peer capability invocation
Expose a tool or model as a discoverable service and invoke it request/response.
→Multi-hop agent transport
Route agent traffic device to device over BLE and WiFi Direct with failover.
→Offline agent authentication
Verify a peer agent device-to-device with an Ed25519 OfflineID.
→Provider selection metadata
Compare providers by hop distance and version before sending a request.
→MLS-encrypted sessions
Run every invocation inside an authenticated, encrypted session by default.
→Chunked payload transfer
Move model inputs and results up to 100MB across the mesh in ordered chunks.
→TypeScript SDK on a Rust core
Build agents in TypeScript over the Rust core on iOS and Android.
→Read the coordination docs
API reference for advertising, discovering, and invoking capabilities.
→What agent teams run on the mesh
Each pattern uses the same three primitives: register a capability with metadata, discover providers with their hop distance and version, invoke request/response with delivery confirmed by the transport.
Local inference as a service
A device with a loaded model registers an inference capability. Nearby agents discover it and send classification or generation requests without cloud access, sharing one model across many devices.
Distributed computation
One agent registers a compute service; peers discover it, send work units, and collect results. Long-running jobs split across the devices in range instead of a data center.
Shared context and content
Agents with cached maps, documents, or embeddings register as content providers. Others fetch from the nearest peer, keeping retrieval local even when the internet is not.
AI agents FAQ
Can AI agents communicate without the internet?
Yes. With Service Discovery, agents advertise capabilities, discover peers, and invoke each other request/response over BLE and WiFi Direct with multi-hop relay up to 8 hops. The internet is one transport among several, not a requirement, so two agents on adjacent devices coordinate directly.
Is there a peer-to-peer alternative to MCP for agent tool calls?
MCP standardizes how a client talks to a tool server. Service Discovery removes the server: capabilities are advertised, discovered, and invoked peer-to-peer over the mesh. The two can coexist, with the mesh as the transport under an MCP-shaped interface.
What does an agent capability look like on the wire?
A named capability with a request/response contract. Invocations carry acknowledgment, retry, and deduplication at the transport layer, and run inside MLS-encrypted sessions.
Does this work when devices are fully offline?
Yes. Discovery and invocation run over BLE and WiFi Direct with multi-hop relay up to 8 hops. The internet is one transport among several, not a requirement.
Which platforms can host an agent?
iOS and Android through the React Native binding over a Rust core. Anything that runs the core can advertise and invoke capabilities.
How does a consumer pick between multiple providers?
Discovery responses carry each provider’s peer ID, version, capability metadata, and hop distance, so an agent can select the closest provider, the newest version, or the one advertising the capability it needs before sending a request.
