Share This:
A customer needs a service available in a new region by the end of the month. Someone stands up the infrastructure. Someone promotes the change through environments. Someone confirms the signals look right on the other side. When it pages at two in the morning, someone else picks it up.
Four stages, four teams, four toolchains, and a wait measured in days. Most of that time is handoff rather than work, [which slows velocity and reduces productivity]
What is an Autonomous Operations Factory?
The Autonomous Operations Factory is a governed operating model in which specialized agents share operational context, work toward the objectives you set, and coordinate work across build, operate, observe and remediate, at an autonomy level you control, using your existing tools as the system of execution.
Two clauses in that sentence carry the weight. The factory is governed, because autonomy without policy is not a factory. And it works toward the objectives you set.
The second clause is the difference. A copilot takes an instruction and finishes. A factory holds an objective between runs.
A software factory produces code, which is the inner loop. An operations factory runs what that code becomes.
The four key stages in an Autonomous Operations Factory
Work enters at a stage and produces a defined output: a provisioned environment, a verified deployment, a resolved incident. A fifth stage, Learn, belongs to all four. Here is what each stage does, and which agents do it.
In most organizations these four stages are also four reporting lines, four budgets and four tool decisions. That is why shared context has to be established above them. No single stage owner can grant it, and every one of them pays for its absence.
That cost has been measured. Across 225 services in one large cloud estate over twelve months, for more than 52% of outages the service where the problem surfaced was not the service where the root cause sat (Wang et al., ICSE 2021). What that buys is specific. A deployment gates on infrastructure drift because the drift is already there. A root-cause agent names the change that caused the incident rather than the service that failed. An infrastructure plan is checked against what is actually running rather than against the last apply.
How does an Autonomous Operations Factory work?
Below is how an Autonomous Operations Factory runs.
Figure 1. The loop. Intent becomes a specification, the specification runs, and every outcome feeds back. The Aiden World Model is the ground the loop runs on, not a step in it.
Intent is an operational outcome in plain language: move forty services off AWS under the exit mandate; keep this service inside its error budget. It names an outcome, leaves the decomposition open, and can be standing rather than one-off. This is what holds the objective, so nobody restates it at every handoff.
The factory specification turns that intent into a version-controlled document naming which agents to instantiate, their decision boundaries, the context they may read and write, and when they escalate. The team approves it before anything runs, and it is reviewable the way a Terraform plan is. Policy is stated once for the whole factory instead of once per agent, so governance composes rather than multiplies.
Runtime assembles those agents, sequences them on durable workflow execution, takes approvals at each action boundary, and verifies the outcome against what was committed. A long-running job that spans a restart has to resume with its state intact. The alternative fails quietly in the middle and leaves the estate in a condition nobody declared.
Learning closes it. Execute, observe whether the outcome matched the objective, record it with confidence attached, adapt. A novel incident class goes from a full analysis pass, to a pattern matched in seconds, to a prevention rule that stops it firing. Without this step, the work an agent saves is replaced by the work of supervising it.
How is an Autonomous Operations architected?
To achieve this workflow, the Autonomous Operations Factory needs the following five layers of capability. The one at the bottom decides what everything above it may do.
Figure 2. The layers. What the factory is made of, where Figure 1 is how work moves through it. The layer at the bottom decides what every layer above it may do.
The critical role of world models in Autonomous Operations Factories
Every agent in the factory reads the world model before it acts and writes to it after it finishes. Ours is the Aiden World Model: a queryable graph store, not a message bus. No agent queries the graph directly, though: every read goes through one governed service, which is what makes it possible for any agent, whoever wrote it, to inherit the same access rules and the same audit record.
Figure 3. The Aiden World Model. Nine kinds of operational fact, one governed service every agent reads and writes through, and the actions that come out of it.
The model holds two kinds of things, across nine categories of operational facts: What is the observed and attributed state of the estate; What is allowed is the set of approved patterns defining how a compliant system may look. Every decision an agent makes is a comparison between the two.
Drift held as a time series rather than a current-state flag is what makes a pattern visible. And incident causality records what was ruled out, not only the confirmed cause. Today the third engineer on a recurring incident re-eliminates the same two hypotheses the first two already did.
Every fact carries its provenance, a confidence value, the window in which it was true, the party that asserted it, and the schema version behind it. Those last two exist because the hardest governance problem here is drift in the agents, not in the infrastructure.
Holding a graph is not the same as resolving anything. On the OpenRCA benchmark, agents handed the dependency graph, the component hierarchy and the schema still reached a best accuracy of 11.34% on root cause. Dependency structure says what connects to what. It does not say what changed, when, on whose authority, or how confident anyone is.
What stops an agent doing the wrong thing
Agents are human-in-the-loop today. Access to a resource is read-only until you explicitly grant write for it, and remediation arrives as a pull request rather than a silent change unless you have granted otherwise for a specific class of action. Both defaults hold however much autonomy you have granted.
The same rules cover every agent in your estate, not only ours. Policy, identity, cost ceilings and the audit record apply to agents you built and agents you bought elsewhere on the same terms as they apply to ours. A model that governs one vendor's agents is a product, not an operating model.
StackGen's State of Reliability 2026 documented nine cases in the past year of an AI agent taking destructive action against a live production system on its own. Aiden OS is where that is answered: policy evaluated at every action boundary before the action runs, a scoped credential per agent, a cost ceiling per run.
Every decision is written to a signed, append-only record, including what the agent chose not to do and why it stopped. A record saying an agent acted is compliance theater. A record saying which agent, under which policy, against which schema, on evidence valid at that moment, is something an auditor can use.
This is what lets you say yes to agents in production. Not yes in a sandbox, and not yes pending review — yes with the boundary written down, enforced before the action runs, and recorded afterward in a form an auditor accepts.
How autonomy is set
Autonomy is a setting, not a maturity score. It runs on five levels, and you set it per task, per environment and per team rather than once for the estate.
Figure 4. The autonomy ladder. Five levels, and the boundary where coordination stops being human. The levels are vendor-neutral by design.
The line between L3 and L4 is the one that matters, because it is where coordination stops being human. L3 is the natural ceiling for a single-domain tool, which is exactly why adding more agents does not shorten the loop. L4 is the first level at which a learning in one domain reaches another without a person relaying it.
Our implementation of the Autonomous Operations Factory
StackGen's four Aiden products — InfraOps, DevOps, Observability and SRE — are generally available today. The StackGen Autonomous Operations Factory is available in preview from 15 September, by request, for evaluation in non-production environments.
Aiden OS is in production. The Aiden World Model is expanding through the preview period and is deepest where the declared state already exists.
How to start building your Autonomous Operations Factory
Measure where you stand first. The Autonomy Index is the share of operational decisions resolved by agents without human escalation, weighted by risk and complexity. Autonomy Coverage is the share of the four stages running on agent-executed workflows at all. A high Index over low Coverage is a pilot rather than a factory. The first read needs no instrumentation: score a stage from how work moves today, from who decides, who relays and where it waits.
Then expand coverage, one cell at a time. One stage against one tier of services, rather than everywhere at once. Pick services by where work is waiting rather than where the most is at stake — the most business-critical service is usually the most change-controlled, which makes it the slowest place to prove anything. Set agents to recommend and prepare rather than execute, and raise the level as performance earns it.
Build the enablers as you go, not before you begin. One identity for a service across all four stages, policy as code with an append-only record, objectives written as numbers, and declared intended state. Each is worth having whoever you buy from.
The white paper sets out the full sequence, including the measures that only the connection between stages can move.
CTA (primary): Read the white paper — The Autonomous Operations Factory: the operating model that completes the AI software factory →
