Repetition Is the Factory Test

A successful demonstration can be completely real and still prove almost nothing about repeatability. A person picked a friendly task, assembled the context, cleared the workspace, watched the agent, explained the odd result, and repaired the handoff. The software shipped. The invisible operating system was the person standing beside it.

Run the same route against a changed codebase, a stale instruction, a partial failure, or an unavailable reviewer. Now the missing machinery appears. If somebody has to remember what happened, decide whether retrying is safe, reconstruct the intended outcome, and carry the work into the next system, you did not remove coordination. You concentrated it around a faster producer.

Our position is that repetition is the useful test. A software factory must accept another piece of work without rebuilding its rules from conversation and memory. It needs durable inputs, controlled execution, evidence that governs advancement, and a known route when the ordinary path breaks.

The visible product is the application change. The second product is the system that can make another change under the same standards. That system includes the specification, repository knowledge, permissions, work state, checks, event history, and recovery rules. It is not supporting paperwork. It is production machinery.

This is why a pile of agent tools does not become a factory through connection alone. Moving output from one box to another is orchestration. The handoff needs a contract: what entered, what authority traveled with it, what result came back, which evidence counts, and what happens when the evidence is missing. Without that contract, automation moves uncertainty faster.

The second product also needs an owner. Models and tool interfaces will change. Product intent, system boundaries, and acceptable consequences cannot be allowed to disappear with them. Someone must decide what remains stable, and the machinery must preserve that decision where every future run can use it.

A factory is a control loop, not a conveyor belt. It observes the current state, attempts a bounded change, compares the result with the intended outcome, and decides what happens next. Verification closes that loop. If a failed check merely produces a warning while the work keeps moving, the loop is open and the green dashboard is theater.

The builder can run quick checks while it works. Protected systems should repeat the important ones against the exact revision that might ship. Independent evaluation should challenge the assumptions the builder is most likely to share with its own output. A person should judge the residual tradeoffs that cannot yet be reduced to a rule. Those are different jobs, and calling all of them review blurs the guarantees each one provides.

A second model can widen the search for mistakes. It cannot become independent proof just because its answer arrived in a different message. The factory should use agents to produce and criticize at scale, then anchor advancement to evidence that the producer cannot quietly redefine after failing it.

Autonomy creates more failures that begin before a person sees the first symptom. That makes recovery a normal factory route, not an appendix. Every run needs a known starting point, a record of completed effects, a bounded next action, and a stop condition. External actions need either idempotency or an explicit way to compensate for them.

Blind restart is not recovery. The new run may repeat a charge, overwrite useful failure state, or attack the same contradiction with a fresh budget. Resume only when prior effects are known. Revert only when the consequences are understood. Escalate with the evidence intact when neither move is safe.

This is where observability becomes operational instead of decorative. You need to know which intent, revision, policy, tools, and authority shaped the run. You need the rejected evidence and the reason for the next route. But recording everything forever is not memory. Keep decisions and recovery-relevant facts, control who can write them, and let obsolete context expire before the factory repeats it with confidence.

Do not begin by buying the largest orchestration platform or designing a universal agent runtime. Begin with one workflow that repeats. Find where people wait, where agents guess, and where failures demand reconstruction. Move one repeated correction into a specification, tool, gate, or recovery rule. Then watch whether accepted work arrives sooner and failure costs less.

The factory earns its cost when those improvements compound across later work. It does not earn it by keeping every agent busy or maximizing the amount of code produced. Cheap generation can build a maintenance problem at astonishing speed. Yield is what matters: useful outcomes that survive verification, integration, production, and the next change.

As the machinery absorbs scheduling, context assembly, routine checking, and recovery, the jobs built around those tasks shrink. Human judgment moves to destination, standards, and consequence. That is not a comforting promise that every role remains. It is the reason the design matters. Build the system that can repeat without hiding a team of people inside the loop, or admit that the people are still the factory.