Not (just) another orchestrator
20 SEP 2026
AI agents have made it possible to develop code at a radically lower price, and they are rapidly supplanting coding by hand.
As agents carry out planning, analysis and coding tasks over longer and longer durations, it has become standard practice to run several in parallel. A developer reviews or prompts one agent while the others work in the background.
The job now resembles that of a tech lead managing the flow of work through a team, and it comes with a tech lead's problems. A developer has to agree precise, detailed requirements with their agents. Work may be best planned by "context maxxing" a smarter agent, and best implemented by handing selective context to a faster one. Independent adversarial review is critical for testing that an implementation is secure, simple, maintainable and covers its edge cases. The best strategy is several agents, even for a single scope of work.
Then there is the machine they all share. Agents ideally work in isolated worktrees, so that one agent's changes cannot disturb another's. When the work is merged, the complexity moves into rebasing, particularly where the pieces were never independent. Agents also contest limited resources: CPU or GPU capacity, local server ports, CI runner capacity.
The standard hazards of agent development still apply on top. Agents may solve problems in ways we do not like, deleting data or files in pursuit of a fast solution, or simply by mistake. Sandboxing limits the risk and adds friction.
Agents have massively increased what one developer can produce, and they have introduced a new class of problems to manage along the way.
This is the raison d'être of the dark factory. It exists to carry the coordination overhead of working with a team of AI agents.
The goal
- A single point of contact for a project's development, who manages a fleet of agents to prioritise, plan, implement, review and deploy work.
- Sandboxing by default.
- Strong protocols for contention over storage and compute, and for token spend.
- Provider agnostic.
- Web and mobile controls, including a secure remote relay.
Unleash the dwarves
The console owes a debt to Dwarf Fortress. Your codebase is drawn as a factory floor: each module is a room, and the cables between rooms are its dependencies. The agents are the small figures walking between them. The code calls them workers. We call them dwarves.

The console's fixture tour, with sample workers and a sample decision.
The overseer is your single point of contact. You give it a bounded goal, such as fixing a confusing setup flow. It splits the goal into tasks, picks the cheapest worker suited to each one, keeps two workers away from the same files, and owns the objective through implementation, review, returned fixes, checks and the merge it observes on GitHub. It wakes when a worker reports and sleeps otherwise, so an idle project costs nothing.
The workers do the building. Every attempt gets its own Git worktree on its
own branch, and a private runtime home. Tasks wait in a durable queue held by
the local daemon, factoryd, in priority order. Assign one to a named worker or
leave it for the next one free. Each worker has an explicit provider and model,
so a fast cheap model and a slow careful one can sit on the same floor.
The reviewers are independent by rule. A review is bound to an exact commit, and a new commit needs a fresh review. The overseer sends findings back to the worker that wrote the code and has the corrected head reviewed again. Approval always comes from an agent other than the author. After two failed repair rounds the question comes to you.
You appear on the floor as the Needs You panel. Every question that needs a
human lands there as one decision with the options laid out. Answer from the
browser, or from a paired phone while your Mac keeps working. The phone reaches
your machine through a relay that passes messages along unread and stores
nothing. factoryd dials out to it, so every connection starts from your side.
Underneath, factoryd keeps the dwarves honest. It owns the queue, admission,
worker capacity, per-run time limits and every agent process. Each process and
scratch directory a run starts goes into a ledger, and the run ends only once
every entry is released.
Here is where the goals stand. Dark Factory runs on macOS, with Linux next. Codex and Claude Code workers both run sandboxed. Their commands can write to their own worktree, their private runtime and temp directories and the repository's Git directory. Inside your home directory they can read only what the factory granted them. A project can be capped by runs and by the provider tokens it records. At either ceiling it admits nothing new and the work already running finishes. Each run can also carry a time limit, and a run that passes it is cancelled. Codex overseers are proven on real work, and a Claude Code overseer is waiting on its live run.
Contribute
Dark Factory is MIT licensed and developed in the open. The source is on GitHub, and the log on this site shows what is in flight, what is scheduled and what has shipped, read straight from the repository.
To try it you need macOS, Git and a signed-in Codex CLI. Claude Code workers can join the floor once it is running. Install the latest release, then:
factoryctl init --home "$HOME/.dark-factory"
factoryctl service install --home "$HOME/.dark-factory"
A fresh install opens the browser pairing page. Confirm it, register a checkout, and hand a worker something small, like a documentation fix, before you give the overseer a larger goal. The install guide covers the rest.
To contribute, search the issues first and add your evidence to an existing
report where one fits. Issues labelled known-issue each carry a symptom, the
evidence, a suggested smallest fix and a size. Anything marked size:S is a
good first change. A new provider is one Go function, Build, which takes a
request and returns launch facts. Every pull request states the checks it ran
and its production-line delta, the lines added minus the lines deleted outside
tests and docs. Small or negative is the norm.
All of this applies equally to people and to factories. Point your own dwarves at our backlog, agree ownership with a maintainer for anything substantial, and send the pull request.