Service Bindings: The Private Agent Network on Cloudflare Workers
How 4 agents communicate in a mesh without a central supervisor, with direct service bindings, dynamic discovery, and natural circuit breaker. PDB as shared memory, MCP as the common protocol.
Gonzalo Monzón
July 7, 2026 · Series: Architecture — How Agents Communicate (2/3)
TL;DR
Most multi-agent systems use a central orchestrator. We built a cognitive mesh: each agent communicates directly with whoever it needs to via Cloudflare Workers service bindings. There's no boss. There are 5 rules: MCP as the protocol, PDB as shared truth, direct calls without a central queue, context embedded in each call, and responsible memory (each agent stores its own). If a node fails, the mesh reconfigures itself. Second article of the Architecture series.
A Boss or a Mesh?
Most multi-agent systems we see have a fundamental problem: a central orchestrator that decides everything. That works until the orchestrator gets saturated, or until agents have to wait their turn to speak.
We took a different path: a cognitive mesh where each agent communicates directly with whoever it needs. No central queue. No bottleneck. No "boss".
┌──────────┐
│ Hermes │◄── Telegram / Discord
└────┬─────┘
│ MCP
┌──────────┼──────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│ Zalo │ │ Lisa │ │ Tom │
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
└────────┼────────┘
▼
┌───────┐
│ PDB │
└───────┘
There's no "boss". There are direct service bindings between Workers. PDB is the shared memory.
The 5 Rules of the Mesh
MCP as the common protocol
Each agent exposes MCP — any agent can call any other using the same standard
PDB as shared truth
System state lives in ^GLOBAL. If an agent dies, the state doesn't die with it
No central queue
Each call is direct via service binding. If the destination doesn't respond in 5s, it's canceled — no automatic retry
Context in the call
There's no global state to sync — context travels with each MCP request
Responsible memory
Each agent is responsible for its own memory. Zalo doesn't store what Tom learns, and vice versa
Dynamic Discovery: Who Does What?
How does Hermes know who to call for each task? It doesn't have a fixed map. Each incoming request is evaluated hot:
1. Hermes receives the message → Zalo (the one who best understands context)
2. Zalo decides whether to handle it alone or needs Tom (classify), Lisa (analyze), or Hermes (execute)
3. If Zalo isn't sure, it asks: "Tom, is this classifiable?" → 260ms → now it knows
4. Routing decisions are saved to PDB as patterns → next time, the mesh knows without asking
There's no service registry. There's no central orchestrator. There's a pattern that emerges from each agent's decisions, recorded in PDB so the system gets faster with every iteration.
Natural Circuit Breaker
If a node fails, the mesh doesn't break — it reconfigures itself:
- 🔄 If Tom doesn't respond, Zalo retries with exponential backoff. If it still doesn't respond, it switches model (CHEAP → QWEN)
- ⏳ If Lisa is busy, Zalo waits and retries. Lisa has a single orchestration thread — it doesn't accept more work than it can handle
- 🛡️ If Hermes goes down, the Edge agents keep running: they accumulate decisions, KB, patterns. When Hermes comes back, they sync
There's no central switch. It's an emergent behavior: each agent knows when to insist and when to wait. And since there's no central orchestrator, there's no single point of failure.
A User Requests an Analysis via Telegram
1. Hermes receives: "Analyze this PDF and tell me if it's relevant"
2. Hermes → Zalo (MCP): "process this message"
3. Zalo evaluates trust → 8.5 → can proceed
4. Zalo → Tom (service binding): "classify: relevant/not"
5. Tom returns: "relevant (conf: 0.92)"
6. Zalo → Lisa (service binding): "analyze this content"
7. Lisa orchestrates: analyze → plan → execute → judge
8. Lisa writes result to PDB
9. Zalo reads PDB, formats response
10. Zalo → Hermes: "here's the analysis"
11. Hermes responds to the user
All in seconds. Without a central orchestrator. Without queues. Without locks. 11 steps, 4 agents, 0 intermediaries.
Complete Binding Map
| Binding | Source → Destination | Type | Latency |
|---|---|---|---|
| ZALO_SERVICE | Hermes → Zalo | MCP HTTP | ~8 ms |
| TOM_SERVICE | Zalo → Tom | Service binding | ~1 ms |
| LISA_SERVICE | Zalo → Lisa | Service binding | ~1 ms |
| TOM_LISA | Tom → Lisa | Service binding | ~1 ms |
| PDB_BINDING | All → PDB | D1 binding | ~5 ms * |
* Read-only for Tom and Lisa. Only Hermes writes to PDB.
MCP vs Service Bindings
| Dimension | MCP (HTTP) | Service Bindings |
|---|---|---|
| Standard | Open (Anthropic) | Proprietary (Cloudflare) |
| Latency | ~8-25 ms | ~0 ms |
| Discovery | tools/list | Defined in wrangler.toml |
| Provider | Any | Cloudflare only |
| Fallback | — | HTTP (automatic) |
You Don't Need a Central Supervisor
The cognitive mesh architecture proves you can build a robust multi-agent system without a central orchestrator. You only need three things:
🔗
Common Protocol
MCP as the communication standard between all agents
🧠
Shared Memory
PDB as the single source of truth, persistent
⚡
Direct Communication
Service bindings between nodes, no intermediaries
Everything else is emergent coordination. And it works.
Series: Architecture — How Agents Communicate (2/3)
← Previous
MCP Without BridgesNext →
Agent DashboardsAll articles in this series:
And All This Is Monitored Live
The last article in the series: dashboards that show the real-time status of each agent, cost per call, latency, and detected inconsistencies.
Architecture Series — 3 articles. Cadences Lab © 2026.