# Software factory architecture and pattern, stage by stage > Software factory architecture traced through one bug report, with the pattern and the stages a software factory diagram should show, from intake to feedback. URL: https://factory.com/articles/what-is-a-software-factory-architecture Published: 2026-07-08 Updated: 2026-10-23 A software factory architecture connects intake, context, planning, execution, review, delivery, and observability, so that a report becomes a tested patch, a controlled release, and production feedback. Consider a bug report that an API returns a server error when an optional field is omitted. 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. For the definition of the model itself, and how it differs from Factory the company, see [Inside the software factory](https://factory.com/articles/what-is-a-software-factory). ## 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. A software factory diagram for this example would show intake, context, planning, execution, review, delivery, and observability as separate areas, and it is useful to examine them 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](https://docs.factory.com/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](https://docs.factory.com/software-factory/wiki/overview) 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](https://docs.factory.com/missions/overview) 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](https://docs.factory.com/droid-cli/overview) 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](https://docs.factory.com/software-factory/code-review-ci) 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](https://docs.factory.com/enterprise/llm-safety-and-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](https://docs.factory.com/droid-exec/overview) 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](https://docs.factory.com/enterprise/compliance-audit-and-monitoring) 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. ## Frequently asked questions ### What does a software factory architecture connect? It connects intake, context, planning, execution, review, delivery, and observability so a report such as a bug becomes a tested patch, a controlled release, and production feedback. ### Does local file access mean local inference? No. The Droid CLI works with the repository on the local machine, while custom-model configuration changes the inference path independently of the working copy. ### What is the first useful result for a bug report? A failing test that reproduces the report. If the expected behavior is unclear, the maintainer settles the contract before the agent expands the change. ### Should the release identity match the agent identity? No. The release identity should remain separate from the identity preparing the patch, and the execution environment should not receive production database credentials. ## Further reading - [Inside the software factory, and what it takes to build one](https://factory.com/articles/what-is-a-software-factory) - [Best software factory tools in 2027, compared by workflow](https://factory.com/articles/best-software-factory-platforms-2027) - [How enterprises actually automate software development](https://factory.com/articles/how-enterprises-automate-software-development) - [Factory enterprise overview](https://docs.factory.com/enterprise)