Synapse Agents vs Claude Code Coordinator
Dos sistemas reales que orquestan múltiples agentes IA. Uno es visual y geoespacial. El otro es textual y code-centric. Misma ambición, diseños radicalmente diferentes. ¿Qué pueden aprender el uno del otro?
¿Cómo haces que varias IAs colaboren sin pisarse entre ellas?
Synapse Studio — nuestro producto en CadencesLab — lo resuelve con agentes que patrullan un mapa interactivo en tiempo real, conectados por WebSockets y respaldados por una base de datos persistente. Claude Code lo resuelve con agentes de código que trabajan en worktrees paralelos de Git, coordinados por XML tags y ejecutándose en memoria efímera.
Mismo problema. Soluciones opuestas. Este artículo no es un "es mejor que" — es un análisis de dos arquitecturas reales, en producción, y las lecciones que cada una puede tomar de la otra.
⚡ Context
Este artículo forma parte de una serie de 4 comparaciones entre patrones descubiertos en el análisis de Claude Code y los sistemas reales que construimos en CadencesLab.
No es publicidad disfrazada. Señalamos dónde Claude Code es superior, dónde Synapse lo es, y dónde ambos tienen trabajo pendiente.
El Pipeline de Agentes de Synapse
Synapse Studio organiza agentes IA alrededor de un mapa interactivo en tiempo real. Cada agente tiene una posición geoespacial, un conjunto de comportamientos (patrol, respond, idle) y la capacidad de interactuar con el mundo virtual y los datos del proyecto.
🌐 Arquitectura del Pipeline
// synapse-pipeline.js (930 líneas) Pipeline: Ingesta → Procesamiento → Emisión Ingesta: ├── WebSocket events (tiempo real) ├── API REST (95 endpoints) └── Scheduled tasks (heartbeat) Procesamiento: ├── Agent behaviors (patrol/respond/idle) ├── Geospatial reasoning (coordenadas, rutas, zonas) └── State updates (D1 persistent + in-memory ephemeral) Emisión: ├── Canvas 2D rendering (mapa) ├── WebSocket broadcasts (clientes) └── Event log (auditoría)
Lo central de Synapse es un pipeline centralizado: una función de 930 líneas que recibe eventos, decide qué agentes deben actuar, ejecuta sus comportamientos en secuencia, y emite los resultados al mapa. Es un modelo pull-based — el pipeline controla el ritmo.
El estado de cada agente se persiste en Cloudflare D1 (base de datos SQLite at the edge), con una capa efímera in-memory para datos de sesión. Esto significa que los agentes sobreviven a reinicios, desconexiones y deploys. Un agente que estaba patrullando la zona norte de un mapa retoma exactamente donde estaba.
Coordinator Mode de Claude Code
Claude Code usa un patrón radicalmente diferente: un coordinador central que solo puede hacer tres cosas — crear agentes (Agent), parar tareas (TaskStop) y enviar mensajes al usuario (SendMessage). No puede leer archivos. No puede ejecutar comandos. No puede editar código.
🤖 Arquitectura del Coordinator
// coordinatorMode.ts
Coordinator (restringido):
├── Agent tool → spawn worker con tarea
├── TaskStop → señalizar fin
└── SendMessage → hablar con el usuario
Workers (toolset completo):
├── BashTool, FileReadTool, FileEditTool
├── GrepTool, GlobTool, ListDirTool
└── Git worktree aislado por worker
Comunicación:
├── Coordinator → Worker: tarea en texto plano
├── Worker → Coordinator: status reports (cada 30s)
└── Formato: XML tags (<status>3-5 words</status>)
Paralelismo:
└── /batch → 5-30 worktree agents simultáneos La filosofía es extrema: el coordinator es intencionalmente débil. No puede ejecutar nada directamente — solo delegar. Esto previene el antipatrón de "el jefe hace todo". Los workers, en cambio, tienen acceso completo al filesystem, terminal y herramientas de código.
Cada worker opera en un Git worktree aislado — una copia ligera del repositorio donde puede hacer cambios sin afectar a los demás. Es el equivalente de dar a cada programador su propia rama temporal. Cuando termina, el coordinator fusiona los resultados.
"Parallelism is your superpower" — instrucción literal del system prompt del coordinator de Claude Code. El coordinador no optimiza calidad; optimiza throughput.
Tabla Comparativa
| Aspecto | Synapse Studio | Claude Code |
|---|---|---|
| Dominio | Geoespacial / visual | Código / texto |
| Agentes máx. | ~50 por mapa | 5-30 por batch |
| Comunicación | WebSocket real-time | XML tags async |
| Estado | D1 (persistent) + in-memory | In-memory + overlay FS |
| Orquestación | Pipeline centralizado | Coordinator pattern |
| Paralelismo | Visual (mapa) | Worktree isolation |
| Feedback | Canvas rendering | Terminal status lines |
| Persistencia | ✓ Sí (DB) | ✗ No (per-session) |
| Human-in-loop | Director review panel | Plan mode / ask |
La diferencia más reveladora es el modelo de estado. Synapse persiste todo — un agente puede "recordar" qué patrullaba ayer. Claude Code es totalmente efímero: cuando la sesión termina, los workers desaparecen. Esto no es un bug — es una decisión de diseño. Los workers de Claude Code no necesitan memoria porque cada tarea es atómica: "edita este archivo", "corre estos tests", "crea este PR".
Lo que Synapse Puede Aprender de Claude Code
1. Separar Orquestador de Workers
El pipeline de Synapse (930 líneas) hace demasiado: recibe eventos, decide qué agentes actúan, ejecuta comportamientos y emite resultados. Todo en una función. El coordinator de Claude Code es intencionalmente limitado — solo puede delegar. No puede "hacer trampa" ejecutando código directamente.
Aplicación: Splitear synapse-pipeline.js en un coordinator puro (que solo asigna tareas) y workers independientes (que ejecutan comportamientos). Beneficio: la pipeline no puede convertirse en bottleneck.
2. Microestados de Workers
Claude Code exige que cada worker reporte su estado en 3-5 palabras en presente: "Editing auth module", "Running test suite". Es brutal pero efectivo para UX — sabes qué hace cada agente sin leer logs.
Aplicación: Synapse podría mostrar microestatus en tooltips del mapa — "Patrullando zona norte", "Analizando incidencia" — en lugar de solo indicadores de estado genéricos.
3. Aislamiento por Worker
Cada worker de Claude Code opera en su propio Git worktree — un contexto completamente aislado. No puede ver qué hacen los demás workers. Esto elimina race conditions por diseño.
Aplicación: Dar a cada agente de Synapse un "viewport de datos" aislado — un subconjunto de la base de datos que solo ese agente puede modificar. Merge de cambios al final, como Git.
Lo que Claude Code Puede Aprender de Synapse
1. Estado Persistente
Los agentes de Synapse sobreviven a reinicios, deploys y desconexiones. Si un agente estaba analizando la ruta 7, al reconectar sigue en la ruta 7. Claude Code workers son one-shot: terminan y desaparecen.
Beneficio potencial: Workers que recuerden su contexto permitirían tareas multi-sesión — "sigue refactorizando mañana donde lo dejaste".
2. Feedback Visual
Synapse muestra agentes moviéndose en un canvas 2D en tiempo real. Ves su progreso, ruta, y estado instantáneamente. Claude Code muestra líneas de texto en terminal — los status reports de 3-5 palabras son funcionales pero limitados.
Beneficio potencial: Una visualización tipo DAG (grafo acíclico dirigido) donde cada worker es un nodo, sus dependencias son aristas, y el estado se actualiza en tiempo real.
3. Sistema de Comportamientos
Los agentes de Synapse tienen behaviors como state machines: patrol → detect → respond → idle. Cada comportamiento define qué hace el agente y cuándo cambia de modo. Los workers de Claude Code no tienen comportamientos — son tareas únicas.
Beneficio potencial: Workers con behaviors como implement → test → fix → verify en lugar de ejecutar todo en un solo prompt monolítico.
4. Contexto Espacial
Los agentes de Synapse tienen spatial awareness: saben dónde están, qué hay cerca, y cómo se relacionan geoespacialmente con otros agentes. Claude Code workers no tienen conciencia de la "topología" del codebase.
Beneficio potencial: Workers que entiendan la "geografía" del código — qué módulos están cerca, qué archivos están relacionados, dónde hay "densidad" de cambios recientes.
El Mejor de Ambos Mundos
Si pudiéramos tomar lo mejor de cada sistema, ¿cómo sería un orquestador ideal?
🔮 Diseño Híbrido
Coordinator pattern (de Claude Code) + geospatial pipeline (de Synapse): un orquestador que no ejecuta, solo delega — pero con awareness espacial del dominio.
Worktree isolation (de Claude Code) + persistent state (de Synapse): workers aislados que no se pisan, pero que pueden retomar trabajo entre sesiones.
Status reports (de Claude Code) + visual rendering (de Synapse): microestados de 3-5 palabras renderizados en un DAG interactivo, no solo texto en terminal.
Behavior state machines (de Synapse) + tool permission model (de Claude Code): agentes con comportamientos definidos Y permisos granulares por fase.
No Es Quién Gana — Es Qué Aprendemos
Synapse y Claude Code Coordinator son productos de mundos diferentes. Synapse nació en el mundo del geospatial intelligence y la visualización en tiempo real. Claude Code nació en el mundo del software engineering y la productividad de código. Compararlos "mano a mano" sería injusto e inútil.
Lo que sí es útil es ver qué patrones arquitectónicos cruzan la frontera entre dominios. El coordinator pattern de Claude Code es universal — funciona igual para coordinar ediciones de código que para coordinar patrullas en un mapa. El persistent state de Synapse es igualmente transferible — cualquier sistema multi-agente se beneficia de workers que sobreviven a interrupciones.
Las mejores lecciones vienen de los contrastes, no de las similitudes. Claude Code eligió workers efímeros y Synapse eligió workers persistentes — y ambas decisiones son correctas para sus contextos. La pregunta no es cuál es mejor, sino cuándo cambia la respuesta.
La industria de AI agents se mueve rápido. Lo que hoy es un patrón "de dominio" mañana es un patrón universal. La orquestación multi-agente no va a ser visual o textual — va a ser ambas cosas.
¿Construyes agentes con LLMs?
En Cadences diseñamos sistemas multi-agente con los patrones que hemos descubierto analizando Claude Code y construyendo Synapse. Si quieres aplicar estos principios a tu negocio, hablemos.
Gonzalo Monzón
Fundador de CadencesLab. Ingeniero de software, arquitecto de Synapse Studio y analista de arquitecturas de agentes IA. Este artículo nace de meses construyendo un sistema multi-agente y unos días reverse-engineering otro.