Synapse Agents vs Claude Code Coordinator
Two real systems that orchestrate multiple AI agents. One is visual and geospatial. The other is textual and code-centric. Same ambition, radically different designs. What can they learn from each other?
How do you make multiple AIs collaborate without stepping on each other?
Synapse Studio — our product at CadencesLab — solves it with agents patrolling an interactive real-time map, connected via WebSockets and backed by a persistent database. Claude Code solves it with code agents working in parallel Git worktrees, coordinated by XML tags and running in ephemeral memory.
Same problem. Opposite solutions. This article isn't a "which is better" — it's an analysis of two real architectures in production, and the lessons each can take from the other.
⚡ Context
This article is part of a series of 4 comparisons between patterns discovered in the Claude Code analysis and real systems we build at CadencesLab.
This isn't marketing in disguise. We point out where Claude Code is superior, where Synapse is, and where both have pending work.
The Synapse Agent Pipeline
Synapse Studio organizes AI agents around a real-time interactive map. Each agent has a geospatial position, a set of behaviors (patrol, respond, idle) and the ability to interact with the virtual world and project data.
🌐 Pipeline Architecture
// synapse-pipeline.js (930 lines) Pipeline: Ingestion → Processing → Emission Ingestion: ├── WebSocket events (real-time) ├── REST API (95 endpoints) └── Scheduled tasks (heartbeat) Processing: ├── Agent behaviors (patrol/respond/idle) ├── Geospatial reasoning (coordinates, routes, zones) └── State updates (D1 persistent + in-memory ephemeral) Emission: ├── Canvas 2D rendering (map) ├── WebSocket broadcasts (clients) └── Event log (audit)
The core of Synapse is a centralized pipeline: a 930-line function that receives events, decides which agents should act, executes their behaviors in sequence, and emits results to the map. It's a pull-based model — the pipeline controls the pace.
Each agent's state persists in Cloudflare D1 (edge SQLite database), with an ephemeral in-memory layer for session data. This means agents survive restarts, disconnections, and deploys. An agent patrolling the north zone of a map picks up exactly where it left off.
Claude Code's Coordinator Mode
Claude Code uses a radically different pattern: a central coordinator that can only do three things — create agents (Agent), stop tasks (TaskStop), and send messages to the user (SendMessage). It can't read files. It can't run commands. It can't edit code.
🤖 Coordinator Architecture
// coordinatorMode.ts
Coordinator (restricted):
├── Agent tool → spawn worker with task
├── TaskStop → signal completion
└── SendMessage → talk to the user
Workers (full toolset):
├── BashTool, FileReadTool, FileEditTool
├── GrepTool, GlobTool, ListDirTool
└── Isolated Git worktree per worker
Communication:
├── Coordinator → Worker: plaintext task
├── Worker → Coordinator: status reports (every 30s)
└── Format: XML tags (<status>3-5 words</status>)
Parallelism:
└── /batch → 5-30 simultaneous worktree agents The philosophy is extreme: the coordinator is intentionally weak. It can't execute anything directly — only delegate. This prevents the "the boss does everything" antipattern. Workers, on the other hand, have full access to the filesystem, terminal, and code tools.
Each worker operates in an isolated Git worktree — a lightweight copy of the repository where it can make changes without affecting others. It's the equivalent of giving each programmer their own temporary branch. When done, the coordinator merges the results.
"Parallelism is your superpower" — literal instruction from Claude Code's coordinator system prompt. The coordinator doesn't optimize quality; it optimizes throughput.
Comparison Table
| Aspect | Synapse Studio | Claude Code |
|---|---|---|
| Domain | Geospatial / visual | Code / text |
| Max agents | ~50 per map | 5-30 per batch |
| Communication | WebSocket real-time | XML tags async |
| State | D1 (persistent) + in-memory | In-memory + overlay FS |
| Orchestration | Centralized pipeline | Coordinator pattern |
| Parallelism | Visual (map) | Worktree isolation |
| Feedback | Canvas rendering | Terminal status lines |
| Persistence | ✓ Yes (DB) | ✗ No (per-session) |
| Human-in-loop | Director review panel | Plan mode / ask |
The most revealing difference is the state model. Synapse persists everything — an agent can "remember" what it was patrolling yesterday. Claude Code is entirely ephemeral: when the session ends, workers vanish. This isn't a bug — it's a design decision. Claude Code workers don't need memory because each task is atomic: "edit this file," "run these tests," "create this PR."
What Synapse Can Learn from Claude Code
1. Separate Orchestrator from Workers
Synapse's pipeline (930 lines) does too much: receives events, decides which agents act, executes behaviors, and emits results. All in one function. Claude Code's coordinator is intentionally limited — it can only delegate. It can't "cheat" by executing code directly.
Application: Split synapse-pipeline.js into a pure coordinator (that only assigns tasks) and independent workers (that execute behaviors). Benefit: the pipeline can't become a bottleneck.
2. Worker Micro-Statuses
Claude Code requires each worker to report its state in 3-5 present-tense words: "Editing auth module", "Running test suite". Brutal but effective for UX — you know what each agent is doing without reading logs.
Application: Synapse could show micro-statuses in map tooltips — "Patrolling north zone", "Analyzing incident" — instead of just generic state indicators.
3. Per-Worker Isolation
Each Claude Code worker operates in its own Git worktree — a completely isolated context. It can't see what other workers are doing. This eliminates race conditions by design.
Application: Give each Synapse agent an isolated "data viewport" — a database subset that only that agent can modify. Merge changes at the end, like Git.
What Claude Code Can Learn from Synapse
1. Persistent State
Synapse agents survive restarts, deploys, and disconnections. If an agent was analyzing route 7, upon reconnection it's still on route 7. Claude Code workers are one-shot: they finish and vanish.
Potential benefit: Workers that remember their context would enable multi-session tasks — "keep refactoring tomorrow where you left off."
2. Visual Feedback
Synapse shows agents moving on a 2D canvas in real-time. You see their progress, route, and state instantly. Claude Code shows text lines in a terminal — the 3-5 word status reports are functional but limited.
Potential benefit: A DAG-style visualization (directed acyclic graph) where each worker is a node, their dependencies are edges, and state updates in real-time.
3. Behavior System
Synapse agents have behaviors as state machines: patrol → detect → respond → idle. Each behavior defines what the agent does and when it switches modes. Claude Code workers don't have behaviors — they're single tasks.
Potential benefit: Workers with behaviors like implement → test → fix → verify instead of executing everything in a single monolithic prompt.
4. Spatial Context
Synapse agents have spatial awareness: they know where they are, what's nearby, and how they relate geospatially to other agents. Claude Code workers have no sense of the codebase's "topology."
Potential benefit: Workers that understand code "geography" — which modules are nearby, which files are related, where there's "density" of recent changes.
The Best of Both Worlds
If we could take the best of each system, what would the ideal orchestrator look like?
🔮 Hybrid Design
Coordinator pattern (from Claude Code) + geospatial pipeline (from Synapse): an orchestrator that doesn't execute, only delegates — but with spatial domain awareness.
Worktree isolation (from Claude Code) + persistent state (from Synapse): isolated workers that don't step on each other, but can resume work between sessions.
Status reports (from Claude Code) + visual rendering (from Synapse): 3-5 word micro-statuses rendered in an interactive DAG, not just terminal text.
Behavior state machines (from Synapse) + tool permission model (from Claude Code): agents with defined behaviors AND granular per-phase permissions.
It's Not About Who Wins — It's About What We Learn
Synapse and Claude Code Coordinator are products of different worlds. Synapse was born in the world of geospatial intelligence and real-time visualization. Claude Code was born in software engineering and code productivity. Comparing them "head to head" would be unfair and pointless.
What is useful is seeing which architectural patterns cross the domain boundary. Claude Code's coordinator pattern is universal — it works equally well for coordinating code edits and map patrols. Synapse's persistent state is equally transferable — any multi-agent system benefits from workers that survive interruptions.
The best lessons come from contrasts, not similarities. Claude Code chose ephemeral workers and Synapse chose persistent ones — and both decisions are correct for their respective contexts. The question isn't which is better, but when the answer changes.
The AI agents industry moves fast. What's a "domain-specific" pattern today becomes a universal pattern tomorrow. Multi-agent orchestration won't be visual or textual — it'll be both.
Building agents with LLMs?
At Cadences we design multi-agent systems using patterns we've discovered analyzing Claude Code and building Synapse. If you want to apply these principles to your business, let's talk.
Gonzalo Monzón
Founder of CadencesLab. Software engineer, Synapse Studio architect, and AI agent architecture analyst. This article comes from months building one multi-agent system and some days reverse-engineering another.