The architecture of a software factory

Consider a bug report that an API returns a server error when an optional field is omitted. Turning that report into a tested patch requires more than code generation. The system must find the relevant contract, reproduce the failure, constrain the change, and carry the result through review and release. Production monitoring then checks whether the original problem has stopped.

A software factory architecture connects those activities. A software factory is the delivery model, while Factory is a product that implements an agent-native version. Factory's published continuous feedback loop follows signals through planning, building, testing, review, security, shipping, and monitoring.

Establish the boundaries before choosing tools

An editor, a coding agent, and a CI runner can all participate in the same change. Their connection determines which repository revision is tested, what credentials the agent receives, and who can authorize release. Listing the products alone leaves those decisions unanswered.

It is useful to examine intake, context, planning, execution, review, delivery, and observability separately. These seven areas are an explanatory breakdown of responsibilities. A team may combine several in one service or distribute one across multiple systems. They are not a universal definition or a requirement to buy seven products.

For the API bug, the execution environment needs the repository and an isolated test service. It does not need a production database credential. The model endpoint must be approved for any code context it receives, and the release identity should remain separate from the identity preparing the patch.

Turn the report into a reproducible task

Intake preserves the reported failure and the requested outcome. In this example, the task should include a synthetic request with the field omitted, the expected response, and the affected API version. Factory's remote delegations let a team start work from tools such as Slack or Linear, but the request still needs enough detail to investigate safely.

Context resolution connects that request to the route handler, schema, generated client, and existing tests. Factory's AutoWiki provides repository documentation that can help locate the relevant design. Droid still needs to inspect the current files and applicable project instructions before treating that documentation as the current contract.

The first useful result is a failing test that reproduces the report. If the schema says the field is optional but the handler dereferences it unconditionally, the mismatch is specific enough to plan a patch. If the expected behavior is unclear, the maintainer must settle the contract before the agent expands the change.

Plan, implement, and test the patch

Planning identifies the smallest change that restores the contract. The API example may need only a handler fix and regression test. If the investigation uncovers dependent client changes, the plan also needs a safe compatibility order. Factory's Missions make planning and milestone validation explicit for larger, multi-feature work. A small bug fix can stay in a normal session.

Execution applies the patch and runs the required commands. The Droid CLI works with the repository and its toolchain. Factory's custom-model configuration changes the inference path independently of the working copy, so local file access should never be taken as proof of local inference.

For the omitted-field bug, test the absent field, a valid supplied value, and any invalid value the API promises to reject. Preserve the response shape expected by existing callers. A passing handler test should be followed by the integration check that exercises routing and serialization, because either can change the response the client receives.

Keep review and release independently controlled

Review inspects the contract, patch, and test result together. Factory's Automated Code Review can apply repository-specific review guidance. Deterministic tests, security checks, and branch protections remain separate controls. An AI review finding can help a maintainer investigate, but its absence cannot prove that every policy or failure path was checked.

Permission boundaries also apply before review. Factory's agent controls describe command restrictions, sandboxing, and secret-detection mechanisms. Configure them alongside repository and infrastructure permissions. A prompt requesting a harmless patch does not remove the consequences of an overprivileged execution identity.

Delivery takes the reviewed revision through the existing build and deployment process. Droid Exec can participate in CI, with mutations opt-in, without granting the job authority to ship production changes. The release record should identify the artifact actually deployed and the checks performed after deployment.

Use production feedback to improve the next change

Observability closes the example by checking the affected API behavior after release. Monitor the relevant error signal and exercise a synthetic request with the optional field omitted. A reduced aggregate error count alone could hide a remaining failure on one route or client version.

Retain the report, starting revision, patch, environment definition, test output, review decision, and release artifact. Factory's compliance and audit documentation separates administrative audit events from operational telemetry. Customer OpenTelemetry metrics do not automatically contain a complete transcript or enough information to replay every action. Content export has separate privacy and retention decisions.

If production reveals a missing case, connect it to a new regression test and update the relevant instructions. That is the feedback that changes future work, rather than merely accumulating more logs.

CI/CD and monitoring already automated parts of delivery before coding agents. Droids add investigation and implementation capabilities within those systems. People still decide the required behavior, permissible access, and release conditions. Ownership depends on the actual workflow, not a universal shift of every stage to an agent.

When selecting tools, follow one representative task across these boundaries. Check whether the same revision, compatibility decision, and validation result survive each handoff. The architecture works when the next person can explain what changed, why it was released, and what production taught the team.

Further reading

• Inside the software factory, and what it takes to build one
• The software factory platforms worth comparing
• How enterprises actually automate software development
• Factory enterprise overview