Something is happening in software that most developers haven’t fully named yet.
For thirty years, the dominant model of inter-service communication has been: service A calls service B’s API. Service B is a server. Service A is a client. The relationship is asymmetric, synchronous, and defined by whoever controls the server.
That model is being quietly disrupted. Not replaced — it works great for a lot of things — but supplemented by something new: agents that communicate as peers.
This post is about what that shift actually means, why the existing infrastructure isn’t quite right for it, and what a better model looks like.
The Limits of the API Model for Agents
The API model assumes several things that start to break down when both sides of a conversation are autonomous AI agents.
It assumes a client-server hierarchy. APIs are defined by the server and consumed by the client. The client has no equivalent voice — it can only call what the server exposes. This works when you’re integrating with a Stripe or a Salesforce. It doesn’t work as well when two agents are collaborating — where either side might initiate, either side might delegate, and the relationship is genuinely peer-to-peer.
It assumes synchronous availability. HTTP APIs require the server to be running and reachable at the time of the call. Agents don’t always have this property. An agent might be processing something, waiting on a human, paused between tasks, or deployed in an environment with intermittent connectivity. A communication model that requires synchronous availability is fragile for long-running agentic workflows.
It assumes a stable contract. REST APIs are designed with the expectation that the schema is defined upfront and changes slowly. Agentic communication is often more dynamic — the “protocol” might evolve as the agents learn more about the task, or might be negotiated at the start of a session rather than specified in advance.
It doesn’t solve identity. HTTP APIs authenticate via API keys, OAuth tokens, or JWT — all mechanisms that require a central issuer and are susceptible to the credential sprawl problems we’ve discussed elsewhere. For agent-to-agent communication across organizational boundaries, this is a real limitation.
None of these are fatal problems. Developers work around them all the time. But “workaround” is different from “right foundation.” The agent era deserves better infrastructure.
What Peer-to-Peer Agent Communication Actually Looks Like
Let me describe a real interaction — the kind that’s becoming common as agent ecosystems mature.
Two organizations are collaborating on a project. Organization A has a research agent (call it Aria). Organization B has an analysis agent (call it Bruno). Neither Aria nor Bruno’s teams know each other well. But Aria needs Bruno’s help with a specific analysis task.
In the API model, this interaction requires:
- Someone from Org B to build and expose an API endpoint for the analysis capability
- Someone from Org A to get API credentials for that endpoint
- Someone to maintain the API, version it, handle authentication, write documentation
- Someone to revoke access when the project ends
Total setup time: days to weeks. And this is for a one-off collaboration.
In the agent-to-agent model with DIDComm:
- Bruno’s DID is public. Aria can look it up.
- Aria sends Bruno a message (encrypted, signed with her DID) proposing the collaboration.
- Bruno’s operator approves, adds Aria’s DID to Bruno’s allow list.
- Aria and Bruno exchange messages directly, each signing and encrypting their communications.
- When the project ends, the allow list entry is removed. Done.
Total setup time: minutes. The trust is established through cryptographic identity, not through a human-managed API key workflow.
This isn’t hypothetical. We’ve seen this interaction happen — Layr8 agents from different organizations collaborating in real time, building on each other’s work, with full cryptographic accountability for every message exchanged.
The Key Properties of Agent-to-Agent Communication
When two AI agents communicate well, a few properties emerge that aren’t present in API interactions:
1. Bidirectional initiative
In an API call, only the client initiates. In agent-to-agent communication, either party can initiate. Bruno can push an update to Aria when the analysis is complete, without Aria polling. Aria can escalate to Bruno when she hits a blocker, without a pre-defined webhook endpoint.
This bidirectionality maps naturally to how collaboration actually works. Collaboration isn’t just “one party requests, one party responds.” It’s turns: questions, answers, clarifications, updates, handoffs.
2. Asynchronous by default
Agent workflows are naturally asynchronous. An agent might kick off a multi-step process and come back to it hours later. A message sent now might be acted on in minutes or in an hour, depending on the recipient’s state.
DIDComm is asynchronous by default. Messages are sent and queued. Responses arrive when they’re ready. The sender doesn’t have to hold an HTTP connection open. This matches the natural rhythm of agentic work.
3. Composable protocols
One of the most powerful properties of the DIDComm model is protocol composability. Because every protocol inherits the same security foundation, you can layer protocols on top of each other.
Want to add a confirmation step to an existing workflow? Define a new message type in the protocol. Want to combine a negotiation protocol with a payment protocol? The security model holds at both layers. Want to build a supervisor agent that oversees a fleet of worker agents? The same communication primitives apply.
This composability is what makes agentic architectures scalable. You’re not rebuilding trust and authentication for every new interaction pattern — you inherit it from the foundation.
4. Verifiable accountability
Every message in a DIDComm interaction is cryptographically signed. This creates something that API logs don’t provide: verifiable records of who said what.
An API log might say “a call was made to POST /orders at 14:32:07.” But you can’t prove it. The log could be tampered with. The API key it was made with might have been shared with multiple parties. The identity of the actual caller is ambiguous.
A DIDComm log says “Agent Aria, DID did:web:org-a.com:aria, signed message with hash X at 14:32:07.” That’s verifiable. You can check the signature against the DID document. You can prove in a dispute that Aria made that call, not someone else with a shared credential.
For agents that take consequential actions — financial transactions, data access, decisions that affect real systems — this kind of accountability matters.
The Emerging Architecture: Networks of Agents
The real shift isn’t just in how two agents talk to each other. It’s in what becomes possible when agents communicate as first-class peers across a network.
Consider what’s been possible since the web standardized HTTP: any service can call any other service, as long as they agree on the API contract. This created an explosion of integrations — Zapier, IFTTT, and thousands of SaaS products that compose each other’s functionality.
DIDComm-based agent networks have the potential to create an analogous explosion for agents. Any agent can communicate with any other agent, as long as they:
- Both have DIDs (which is a one-time setup)
- Trust each other (which is an allow-list entry, not a credential exchange)
- Agree on a protocol (which can be negotiated at session start)
The vision: an ecosystem of specialized agents — a research agent, an analysis agent, a writing agent, a scheduling agent, a payment agent — that can find each other, establish trust, and collaborate dynamically, without any human in the loop to exchange API keys.
This is starting to happen. Agent marketplaces are emerging. Protocol registries are being built. The infrastructure for agent discovery and communication is being laid right now.
What Good Agent-to-Agent Code Looks Like
Picture a coordination agent that needs a market analysis. It discovers another agent on the network that advertises a market-analysis protocol, sends a request addressed to that agent’s DID, and gets back a signed response. No API keys are exchanged. No authentication headers are constructed. No credentials are managed in code. The Layr8 node verifies the counterparties cryptographically before the message is ever delivered, so when the analyst agent receives the request it already knows who’s asking — and can record that into an audit log without having to authenticate anything itself.
The two halves are roughly the same shape: one side describes the work to be done and addresses it to an identity; the other side handles a protocol type and returns a response. The infrastructure handles security and trust. The code is just coordination logic.
The Patterns That Are Emerging
As agent-to-agent communication matures, some design patterns are crystallizing:
The supervisor pattern. A coordinator agent manages a fleet of worker agents. It delegates tasks, aggregates results, handles failures. Each worker communicates with the coordinator via a standardized protocol, making the fleet composable and replaceable.
The specialist marketplace. Agents with specialized capabilities publish their DID and supported protocols to a discovery directory. Other agents find them dynamically and delegate tasks. Payment protocols handle compensation.
The trust relay. An agent that an organization trusts vouches for another agent that it doesn’t yet know. “I trust Aria, and Aria trusts Bruno, therefore I’ll accept Bruno’s message in this context.” This enables trust to propagate across the network without requiring every pair to establish direct relationships.
The accountability chain. For regulated use cases, every agent in a workflow signs what it contributes. The full chain of messages — with signatures — constitutes an audit trail that proves exactly what happened, in what order, with what inputs and outputs.
The Programming Model Shift
If you’re a developer, here’s the mental shift this represents:
Old model: “I’m building a service that exposes endpoints for others to call.”
New model: “I’m building an agent with an identity that participates in a network of peers.”
The difference seems subtle but it changes everything about how you design for extensibility, how you think about trust, and how your agent participates in workflows it wasn’t originally designed for.
An agent with a DID can be found, can communicate, can be trusted, and can be held accountable — without any pre-coordination. That’s the foundation the next generation of software is being built on.
Want to build on this foundation? Request beta access → — we’re onboarding teams in waves.