For three years, almost every industry conversation about AI and software delivery has centered on the exact same half of the problem. We have, collectively, gotten very good at leveraging AI to create software. Nobody hand-crafts all of their code anymore. Most teams now write a specification (Spec), and AI generates the code, writes the tests, and runs those tests against it. While maturity varies across different engineering organizations, virtually everyone is using something—whether it is Claude Code, Cursor, Windsurf, or Devin. StackGen's growing number of enterprise customers such as Nielsen, AutoDesk, Bancolombia have all witnessed this firsthand where those tools quickly became standard across the board for developers. That is the norm now, not the exception.
And yet, looking honestly at the industry, we have been celebrating an incomplete victory.
We have automated the making of software and left the running of it almost entirely alone.
If you have built a software factory - and most enterprises now have one at some level of maturity - then you have a system that produces deployable artifacts faster than your organization can safely deploy, operate, and defend them. The bottleneck did not disappear. It simply moved downstream, shifting from the inner loop to the outer loop.
The outer loop, where software actually runs and delivers business value, is still being managed the way it was a decade ago: by humans, with a stack of disconnected tools, handling problems one ticket at a time.
To understand why this is unsustainable, we have to look at the problem from first principles.
Picture the DevOps infinity loop most of us have drawn on a whiteboard.
The outer loop remains unsolved not because it is inherently harder, but because the industry has attacked it the wrong way. Over the last decade, we optimized this space with DevOps and SRE practices. Today, vendors are trying to make each step in that sequence "agentic" on its own isolated island. Some have genuinely rethought their products around agents; others have bolted a chat box onto a legacy dashboard.
Either way, the result is the same: a collection of very capable, highly siloed agents bound strictly to their core tools.
Every observability vendor now has an agent sitting on its stack. Cloud providers have infrastructure agents. There are excellent, standalone SRE agents doing auto-remediation. These are real companies building genuinely impressive products, and our critique is not of their individual capabilities.
The issue is that every single one of them is a silo. The enterprise that buys three or four of them inherits a job nobody asked for: acting as the integration layer between independent agents that have no awareness of one another, no shared context, and no common memory.
We spent the better part of a decade learning this lesson with traditional tools. A toolchain full of best-of-breed products that don’t talk to each other doesn’t give you the sum of their capabilities; it gives you the sum of their seams.
Now imagine that same problem, except the tools can actively execute changes:
This creates three intelligent systems, each locally correct, collectively producing chaos while a human frantically tries to referee. Enterprise customers do not want to buy isolated intelligence and then supply the integration themselves. They want that intelligence integrated out of the box.
Stripping the problem back to first principles makes the demand simple. The people who run these systems do not want another dashboard, and they certainly do not want a fleet of disjointed agents to babysit.
They want to express an intent and have the machinery deliver the outcome.
The industry already knows how to express intent because we have spent years teaching it to do so:
These are outcomes an engineer can state in plain English. That is the real goal. We should not just be giving SREs smarter tools. The goal must be to let a human declare the operational outcome they want, and let the system take responsibility for continuously achieving it.
Everything between that intent and the final outcome - from triage and correlation to remediation and paperwork - is work organizations can no longer afford to do by hand. The upstream software factory is simply shipping changes faster than any human team can absorb.
Companies like Devin and Factory AI proved that software development deserves an integrated factory system rather than a pile of point tools. The exact same argument applies to operations.
If you have a software factory, you need an operations factory to run what it produces.
This is precisely what we are building at StackGen. To be clear, this is not another point agent; it is a true factory system built on a continuous pipeline:
This shared context changes everything. It is what allows the SRE agent to know, instantly and without manual intervention, exactly which pull request the DevOps agent deployed twenty minutes before a latency alarm went off.
When something breaks, the system does not guess at loose hypotheses. If a code change caused the issue, it opens a pull request against the code; if the cluster was never resized to handle that change, it resizes the cluster instead. The difference between those two root causes is only knowable because the agents share a unified world model.
This world model rests firmly on what we call the Four Bodies of Truth:
When engineering systems become agentic, there is a temptation to make everything probabilistic. We believe that is a potentially catastrophic mistake. Guardrails must remain deterministic.
A policy like "You cannot make an S3 bucket public-facing without proper encryption" is not a suggestion we want an agent free to reason its way around. To solve this, our policy engine compiles rules directly into Rego code. The guardrails hold every single time, regardless of what an AI model thinks.
Inside those strict guardrails, however, the agents can genuinely act. Within bounded blast radiuses, they can:
That boundary is where human judgment is encoded. A simple rollback of a single microservice? The factory handles it automatically. A cluster or storage resize within a modest threshold? Done. Anything with a blast radius above what the line the business draws? The system stops and dials home to a human.
Human-in-the-loop is not a fallback for when the AI fails; it is a designed protocol for novel, First-of-a-Kind (FOAK) exceptions and high-consequence judgment calls. Because it all sits on a shared world model, the factory's capabilities compound with each run, building its own corpus of knowledge to handle recurring incidents faster, more consistently, and more cost-effectively.
The technology industry has begun drawing a line that we believe is exactly right: intelligence should be owned by agents, but judgment and authority must always belong to humans.
Humans own the goals, the risk appetite, the priorities, and the trade-offs. The factory owns everything that can safely be automated. To make this line visible and manageable for organizations, we are introducing two key metrics:
We view these metrics as a natural extension of DORA’s logic, carried past the traditional software development lifecycle and directly into operations. Tying them together is a single north star: Cost per Action. This measures the total cost of operations, including token spend, human time, infrastructure, and the cost of the downtime being avoided. As autonomy goes up and the factory learns, your cost per action should come down while your SLOs hold flat.
We spent a decade convincing enterprises that DevOps and cloud migration were foundational organizational transformations, not simple tooling purchases. The companies that played the long game, that is building capability before scaling spend, were the ones that won.
The AI wave will reward the exact same discipline. Automating the inner loop was the easy, visible half. Running the outer loop with the same rigor, the same shared context, and the same honesty about human judgment is the harder half. It is also the half that decides whether software generated at AI-velocity becomes a business asset or a massive liability.
You have a software factory. The question is no longer whether it is fast enough; it is how effectively you can run everything it ships.
We are officially pulling back the curtain on our Autonomous Operations Factory, entering preview on September 15th. To learn more and request early preview access, visit stackgen.com/factory.