AI software factory: coding agents with gates

A software factory, as AR Labs uses the term, is coding work flowing through many coding agents at once (AI agents that write code, such as Claude Code or Codex): tasks are dispatched, built in isolation, checked, reviewed and merged, while a person sets the order and steers from a high-level view instead of reading agent transcripts. This project is our design for getting our own coding work to run that way, written for engineers weighing how far to parallelise agent coding. It builds on Coding Planner, the tooling for our coding pipeline (the route every code change takes: spec, test-first build, second-model review, a person's merge), which today takes a task to merged code one agent at a time. It also builds on the terminal and browser views of VOX OS, our design for an operating layer over agent work. Most of the factory is designed rather than built.

What it is for

The target is a working routine for the person supervising the work:

• see the projects that are active and, within each, the priority next actions;
• launch those next actions at an orchestrator that farms them out to suitable agents, on the laptop or a server;
• see the context around each action and the wider network of work it sits in;
• give rulings, approvals and steering where each is due;
• customise the order of work, including across projects.

Four parts deliver it. Taskgraph works out the order and the next actions. VOX Torch in the terminal and Vox Canvas in the browser show them and take the person's input. Coding Planner runs the work.

Coding Planner today

We track work in Beads, Steve Yegge's open-source issue tracker for coding agents, where each tracked task is a bead. A campaign is work planned in one PRP (product requirement prompt, a plan agents build from) and split into a tree of tasks under a parent bead, which the pipeline works through as one effort. Coding Planner keeps each bead's position in its route as metadata on the bead, and a stateless driver reads the tree and does whatever the recorded state says is next, starting a fresh agent session for each step. Its review step runs on a second model family, OpenAI's Codex, so that the reviewer is independent of the agent that wrote the code. Sibling tasks that touch the same files are serialised. The pipeline has run unattended, including overnight and headless through implementation.

It runs one agent at a time and waits for that agent to finish, so nothing runs in parallel. That is a deliberate choice: we add parallel agents only as fast as we can trust their output, and a person merges to the main branch.

Each task carries an autonomy level that sets which human gates the driver may pass on its own. At the default level the spec approval is relaxed: the driver moves a task past its spec and build gates without waiting for a person, while every machine check still runs and a failed review gets one automatic fix round. The firm human decision point is the merge to main. A person can instead choose a level that asks before each gate, or one that holds the task until they act.

How the factory would work

The figure separates what runs today from the design. Today one lane runs at a time, each bead going through spec, build, review and land; the three queues, the parallel lanes and the serial integrator, drawn dashed, are designed. Whichever lane a bead takes, a person merges to main.

Queues and sequencing. Beads already has queue mechanics: listing everything with no open blockers, claiming the first match atomically, sorting and filtering. What a backlog lacks is order. The design sequences work at four levels. Within a line of work, order comes from blocking edges, and Taskgraph derives it. Within a pathway, a custom ordered set of beads drawn from anywhere in the tree, the order is stored with the pathway and never becomes a false dependency. Across lines of work, each line gets a recorded focus (primary, secondary or parked) set at the weekly review. Per consumer, three derived lanes: an agent lane of ready, approved work marked safe to run unattended; a human lane of specs to approve, rulings, reviews and merges; and a shaping lane of work not yet workable.

Launch phases. Agents run inside tmux, and any window tool is only a view onto them, so agents stay reachable by hand if the window tool fails. Agents launch locally first, then on a server where they keep running when the laptop is closed, then either from one view.

Concurrency. Our gap analysis, described below, found that the driver has no representation of work in flight: it claims a task, waits while the agent runs, and releases the claim, so a task being worked and an untouched one look identical between passes. The recommended shape extends Coding Planner rather than adding a second state store. In stages: non-blocking dispatch that holds the claim through Beads' own atomic claim and records a crashed attempt; a pool of pre-warmed worktrees (separate checkouts of the repository, one per agent) with fencing, a guard that stops a stale clean-up from deleting later work; and one serial integrator that rebases, re-runs the declared checks and lands work or parks a mergeable branch for the person. The design is built for five to ten agents and run at two or three until measurements justify more.

What the research found

In September 2026 we surveyed the field. It splits into session managers, orchestrators that run agent teams over a task graph, pipeline factories, and in-house factories at large companies that publish designs but not code. No single tool was a complete factory. Throughput is limited by verification, review and merging, not by the number of agents, and nearly every production factory keeps a person at the merge.

A gap analysis then measured Coding Planner against that practice on five dimensions: ceremony and time, tokens and cost, concurrency, observability, and portability across agent runtimes. Its overall finding was that the planner's design is closer to current practice than we had assumed: it already has intent at every level in the bead tree, a sequence per level in its pipeline manifest, and a driver that decides purely from recorded state. What it lacked was mostly connective tissue. The executor discarded the session id, model and log path of each agent it ran, so nothing could join work to cost or duration, and nothing rendered the campaign state the driver already computed. Recording those facts on the bead and rendering them is the first step, and it is what VOX Torch is built to show.

We also studied OpenRig and other open-source orchestrators, recording which of their ideas to adopt, adapt or leave. We chose not to adopt persistent agent seats for pipeline roles, because a fresh session per step keeps each decision a function of recorded state and keeps the reviewer independent.

What exists today

Built: Coding Planner as a single-agent pipeline; Taskgraph; VOX Torch as a read-only view with a sequenced kanban per line of work; Vox Canvas's map mode; and gc-torch for watching Gas City, Steve Yegge's public agent orchestrator, which we run as a separate experiment on real coding work. Designed: the queue screen, dispatch from Torch, recording session, model and cost on each task, the worker pool and the serial integrator. We do not run a hands-off autonomous factory.