A fixed spawn order with 4 roles (orchestrator, observer, worker, specialist) will provide predictable parallel Claude Code execution

Hypothesis

A fixed spawn order with 4 roles (orchestrator, observer, worker, specialist) will provide predictable parallel Claude Code execution

Changelog

Date	Summary
2026-04-06	Audited: added Changelog, domain tag, expanded Hypothesis/Method/Findings/Next Steps, stamped last_audited
2026-03-10	Initial creation

---

Hypothesis

We bet that a fixed 4-role spawn order would eliminate the race conditions we kept hitting when launching parallel Claude Code agents. Without a defined order, each agent competed for the same initialization resources : the PTY process pool, the WebSocket server port, the shared config file. The hypothesis: name the roles, fix the launch sequence, and the chaos goes away.

Method

Designed the 4-role architecture: Kommando (orchestrator : assigns work, holds the master plan), Mekboy (worker : executes code changes), Weirdboy (specialist : handles research, web search, context retrieval), and Painboy (observer : monitors the other agents and flags conflicts). Each role gets a distinct CLAUDE.md directive that scopes its behavior.

Implemented spawn/kill UI with +/- buttons for manual warband management. The spawn button always starts the next role in the fixed sequence (Kommando first, then Mekboy, Weirdboy, Painboy). WebSocket protocol carries control messages (spawn, kill, status) and terminal output (binary frames) between the backend and the frontend.

Results

Confirmed. Fixed spawn order eliminates initialization race conditions. The orchestrator (Kommando) always starts first and claims its resources before any other agent boots. WS protocol provides real-time status without polling : each agent pushes state changes as they happen.

The first practical validation: three Mekboys running in parallel on different files produced a clean merge because Kommando assigned non-overlapping file paths before spawning them.

Findings

1. Naming roles is not ceremony : it enforces contracts. Calling a process “Kommando” is not cosmetic: it means the CLAUDE.md for that slot contains orchestration directives, not execution directives. The name is the interface contract.

2. Fixed spawn order is a coordination protocol. The deterministic sequence (1, 2, 3, 4) means any component that needs to reference “the orchestrator” can always use index 0. Dynamic role assignment would require role discovery, which adds latency and error modes.

3. The +/- paradigm matches how developers think. “I need more help” (+) and “wrapping up” (-) are natural mental models for scaling a work session, more intuitive than managing individual process lifecycles.

Next Steps

The 4-role concept validated, but the prototype used a simple bash-based process manager that lacked PTY fidelity and proper state tracking. The next step is building the full monorepo (gork backend, mork frontend, shared types) with XState v5 state machines for robust agent lifecycle management. See experiments/dakka/2026-03-29-v010-monorepo-build.