Start with the work you want to repeat
A software factory is a reusable engineering system that produces software and evidence about its behavior. A team configures it around a kind of work: maintaining an application, building a family of tools, implementing a protocol, or producing creative software. The factory has inputs, workers, tools, checks, and a way to deliver an accepted result. Those parts can be simple at first.
The useful first question is concrete. What should happen the next time we need to do this? Perhaps a team repeatedly adds a new data source to a product. Each addition needs an adapter, a schema mapping, fixtures, documentation, and a deployment change. That repetition gives the factory a shape. It also gives you something small enough to build and evaluate before expanding the system.
Design the handoffs
Write down what each stage receives and what it must return. An implementation task might receive a source specification, sample records, and an existing adapter as a reference. Its result might be a patch, new fixtures, and a report from the contract tests. These artifacts let the next stage continue without reconstructing the previous agent's conversation.
A clear handoff also exposes missing decisions. If two workers interpret a field differently, the problem may be an ambiguous contract. If review cannot establish which version was tested, the evidence needs a stronger connection to the artifact. Make those relationships explicit. The factory improves when recurring confusion becomes a better interface or a better check.
Build one complete route
Choose a narrow task and take it all the way through. Give an agent a prepared workspace and a defined tool set. Capture the changes it produces. Run the relevant checks. Review the result and package it through the same route you expect to use again. This first route reveals where the real effort is: setup, missing context, slow validation, unclear decisions, or fragile delivery.
Keep the working parts. A fixture generator, a clean development environment, an API client, or a reliable task brief can save more effort than a complicated scheduler. Reuse should accumulate at the boundaries where you have demonstrated that a component helps. That is how a collection of scripts becomes dependable machinery.
Add concurrency where the structure supports it
Several workers can help when the tasks are independent and the results can be combined predictably. Give each worker clear ownership and an isolated place to work. Record dependencies so downstream tasks start with the right inputs. Decide how abandoned work is recovered and how competing changes reach integration. These are practical coordination questions, even when every worker uses the same model.
Human decisions belong in this design too. Product scope, an important tradeoff, or a release decision may require the person directing the work. Present the relevant artifact, evidence, and alternatives at that point. A good checkpoint makes a decision easier to make and leaves a record the next worker can use.
Improve the production system after each run
Measure where time and attention went. Which checks caught useful defects? Which failures repeated? Which part required someone to explain the same thing again? Feed those observations into the tooling and the process. Over time, the factory should need less repeated explanation while giving you a clearer account of its output.
Rigwright's role is to build the tools for that work: agent runtimes, durable context, workspaces, reusable components, observation, and verification. You assemble them around your requirements. The result is a production system you can understand, change, and use again.