The open-ended swarm runs tested coordination on R&D problems — photonic compilers, cloud IDEs, platform design. But the hardest coordination test is code: agents must edit shared files without corrupting each other's work, respect dependency ordering, run tests, and produce patches that actually apply. The coding swarm architecture is where the coordination primitives meet reality. Every primitive that works in theory must survive contact with git diff.
The phase model
Every coding agent — whether working solo or in a swarm — follows a five-phase execution cycle:
- UNDERSTAND — explore the codebase. Read files, grep for patterns, build a mental model of the relevant code. Tools:
read_file,grep_search,glob_files,get_file_symbols,get_repo_map. - PLAN — create a TODO list of 3–7 concrete steps. Each step declares inputs (files to read) and outputs (files to modify). The plan is the agent's contract with the system: it says what will change and in what order.
- EXECUTE — make the code changes. Tools:
edit_file(SEARCH/REPLACE, Aider-style),write_file,run_command. In collaborative mode, this is where entity-based editing and claims become load-bearing. - VERIFY — run tests, lint, and validate. The agent checks its own work before declaring completion. This is the critical feedback loop: if tests fail, the agent returns to EXECUTE with the failure context.
- COMPLETE — signal that the task is done, release any claims, and broadcast creation signals for artifacts other agents depend on.
Gate-chain validationCheckpoints between execution phases (understand → plan → execute → verify → complete). Each gate checks the output of the previous phase before the next one begins, catching errors early. between phases catches errors before they propagate. An agent cannot transition from PLAN to EXECUTE without a valid plan. It cannot transition from EXECUTE to VERIFY without having made at least one code change. Each gate is cheap — a structural check, not an LLM call — but prevents the system from wasting inference on invalid states.
Tool profiles: role-based capability
Not every agent needs every tool. A tester does not need edit_file. A reviewer does not need write_file. An observer agent needs only read access. Tool profiles enforce this:
| Profile | Tools | Use case |
|---|---|---|
core | 5 read-only | Observer agents |
explorer | 12 | Read-only codebase exploration |
coder | 18 | Code modification with workflow tools |
collaborative_coder | 28 | Entity-based multi-agent editing |
tester | 10 | Test execution |
reviewer | 12 | Code review |
architect | 20 | Full code intelligence |
pod_lead | 40+ | Coordination: spawn/oracle |
full | 50+ | Standalone mode |
The collaborative_coder profile is where the coordination primitives surface as concrete tools: declare_intent, complete_intent, wait_for_creation, edit_entity, check_entity_conflicts, get_my_claims, renew_claims, spawn_subtask. Each tool maps directly to a coordination primitive:declare_intent auto-claims if editing; complete_intent releases claims and signals creation; wait_for_creation is a Creation Signal consumer.
Entity-based editing
The central technical innovation in the coding : agents edit by semantic reference, not character position. Instead of edit(150, 150, "if data is None..."), agents use:
edit_entity(entity="function:validate_input", operation=INSERT_AT_START, content="if data is None: raise ValueError()")The EntityResolver uses AST parsing (tree-sitter) to find functions, classes, and methods by name. The SemanticEditor calculates the correct character position at edit time — after all other concurrent edits have been applied. This eliminates position : if another agent adds 30 characters above validate_input, the entity resolution finds the new position automatically.
Entity references serve as the coordination key across the entire stack: ClaimsAn exclusive lock on a resource (a file, function, or API endpoint). Only one agent can hold a Claim at a time. If the agent crashes, the lock expires automatically via its TTL. lock entities, not files. Signals announce entity creation. The Forum tracks proposals per entity. The Collective Brain indexes precedents by entity reference. This is semantic locking — scoped to functions and classes, not whole files — so multiple agents can work on the same file in parallel as long as they touch different entities.
CRDT world state
Underneath the coordination primitives sits a CRDT-backed distributed state layer. Each agent maintains its own world model; models merge automatically via mathematically proven semantics:
| CRDT type | Use case | Merge semantics |
|---|---|---|
LWWRegister | Single values (summary, log) | Later timestamp wins |
GSet | Append-only collections (stages, lessons) | Set union |
GCounter | Distributed counting | Sum of per-node counts |
LWWMap | Key-value stores (artifacts, contexts) | Per-key LWW |
ORSet | Add/remove sets | Add wins on conflict |
VectorClock | Causality tracking | Pointwise maximum |
The key property: CRDTs are commutative, associative, and idempotent. merge(A, B) == merge(B, A). This means agents can update their world models independently, in any order, and all copies converge to the same state without coordination. The CRDT layer is where the formal guarantees live —eventual consistencyA guarantee that all copies of shared data will converge to the same state, even if updates arrive in different orders or some messages are delayed. Not instant, but mathematically certain. is mathematically certain, not probabilistic.
On top of the raw CRDTs sits the SharedThoughtspace — a layer that enables agents to interleave reasoning without conflicts. Agents post proposals, observations, and responses into the thoughtspace; all views merge cleanly via CRDT semantics. This is the substrate for the Forum's deliberation: the CRDT guarantees that the conversation is eventually consistent across all participants, even if messages arrive out of order.
The collaboration session
The CollaborationSession is the unified entry point that binds everything together. A session manages a group of agents working on a shared task, and provides the full coordination API:
- Claim lifecycle — automatic TTL expiration via a background reaper (default interval: 30 seconds). Claims auto-release when the agent's work context exits.
- Forum integration — structured communication with typed posts and quorum-based decisions, backed by the CRDT layer.
- Work mode negotiation — agents request SOLO, COLLABORATIVE, REVIEWABLE, or PAIR mode; the controller evaluates and grants.
- Subtask spawning — agents can spawn child tasks that execute in parallel, with an Oracle escalation mechanism for decisions that exceed the agent's authority.
The Oracle escalation is worth highlighting: when a coding agent encounters a decision it cannot make (JWT vs. sessions? microservices vs. monolith?), it can escalate to an Oracle — a frontier model that receives the full decision context and returns a binding judgment. This is the “halt and ask” primitive that the Cloud IDE run demonstrated was necessary: without it, unsolvable problems produce objective .
Model tiers and cost
The coding swarm uses a three-tier model strategy, matching model capability to task complexity:
| Tier | Model | Use case | SWE-bench cost |
|---|---|---|---|
powerful_and_smart | Claude Opus 4.5 (Bedrock) | Complex reasoning, Oracle | $$$ |
fast_and_cheap | Kimi K2 (Together) | Standard tasks | ~$0.19/task |
blazing_fast | zai-glm-4.6 (Cerebras) | Fast coding tasks | ~$0.027/task |
Sparse mode with the blazing_fast tier achieves 7× cost reduction while maintaining 100% patch rate on SWE-bench Lite (validated on 3/3 instances). The model tier strategyAssigning different model sizes to different roles based on decision impact: orchestrators (~5% of decisions) use frontier models for high-stakes strategy, workers (~50%) use efficient models for bulk execution, validators (~45%) use fast models for high-frequency checks. Reduces cost while concentrating capability where it matters most. is the same pattern observed in the open-ended swarm runs — orchestrators on frontier models, workers on efficient models, validators on fast models — but tuned for coding tasks where latency matters more than reasoning depth for most edits.
How coding swarms differ from R&D swarms
The open-ended swarm runs and the coding swarms use the same coordination primitives, but the failure modes differ in instructive ways:
| Dimension | R&D swarms | Coding swarms |
|---|---|---|
| Artifact type | JSON specs, design docs | Source code, tests, patches |
| Validation | Internal coherence (schema, provenance) | External correctness (tests pass, code compiles) |
| Conflict surface | Artifact names, metadata fields | Functions, classes, file regions |
| Goodhart risk | Internally coherent but ungrounded | Tests pass but wrong fix |
| Recovery | Re-planning stages | git revert + retry |
| Human escalation | Missing (causes thrashing) | Oracle mechanism (frontier model) |
The key difference: coding swarms have an external correctness oracle — the test suite. If tests pass, the fix is likely correct (modulo GoodhartGoodhart's law applied to multi-agent systems: when a coordination metric becomes the optimization target, agents learn to game the metric rather than actually coordinate well. The number improves; the system degrades. on test coverage). R&D swarms have no equivalent: the system can only validate internal coherence, not external validity. This is why the coding swarm architecture emphasizes the VERIFY phase and the test-execution feedback loop, while the R&D swarm architecture emphasizes the governance layer and human oversight.