What is a software factory? And how to build one with coding agents

A software factory is a repeatable pipeline that turns intent into shipped software through fixed stations (plan, design, build, verify, review), a shared queue of work, and quality checks with evidence, so the output does not depend on who, or what, did the work that day. An agentic software factory is the same pipeline with coding agents such as Claude Code and Codex working the stations and people owning the approvals. To build one you need five things: a work queue agents can read and write, units of work sized for one agent, an isolated checkout per agent, stations written down as skills, and a record of every run that shows what was checked and how. The rest of this post takes those in order.

#Where the term comes from

"Software factory" is an old idea with a new engine. Japanese companies used the name in the 1970s and 80s for organized, repeatable software production. Microsoft revived it in the mid-2000s for model-driven development with reusable templates. The US Department of Defense uses it for in-house DevSecOps teams such as the Air Force's Kessel Run. The constant across all three is the same: make building software a process you can repeat and inspect, not a craft that lives in one person's head.

What changed is who works the stations. A team with three engineers and ten agent sessions a day has more labor than review capacity. The factory is how you keep that labor pointed at the right work and keep its output trustworthy.

#The five parts of an agentic software factory

#1. A work queue agents can read and write

The queue is the factory floor. Agents pull from it, update it, and close work in it; people triage it and read the results. It has to be shared and live, because the agent on your laptop, the agent in CI, and the teammate reviewing in a browser all need the same state at the same moment. A markdown file in the repo is per-branch and per-checkout, so two agents in two worktrees see two different backlogs.

That is the job of an issue tracker in the cloud with an interface agents can drive. In Radial the agent uses the native CLI or the MCP server, people use the web app, and both see one backlog:

radial list --status todo --json      # what is ready
radial update RAD-383 -s "In Progress"
radial comment RAD-383 --stdin < notes.md

#2. Units of work sized for one agent

An agent does well with a change it can hold in one context: one parent goal, split into two to four children, each with acceptance criteria and explicit blocked-by edges. Too big and it loses the thread; too small and you spend your review time on overhead. Writing the plan to a file before filing it lets you argue with the breakdown while it is still cheap to change.

#3. An isolated checkout per agent

Two agents in one working tree overwrite each other. Give each its own git worktree and branch, and let the queue, not the filesystem, be the place they coordinate: who has which issue, what is blocked, what is done. More on that in running parallel agents.

#4. Stations written down as skills

A station is a step with a contract: what it reads, what it writes, and when it is done. Write each one down as an agent skill so every session runs it the same way. Radial ships a pack of open-source rd-* skills for Claude Code and Codex that cover the line:

Install them with radial skills install. The workflow walkthrough runs all of them on one real feature.

#5. A record of every run

A factory without records is a rumor. For every piece of work you want to see which stations ran, how long each took, which checks passed, and on what evidence. "The agent said the tests pass" is not evidence. "The CLI ran pnpm test and read the exit code and the summary line" is:

radial build gate --gate unit --exec -- pnpm test

In Radial each issue keeps a build record: the stages with every attempt, the gates with their provenance (run by the CLI, imported from a file, or reported by the agent), and the agent's redacted session. That is also how you keep the logs: see how to save Claude Code and Codex session logs.

#Where the people go

People do not leave the factory. They move to the gates where judgment matters:

• Approving the plan before it becomes issues.
• Reacting to the prototype before the real component is written. Clicking a Preview and saying "no" costs five minutes; saying it after the build costs a day. See sharing agent HTML prototypes.
• Reviewing and merging the pull request, with the build record open next to the diff.

The factory's job is to make those three decisions fast and well informed, not to remove them.

#How to start this week

1. Put the backlog in a shared tracker your agents can drive. npm i -g radial.build && radial auth, or add https://mcp.radial.build as a remote MCP server.
2. Install the stations: radial skills install, then run /rd-setup in the repo.
3. Run one feature through the line: /rd-plan, /rd-prototype, /rd-issues, /rd-build, /rd-pr.
4. Install the session hook (radial build hook install --client claude or --client codex) so every run leaves a record.
5. After a few runs, read the records with /rd-retro and change the station that keeps failing.

Agents are not billed in Radial, so adding a second or tenth agent session to the line costs nothing on the tracker side: $50 per user per year for the people, flat. See pricing.

#FAQ

#What is a software factory in software engineering today?

A repeatable pipeline that takes work from intent to shipped code through defined stations, a shared work queue and quality checks with evidence. Today the term usually means a pipeline where coding agents do much of the implementation and people approve plans, designs and merges.

#What is an AI software factory?

The same pipeline with AI coding agents working the stations: planning, prototyping, building and verifying. The factory part is the structure around them (queue, work units, isolation, written stations, records), which is what makes agent output repeatable and reviewable.

#What is an agentic software factory?

A software factory where autonomous coding agents such as Claude Code or Codex pull work from a queue, run each station, record their checks, and hand finished work to people at defined approval gates.

#How do I build a software factory with Claude Code and Codex?

Give the agents a shared, cloud work queue they can drive through a CLI or MCP, size work as a parent with a few children, give each agent its own worktree, write each station down as a skill, and record every run with evidence. Radial provides the queue, the rd-* skills and the build records; your repo provides the tests and the gate.

#Do I need an issue tracker for a software factory?

You need a shared, live queue with state that every agent and every person sees at once, plus a place for each run's record. An issue tracker in the cloud is that queue. A markdown file in the repo is not shared across worktrees, and a chat thread is not a queue.