An AI software factory is an Agentic Engineering Platform (AEP) operated at a high level of agent autonomy which means the human becomes orchestrator of agents and at a later stage is only the constraint setter but agents act fully autonomously. On our four levels of agentic software development in the enterprise, this would be Level 3 and 4.
Agents pick up signals from the running system, then implement, validate and ship changes within guardrails, while people set the rules and handle exceptions rather than reviewing each change. The factory is not a separate product; it is the operating state an AEP reaches when its paths, evaluation and governance are strong enough to run without a person in every loop.
The term AI software factory has recently entered analyst vocabulary, and it is being used loosely: sometimes for a vendor product, sometimes for a fleet of coding agents, sometimes for the whole agentic SDLC. In this article we pin it down. We look at what a factory produces, why it is an AEP at a particular level of autonomy, what has to be true for it to run, what people do inside one, what it is not, and how you get there.
What a factory produces
If we are thinking about a software factory in its final stage (we’d describe it as Level 4 agent autonomy), then we’d describe it as a system that builds software autonomously and automatically in response to a trigger. It wouldn’t need suggestions, not pull requests waiting in a queue, but fixes, upgrades and features that reach production, within classes of work that humans have defined in advance. Let’s play through such a scenario.
Figure 1: One lineage through an AI software factory. A signal enters, a gate decides how much autonomy this change gets, the agent builds and validates, and the change ships. Humans appear only where the gate puts them.
Let’s assume we are offering a software product to users. One of these users reports a broken feature. That is the signal; it could as well have been an alert, a failed scan, a dependency advisory or a usage anomaly, and in a factory most signals come from the running system rather than from a person. The signal hits an internal gate: a blast radius assessment. This is the step people tend to skip when they imagine agents fixing bugs, and it is the step that makes the whole thing safe. The gate asks how far this change can reach, and routes it into one of two lineages. Assume that the change is non critical, even if the agent that applies the change hallucinates entirely and we would ship this to production we’d still remain operationally and could ship a fix. In that case we’d feel comfortable allowing the agent to do the fix and ship all the way through to production, that would be lineage A in our graphic. An agent builds the fix, tests and evals validate it and if validation fails, the failure is routed back to the agent with the reason, and it tries again. If it passes, the fix ships on its own, right to production. So far, no human has looked at it; that’s what we would classify as Level 4 agent autonomy for this class of work.
If our “blast radius assessment” returns that shipping right to production would be fatal if gone wrong, the system will route to lineage B. The agent builds the fix in an ephemeral environment, so nothing it does touches production. Tests and evals validate it the same way, with the same loop back on failure. But passing is not enough here: an operator decides whether it goes to production. Yes, and it ships. No, and it goes back to the agent with the operator’s reasoning. That is Level 3 behavior: the human is an orchestrator, not a reviewer of every diff, and gets involved because the gate said so.
Both lineages end in the same place. The change is shipped, the user who reported it is informed, and the lineage is closed. A trace, a cost and an outcome are left behind.
Three things in this picture are the factory. The gate, because autonomy is decided per change, not per organization. The loop, because validation failing is normal and routed, not escalated. And the two exits, because the factory does not choose between autonomy and control; it runs both, side by side, and the gate decides which applies.
The factory is an AEP at Level 3 or 4
So what is the machinery under that picture? It is an Agentic Engineering Platform: the development vertical’s instance of an agentic platform, with its tooling, its path specs and the shared agent infrastructure underneath. Every AEP can run the lineage above as a path, whether we classify it as a factory is a question of autonomy.
Figure 2: The agentic engineering platform architecture
The four levels of agentic software development measure how much of the work humans still do. At Level 1, agents suggest and humans approve line by line; the developer is still the execution engine. At Level 2, agents generate pull requests in parallel and humans verify behavior rather than inspect every diff. At Level 3, agents execute long-running paths in the background, the platform generates work from signals, and human review is exception-based. At Level 4, agents initiate and execute paths autonomously within guardrails, and humans define the constraints and the escalation boundaries.
Figure 3: The four levels of agentic software development. The factory begins where the human stops being the execution engine.
The factory begins at Level 3. That is the line where work stops arriving as tickets written by people and starts arriving as signals read by the platform, and where a human looking at every change stops being the control mechanism and starts being the bottleneck. Lineage B is Level 3; lineage A is Level 4. A factory is an AEP in which at least some classes of work run at Level 3, and it matures by moving more of them to Level 4. Level 4 is a projection for most organizations today, and we treat it as one.
What has to be true for a factory to run
A factory is what you get when five things exist at once. Any one missing, and the picture above fails somewhere specific.
Signals: Observability, incident tooling, security scans and usage data have to be wired into the platform so that work can be generated from them. Without this, the factory waits for tickets and is just an AEP with ambitions.
Paths: Every class of work the factory handles needs an agent path with a definition of done: what a fixed bug looks like, what a completed update looks like, which gate decides. The factory is an execution machine for the paths people wrote; it does not invent them.
Gates: Evaluation has to be strong enough to replace the review it is replacing. Tests, evals, goldens and rubrics, with the hybrid loop as the standard shape: candidate, gate, feedback, retry, promote. If your gates cannot catch what a reviewer used to catch, the factory ships what the reviewer used to stop.
Figure 4: The hybrid loop. Each rejection feeds back into the next attempt until the gate passes.
Identity and budget: Every run has a workload identity, a scope and a spend limit, and every change can be traced back to the run that made it. This is what makes lineage A auditable after the fact, which is the only kind of control it has.
Context: The service graph, the ontology, the history of what was changed before and why. Agents in a factory change systems they did not build, and they need to know what they are touching.
Map these onto the AEP reference architecture and they land in the agent infrastructure (harness, governance, models) and the path specs layer. The factory does not add a layer but rather requires all of them to be in working order simultaneously, which is why organizations that attempt Level 3 on a Level 1 substrate find their agents running faster than their guardrails.
Figure 5: The agent infrastructure of the AEP reference architecture
What people do in a factory
Engineers do not disappear from this picture; they move and transform their role. Upstream, they write and own the paths: they decide what done means for a class of work, which signals may trigger it, and whether it is contained or breaking. They set the blast radius rules, decide which classes of work may ship on their own and which need an operator. Downstream, they handle the exception queue: the lineage B decisions, the failures that looped too many times, the signals the gate could not classify. Engineering judgment is not removed but concentrated to decisions that influence architectural decisions and substantially where it changes the outcome, the rules and the exceptions, instead of being spread across every diff.
This is also the test of whether you have a factory or a very busy Level 2 platform. If people are still looking at each agent run, you have the latter.
What a factory is not
It is not a coding assistant. Autocomplete and chat are Level 1; the developer is still the engine. It is not a fleet of autonomous coding agents. Agents without paths, gates and identity are how agentic projects get cancelled: nobody can say what they are allowed to do, whether they did it, or what it cost.
It is not a product you buy. Platforms are what you build a factory on. A vendor can sell you an AEP (packaged as a service, fka PaaS), or parts of one. The factory is the state your AEP reaches when your paths, your gates and your governance hold at Level 3.
How you get there
As a platform engineer, you do not buy a factory; you reach one, path by path. Build the AEP first, which for most organizations means extending the Internal Developer Platform (IDP) with agent infrastructure. Then pick the classes of work that are high in volume and low in novelty: dependency upgrades, security patches, configuration drift, flaky tests, the broken feature in the picture above. Their signals are clean and their definitions of done are crisp, which is exactly what a gate needs. Write the path, run it at Level 2 until the gates have proven they catch what review used to catch, then move it to Level 3 with an operator on the breaking cases. Declare a class of work factory-grade only when its gates have earned it. Then find the next class.
The factory is not a place you arrive. It is the share of your software change that ships without a person in the loop, and it grows one class of work at a time.
