What is a software factory?
The delivery practice · Checked 20 Oct 2026
A software factory is a set of AI agents that moves software work through stations. It transcribes what was asked, drafts the specification, probes the systems a change touches, implements it, and attaches the evidence that it works. Every station leaves a record. A person decides at four gates, and an engineer signs every release.
Our factories always run with the lights on. Agents carry the volume between the gates, and nothing passes a gate without a person.
Chapter 1 · the unit of workEvery task keeps what the business actually said
The unit of work is the task. It opens from what someone actually said, such as a call, a ticket, or a voice note, and it carries that origin word for word. Requirements, decisions, code, and tests stay linked to it from then on.
task: brokers can attach a loss run to a submission origin: call with broker services, 2026-10-07 # kept word for word stage: build plan: plan.md, version 3 # two review rounds touches: [submission service, document store] agents: [planner, builder, verifier] evidence: [unit tests, end-to-end upload test, screenshots] model_calls: through the gateway, zero retention signed_by: the engineer who reviewed the plan
Chapter 2 · stations and gatesAgents move the work between four gates a person holds
- What to make, and why. A person decides before anything is funded.
- How it fits your architecture. A person decides before anything is designed.
- The shape of the code. The types, interfaces, and call paths are agreed before anything is built at scale.
- The release. An engineer reads the change and its evidence, and signs it to ship.
fig 1 · factory-lineEach gate gets an artifact built to be judged in minutes: the request, the plan, the change with its evidence, or the one question that needs a person. Nothing arrives as 2,000 raw lines.
Chapter 3 · the two stages of a taskEvery task is planned in documents before it's built
- The agent proposes a plan. It writes the plan as a document a person can read.
- The engineer reviews it. They iterate until the plan is right, and every round is on the record.
- The agent builds the plan. It implements what was agreed, and nothing else.
- The engineer validates it. They test it functionally and technically, then sign the release.
Routine changes run nearly alone between the two reviews. New kinds of change keep the engineer close at every step.
Chapter 4 · one factory per customerWe tune each factory to a quarter of your real work
We start by sorting a recent quarter of your requests, incidents, changes, and escalations. We define an agent for a kind of work only when it recurs, its output can be checked, and the proof of that check can travel with the change.
| Where you are | The agents a factory usually opens with |
|---|---|
| An insurer with regulated change | One that transcribes intake, and one that assembles compliance evidence for each change |
| A company in the middle of a migration | One that probes the old system's behavior, and one that carries fixes across versions |
| A team on its first custom build | Two agents: one turns requirements into a reviewable specification, and one attaches test evidence to every change |
The stations stay the same in every factory. The agents change, because your week of work is not anyone else's.
Chapter 5 · slices, not layersWe build thin working slices, because late changes cost more
A slice is a thin, working path through the whole system that a business user can try in a browser when the build is days old. We build that way because the price of changing your mind rises at every step.
| Where a wrong decision is found | What it costs to fix |
|---|---|
| In a one-page plan | Minutes of argument |
| In review, under 2,000 lines of finished code | Days of rework |
| In production | An incident |
Chapter 6 · your controlsThe agents can change, and your controls stay
The factory runs in your repositories, your cloud, and your identity. We built its orchestration layer in partnership with Alan AI, and agents get access scoped to one project, never standing access to everything.
fig 2 · factory-controls| Every task records | No agent ever gets |
|---|---|
| Which agent worked it | Standing access to everything |
| Which context, model, and tool it used | A release without an engineer's sign-off |
| What changed | Your prompts, kept for model training |
| Which person approved it | A route to data it isn't allowed to use |
Chapter 7 · where the hours goWe measure how an engineer's week moves toward judgment
Both stages of every task run through one platform, so we can report how each engineer's hours split across planning, implementing, and validating. We use the split to keep the engagement honest, never to watch people.
fig 3 · hours-splitImplementing falls first, as agents take the mechanical share. Validating holds while a person still walks every change, and falls once agents run the end-to-end tests. Planning rises until it's the biggest part of the week.
Questions reviewers ask
Do our engineers have to use your tools?
No. The factory runs inside your repositories, cloud, and identity, and the coding agents can change without changing your controls.
Is our code used to train models?
No. Model calls go through one gateway with zero data retention, and your prompts aren't kept for training.
Who is accountable for what ships?
When we run the factory, a Damco engineer's name is on every release. The strategist who was on the discovery call is still accountable in week 12.
Can we take the factory in-house?
Yes. The handover includes the agents, the project context, and the full record, so your team starts where ours stopped.