Service Bindings: La Red Privada de Agentes en Cloudflare Workers
Cómo 4 agentes se comunican en un mesh sin supervisor central, con service bindings directos, descubrimiento dinámico y circuit breaker natural. PDB como memoria compartida, MCP como protocolo común.
Gonzalo Monzón
7 julio, 2026 · Serie: Arquitectura — Cómo se Comunican los Agentes (2/3)
TL;DR
La mayoría de sistemas multi-agente usan un orquestador central. Nosotros construimos un mesh cognitivo: cada agente se comunica directamente con quien necesita mediante service bindings de Cloudflare Workers. No hay un jefe. Hay 5 reglas: MCP como protocolo, PDB como verdad compartida, llamadas directas sin cola central, contexto incrustado en cada llamada, y memoria responsable (cada agente guarda lo suyo). Si un nodo falla, el mesh se reconfigura solo. Segundo artículo de la serie Arquitectura.
¿Un jefe o un mesh?
La mayoría de sistemas multi-agente que vemos tienen un problema de base: un orquestador central que todo lo decide. Eso funciona hasta que el orquestador se satura, o hasta que los agentes tienen que esperar turno para hablar.
Nosotros tomamos otro camino: un mesh cognitivo donde cada agente se comunica directamente con quien necesita. Sin cola central. Sin cuello de botella. Sin "jefe".
┌──────────┐
│ Hermes │◄── Telegram / Discord
└────┬─────┘
│ MCP
┌──────────┼──────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│ Zalo │ │ Lisa │ │ Tom │
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
└────────┼────────┘
▼
┌───────┐
│ PDB │
└───────┘
No hay un "jefe". Hay service bindings directos entre Workers. PDB es la memoria compartida.
Las 5 reglas del mesh
MCP como protocolo común
Cada agente expone MCP — cualquier agente puede llamar a cualquier otro con el mismo estándar
PDB como verdad compartida
El estado del sistema vive en ^GLOBAL. Si un agente muere, el estado no muere con él
Sin cola central
Cada llamada es directa vía service binding. Si el destino no responde en 5s, se cancela — no hay reintento automático
Contexto en la llamada
No hay estado global que sincronizar — el contexto viaja con cada petición MCP
Memoria responsable
Cada agente es responsable de su propia memoria. Zalo no guarda lo que Tom aprende, y viceversa
Descubrimiento dinámico: ¿quién hace qué?
¿Cómo sabe Hermes a quién llamar para cada tarea? No tiene un mapa fijo. Cada petición entrante se evalúa en caliente:
1. Hermes recibe el mensaje → Zalo (el que mejor entiende contexto)
2. Zalo decide si resuelve solo o necesita a Tom (clasificar), Lisa (analizar) o Hermes (ejecutar)
3. Si Zalo no está seguro, pregunta: "Tom, ¿esto es clasificable?" → 260ms → ya sabe
4. Las decisiones de ruteo se guardan en PDB como patrones → la próxima vez, el mesh sabe sin preguntar
No hay un service registry. No hay un orquestador central. Hay un patrón que emerge de las decisiones de cada agente, registrado en PDB para que el sistema sea más rápido con cada iteración.
Circuit breaker natural
Si un nodo falla, el mesh no se rompe — se reconfigura solo:
- 🔄 Si Tom no responde, Zalo lo reintenta con backoff exponencial. Si sigue sin responder, cambia de modelo (CHEAP → QWEN)
- ⏳ Si Lisa está ocupada, Zalo espera y reintenta. Lisa tiene un solo hilo de orquestación — no acepta más trabajo del que puede gestionar
- 🛡️ Si Hermes cae, los agentes del Edge siguen funcionando: acumulan decisiones, KB, patrones. Cuando Hermes vuelve, sincronizan
No hay un interruptor central. Es un comportamiento emergente: cada agente sabe cuándo insistir y cuándo esperar. Y como no hay un orquestador central, no hay un solo punto de fallo.
Un usuario pide un análisis por Telegram
1. Hermes recibe: "Analiza este PDF y dime si es relevante"
2. Hermes → Zalo (MCP): "procesa este mensaje"
3. Zalo evalúa trust → 8.5 → puede proceder
4. Zalo → Tom (service binding): "clasifica: relevante/no"
5. Tom devuelve: "relevante (conf: 0.92)"
6. Zalo → Lisa (service binding): "analiza este contenido"
7. Lisa orquesta: analyze → plan → execute → judge
8. Lisa escribe resultado en PDB
9. Zalo lee PDB, formatea respuesta
10. Zalo → Hermes: "aquí tienes el análisis"
11. Hermes responde al usuario
Todo en segundos. Sin un orquestador central. Sin colas. Sin bloqueos. 11 pasos, 4 agentes, 0 intermediarios.
Mapa completo de bindings
| Binding | Origen → Destino | Tipo | Latencia |
|---|---|---|---|
| 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 | Todos → PDB | D1 binding | ~5 ms * |
* Solo lectura para Tom y Lisa. Solo Hermes escribe en PDB.
MCP vs Service Bindings
| Dimensión | MCP (HTTP) | Service Bindings |
|---|---|---|
| Estándar | Abierto (Anthropic) | Propietario (Cloudflare) |
| Latencia | ~8-25 ms | ~0 ms |
| Descubrimiento | tools/list | Definido en wrangler.toml |
| Provider | Cualquiera | Solo Cloudflare |
| Fallback | — | HTTP (automático) |
No necesitas un supervisor central
La arquitectura de mesh cognitivo demuestra que se puede construir un sistema multi-agente robusto sin un orquestador central. Solo necesitas tres cosas:
🔗
Protocolo común
MCP como estándar de comunicación entre todos los agentes
🧠
Memoria compartida
PDB como fuente de verdad única y persistente
⚡
Comunicación directa
Service bindings entre nodos, sin intermediarios
El resto es coordinación emergente. Y funciona.
Serie: Arquitectura — Cómo se Comunican los Agentes (2/3)
← Anterior
MCP sin BridgesSiguiente →
Dashboards en VivoTodos los artículos de la serie:
Y todo esto se monitoriza en vivo
El último artículo de la serie: dashboards que muestran el estado real de cada agente, el coste por llamada, la latencia y las incoherencias detectadas.
Serie Arquitectura — 3 artículos. Cadences Lab © 2026.