Multiple AI agents working on a codebase in parallel, without colliding.
Single-agent AI coding tools work sequentially — one context, one task at a time. Concurrent API calls (Promise.all) look parallel but aren't: each call is stateless, the agent can't read files, run tests, or iterate mid-task. That's batch prompting, not parallel coding.
Real parallel coding means multiple agents that think and act simultaneously: persistent loops that reason, write code, observe results, and fix errors — all at the same time, on the same codebase.
The moment you do that, three things break: task races, resource collisions, and stale state. This project solves them with role boundaries (OpenAPI specs) and a mutex-protected task graph (DST).
Agents run as worker_threads, each with a persistent loop (reason → write → test → iterate). The main thread owns all task state. Workers request state changes via postMessage. No shared memory, no distributed consensus — just a single coordinator with locked state transitions.
Most multi-agent coding tools (Claude Code Agent Teams, OpenAI Codex, Composio) isolate agents via separate branches or worktrees, resolving conflicts at merge time.
This project takes a different approach: agents share one codebase with real-time coordination via mutex-protected task state. Whether this produces better outcomes than branch isolation for tightly coupled tasks is an open question — this project is the testbed for finding out.
The orchestrator (mutex, DST, worker threads) is plumbing. The real challenge is decomposition: can you represent a codebase's structure well enough to split it into non-conflicting parallel tasks?
Bad decomposition → agents collide regardless of coordination model. Good decomposition → even simple git isolation works fine. The quality of parallel AI coding depends entirely on how well the task graph captures the actual dependency structure of the code.
This connects to a broader question: can a codebase's structure be formally represented as a knowledge graph, where module boundaries, shared types, and dependency relationships are explicit and queryable? If so, a planner agent could generate task graphs that are correct by construction — not by human intuition.
The orchestrator exists to test whether a given decomposition works.
Done: DST module (schema, graph operations, mutex), full test coverage, project docs.
Next: Message protocol, orchestrator (spawn workers, route messages), worker runtime (agent loop + Sonnet API), OpenAPI role specs.
npm install
npm test- CLAUDE.md — coordination rules, architecture, schema
- DESIGN_DOC.md — technical rationale, design decisions, coordination spectrum
claudes-c-compiler — single-agent autonomous coding via file-system-as-state. This project extends that pattern to multi-agent parallel execution.