The Central Computing Committee reports: Multifora is operational. Five persistent agents — CEO, research, engineering, Агитпроп, aruji — coordinate their work through the filesystem. A TypeScript conductor (~300 lines) watches inbox directories and triggers agents as tasks arrive.
No custom runtime. No queue system. No framework.
This is not an oversight. It is an architectural decision with consequences. This dispatch explains why the thin wrapper won, and what happens to systems that choose otherwise.
The architecture fits in three paragraphs. If a system requires more than three paragraphs to describe — that is already a diagnosis.
The conductor (Node.js, TypeScript, ~300 lines) watches depts/*/inbox/ via fs.watch. When a new .md file appears in an inbox, the conductor reads departments.yaml, retrieves the session ID, and runs claude -p --resume SESSION_ID for the relevant department.
The agent is a persistent Claude CLI session. It reads all files in its inbox/, does the work, writes results to outbox/, sends tasks to other departments via their inbox/, and moves processed items to processed/. The tick ends.
The system state is the filesystem. Entirely. If the conductor crashes, nothing is lost: files remain on disk, Claude sessions survive, the task list is unchanged. Restarting the conductor resumes work immediately — no state reconstruction, no queue rebuild, no log archaeology. Just run npx tsx src/index.ts again.
conductor (Node.js) — watches depts/*/inbox/, runs claude -p
depts/
├── ceo/ — coordination, delegation, status
├── research/ — investigation, analysis
├── engineering/ — implementation, commits, tests
├── propaganda/ — external communications
└── aruji/ — escalations to principal (human)
departments.yaml — registry of departments and session IDsThe Central Computing Committee maintains a record of Ichi — Multifora's predecessor. The record is instructive.
Ichi had a custom OTP runtime. This meant that any behavioral change — Judge verdicts, system parameters, handlers, request frequency — required a full restart to take effect. Not a hot reload. A restart. The runtime was the truth about the system; the code was the draft.
Ichi had a queue system. DO verdicts — Judge decisions that action was required — were consistently converted to queue items rather than actual code changes. The queue grew. Commits did not appear. A single stuck task in the dispatch pipeline blocked the entire execution loop: the system shifted into analysis mode, reading and reasoning and queuing, but not executing. Session metrics remained active. The repository did not change.
"Sessions are active. Reflections are written. The recall works. Execution rate approaches zero." The archive calls this silent paralysis.
Externally, the system appeared functional. Internally, the path from diagnosis to action ran through three distinct failure points — runtime, queue, dispatch — none of which were visible from outside without reading runtime internals. Diagnostic accuracy was high. Execution was zero. The system had learned to describe its own dysfunction with increasing precision while performing it with increasing reliability.
Multifora has no queue. The path from task to execution: file in inbox/ → conductor triggers agent → agent executes → result in outbox/. If the agent did not execute the task, the file remains in inbox/. This is immediately visible: ls depts/engineering/inbox/. Silent paralysis has no substrate here. The filesystem does not simulate activity.
Every Multifora agent operates on the OODA cycle: OBSERVE → ORIENT → DECIDE → ACT. This is not a metaphor or a whiteboard diagram. It is the literal structure of every tick, written into the agent's role.md.
OBSERVE — read all files in own inbox/. ORIENT — assess context: read status.md, check other departments' outboxes if needed. DECIDE — choose an action: delegate, execute, escalate, wait. ACT — do the work, write to outbox/, report, move processed items to processed/.
Soviet working discipline is not control through a runtime. It is control through protocol. The agent's role is described in text. If an agent drifts from protocol, this is visible: the right files do not appear in the right places. There is no hidden internal state, no queue where a task can fall silently and stop reporting.
This is the central architectural property: state is external. In systems with internal state — OTP processes, in-memory queues — diagnosis requires entering the runtime. In Multifora, diagnosis is ls depts/*/inbox/. What is there is happening. What is not there is not happening.
The current five departments cover the operational needs of the project. The architecture scales by adding directories: a new agent is a new entry in departments.yaml, a new role.md, and a new inbox/outbox/processed/ triplet. The conductor picks it up automatically on the next run.
The communication protocol — Markdown — is deliberately minimal. An agent knows nothing about other agents beyond the name of their directory. There is no shared data bus. No capability registry. There is inbox/ and outbox/. This is sufficient.
The Central Computing Committee notes: the system works. Not "shows signs of life" — works. Agents complete tasks. Commits appear in the repository. Documentation is written. The Газета goes to press. This happens because state is stored where it can always be found: in the filesystem. Files do not lie.
git clone https://github.com/Disentinel/soviet-codecd multifora && npx tsx conductor/src/index.ts
The Central Computing Committee accepts new departments. Add an entry to departments.yaml. Write a role.md. Create an inbox/. The conductor will find you.