An AI software factory has two parts worth separating: the loop where agents do work, and the control plane where a platform team sets the rules that loop runs under. Keeping them apart lets agents move quickly while the limits stay under human control, and within that split a change flows through intake, an isolated build environment, validation, and deployment, with observability feeding back into the next task.

The dev loop and the control plane

The dev loop is where each task is picked up, built, and validated, while the control plane holds configuration, permissions, and deployment policy, managed by the platform team rather than touched per change. Agents read the policy but do not set it, and because it was reviewed once when it was set, individual changes do not each need a platform review, and the boundaries change in one place when the platform team decides to change them. Validated changes can then deploy quickly, since the review that carries weight already happened when the policy was set.

Intake and the agent runtime

A task enters from an issue tracker, a chat message, a pull request comment, or the terminal, carrying enough context for an agent to act on, and it is routed to an agent that runs in an environment of its own, created for the task and discarded after. Isolation at this layer lets many agents run at once without shared state causing collisions, and each environment holds the agent's checkout, the compute it runs on, and the infrastructure its change needs. The choice of coding agent is made here rather than fixed by the platform.

Infrastructure and validation

Resources are declared in the application code through an infrastructure SDK, so the factory reads those declarations and creates the matching database, queues, and buckets inside each environment automatically, and the agent develops against them instead of mocks. The same declarations drive the production deploy, so the environment an agent tests in and what runs in production come from one source. Validation then turns each change into a running environment a person can exercise, backed by the tracing and logging the platform already collects, so a reviewer runs the feature and inspects traces rather than reading the diff to guess whether it works. See how to give agents infrastructure to test against for this layer in detail.

Deploy and observability

On merge, the deploy pipeline analyzes the code, works out the infrastructure the change requires, and generates the cloud configuration for it, so IAM, networking, and resource creation come deterministically from the declarations rather than from the agent, applied to your own cloud account within the boundaries set in the control plane. The running system then emits traces, logs, and metrics, which serve both operations and the next task, since an agent picking up related work has the context of how the system actually behaves. How that deploy stays safe is covered in how to let agents deploy safely to AWS or GCP.

Encore is one system built to this shape, with its open-source SDK as the infrastructure layer, though the architecture holds for any tool that declares infrastructure in code and provisions it deterministically.

For the definition behind this architecture, see what is an AI software factory. To build one, see how to build an AI software factory.