We run every software factory with people inside Why each client gets its own factory, and where a person decides

A factory is a set of agents with people at the gates

A software factory is a set of AI agents that moves software work through stations. It transcribes what was asked, drafts the spec, checks the systems the change touches, writes the change, and attaches the evidence that it works. Every station leaves a record.

The unit of work is the task. A task starts from what the business actually said (a call, a ticket, or a voice note) and carries it along word for word. Agents log what they did at every stage, and people decide against that log.

We don't sell the factory as a product. We set it up inside your account, tune it to your systems, and keep running it with you after launch. And we don't run it lights-off.

We've tried letting agents plan, build, review, and merge with nobody judging the work. The agents kept shipping code, and the code kept getting harder to change.

A model can write more code every month. It still can't tell whether a codebase is getting easier or harder to change, and that's the call that decides whether you're building an asset or a liability. So a person still judges every change.

Every client gets its own factory

We can't hand the same factory to two clients. A factory is tuned to one company's work: what lands in a normal week, which systems it hits, what evidence proves a change is safe, and which changes are risky. Almost all the work is in that tuning.

No two clients we've worked with had the same week. For one, it's feature requests against a portal. For another, it's integrations breaking between a policy system and a warehouse, a regulatory change with a filing date, and report requests that each take an analyst a day.

The constraints differ too: data residency, an air-gapped network, or five legal entities answering to three regulators. The stations stay the same, and the agents change.

We start by reading a quarter of your work

We take a recent quarter of your actual work (requests, incidents, changes, and escalations) and sort it. We look at what recurs, what's mechanical once the intent is clear, and what needs judgment.

Then we define agents one kind of work at a time. Each kind has to pass a simple test: the work recurs, its output can be checked, and the evidence of that check can travel with the change.

An insurer's factory might open with agents that transcribe intake and assemble compliance evidence. A company mid-migration gets agents that check how the old system behaves and carry fixes across versions.

A company on its first custom build might start with only two agents. One turns requirements into a spec you can review, and the other attaches test evidence to every change.

A person decides at four gates

Before the volume goes up, the gates go in. There are four things the agents don't get to decide, so a person signs off at each one.

Nothing reaches a gate as a stream of diffs. It arrives as something built to be judged in minutes: the request word for word, the spec, the change with its evidence, and the decision with its reason.

The factory also builds in slices, not layers. 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. Slices matter because a decision gets more expensive the later it's found.

Keeping the lights on means someone still reads the code

A factory left to judge itself gets worse quietly. Each change works, each one makes the next a little harder, and there's no single week where it went wrong. Four habits stop that.

1. A person reads the code. An engineer reads the diff and holds the codebase to its standards, instead of a model grading a model.
2. Planning happens in documents that get argued before anything is built, so review confirms instead of digging.
3. Every change carries its evidence, so the reviewer judges the change instead of rebuilding it in their head.
4. The record stays current: the docs, the decisions, and the transcripts. A factory working from a stale map of your systems does confident work in the wrong place.

We also run the factory itself. We version the agents, retune them as your systems change, check their output against the record, and go through the results on the weekly steering call.

The decision log ties it together. Every ruling a person makes, at a gate, on a call, or in a review, goes in with its date, its author, and its reason. The agents read it before they build, and it answers “why is it like this?” in year three.

People decide, and agents do the repetitive work

People decide what to make and why, and stand behind it with the business. They own the architecture, the decisions that are cheap to change on paper and expensive to change in production. They read the code and sign what ships, and a Damco engineer's name is on every release.

Agents do the repetitive work: retyping what a document already says, scaffolding, integration checks, regression evidence, carrying a fix across four versions, and chasing status the log can answer.

One person can cover four gates across a whole factory because nothing reaches them as 2,000 raw lines. It arrives as what changed, the evidence, and the one question that needs a person's answer.

We're still finding out how far the evidence can go

We don't yet know how much of the review evidence agents can put together on their own. We're testing whether they can assemble enough of it that review gets faster without getting weaker. Until we know, all four gates stay.

Business users get software sooner

We built the factory for two things the CTOs we work with keep asking us for. Business users get software sooner, because the mechanical part of a change stops queueing behind engineering capacity. And engineers stop being spent on volume, so their hours move to the four gates.

It's also our practical answer to the compression problem. The business user's words are captured once and attached to the task, and the agents build from the original. That record goes into production with the change, and the factory reads it again the next time the system needs to change.