This is part 4 of 5 in a series adapted from our white paper, The Autonomous Operations Factory: the operating model that completes the AI software factory. Download the full white paper for the complete argument, figures and sources.
An operations factory only shortens the loop if its agents coordinate across stages without a person relaying context between them. This post covers how that works, first as a workflow and then as an architecture.
The workflow is a loop: intent becomes a specification, the specification runs, and every outcome feeds back to drive learning. The architecture is the set of layers underneath it. Each step of the loop answers one of the five point-agent failures from Part 2.
The model starts with an operational outcome in plain language: move forty services off AWS under the exit mandate, or keep this service inside its error budget. Intent names an outcome and leaves the decomposition open, and it can be standing rather than one-off. A copilot takes an instruction and finishes. A factory holds an objective.
Intent becomes a factory specification: a version-controlled document naming which agents to instantiate, their decision boundaries, the context they may read and write, the objectives the factory commits to, and when it escalates. The team approves it before anything runs.
This is what makes governance compose rather than multiply. Policy is stated once, for the whole factory, instead of once per agent.
The runtime is where the agents work. They come from the four domains: InfraOps for build, DevOps for operate, observability for observe and SRE for remediate. No vendor will have a pre-built agent for every task, so custom agents are expected, and an agent from any source runs inside the same guardrails and audit trail.
Orchestration owns the rest: assembly, sequencing on durable workflow execution, approvals at each action boundary, verification against the commitment, and holding the objective between runs. Without it there is no factory, only four domains automating in parallel.
Four steps run continuously: execute, observe whether the outcome matched the objective, record the event with confidence attached, and adapt so the next similar situation starts from richer context.
That compounds in three ways. Resolution time falls, as a novel incident class goes from a full analysis pass, to a pattern matched in seconds, to a prevention rule that stops it firing at all. Detection moves earlier. And inference cost falls, as familiar work moves to smaller models. All of these reduce cycle time at the same arrival rate. Without this step, the work an agent saves is replaced by the work of supervising it.
In reinforcement learning, a world model is learned from experience and run forward to predict what an action will do [1]. An operations world model works the same way from a different starting point. You cannot learn a production estate by exploration, because the cost of a wrong action is an outage. So it begins with what the systems of record already hold, and updates from every real outcome after that.
Today that prediction is historical: which deviations have preceded which failures, and with what confidence. The direction of travel is toward testing a proposed action against the model before it runs, and we expect that to become how teams establish trust in an agent's judgment.
It holds nine data types: alerts and incidents; metrics, logs and traces; deployments and changes; service dependencies; cloud and Kubernetes resources; app code and infrastructure; policies, desired state and drift; pipelines and workflows; and tickets, runbooks and postmortems. A root-cause agent queries prior incidents with similar signals before forming a hypothesis, then writes the confirmed cause back. The set widens as more systems of record are connected, and every addition extends what an agent can settle without asking a person.
Every fact carries its evidence: where it came from, how confident the system is, when it was true, and who asserted it. Agents reach it through one governed query service rather than the graph itself, which is what lets an agent from any source inherit the same access rules.
Holding a graph is not the same as resolving anything. On the OpenRCA benchmark, agents handed the raw telemetry and its schema still reached a best accuracy of 11.34% on root cause [2]. What closes that gap is modeled state with evidence attached.
The agent operating system is the layer that decides what an agent may do, what it may spend, who it acts as, and what it leaves on the record. Eight things belong here.
| Element | What it does |
|---|---|
| Skills and workflows | The reusable units an agent runs. Author once, version them, and every agent calls the same tested step. |
| Policy as code | What each agent may touch, in which environment, at which autonomy level, declared in version control rather than configured in a console. |
| Guardrails and approvals | Scope every agent by service, environment and change class, and put a named human on the changes you decide need one. |
| Identity and access | Every agent holds its own scoped credential and shows up in your logs as itself. No shared key, no borrowed human account. |
| Tokenomics | A cost ceiling per run, per agent and per team, enforced before the spend. |
| Audit and evidence | Every decision, and the objective version behind it, written to a signed record you can hand an auditor. |
| Integrations | Your pipeline, ticketing and monitoring stay the system of execution. Agents act through them; the world model reads from them. |
| Model routing | Every step goes to the model that suits it, balanced across quality, speed and cost, without anyone hard-coding a model into a workflow. |
Bringing the workflow and these elements together, an Autonomous Operations Factory is constructed in five layers. The loop above is how work moves through it. The layers are what it is made of.
Two defaults sit underneath, whatever the level. Access is read-only until write is explicitly granted, per resource. Remediation arrives as a pull request, not a silent change, unless a team grants otherwise.
Autonomy is a setting, not a maturity score. It runs on five levels, and different parts of an estate will sit at different levels. The spectrum is derived from StackGen's previously published infrastructure autonomy levels [3].
| Level | What the factory does | How the domains coordinate |
|---|---|---|
| L5 Full autonomy | The factory improves itself. People set targets, ratify policy and audit outcomes. | A learning in any domain becomes policy for every domain. |
| L4 Supervised autonomy | The factory runs as one system toward declared outcomes. People intervene by exception. | Machine to machine, through shared context and one governance layer. |
| L3 Intent-directed | Automation runs inside bounded domain cells. People issue intent and approve at gates. | Within a domain only. People are the glue between domains. |
| L2 Assisted | People author the definitions. Machines validate, execute and flag deviation. | Tool by tool. People coordinate across teams and tools. |
| L1 Manual | Everything hand-built: scripts, CLI, tickets, runbooks. | None. Meetings, tickets and tribal knowledge. |
One intent, crossing four domains, with the shared context underneath it. The times are elapsed, and no person is paged at any point in the sequence.
| Time | Domain | What happens |
|---|---|---|
| 02:47 | InfraOps | An infrastructure watch agent detects a Terraform state deviation in an autoscaling group and scores the drift risk high, having correlated it with three prior incidents of the same class. |
| 02:51 | Observability | Memory pressure appears on dependent services. A change-correlation agent links the two. A P1 fires. No human is paged. |
| 02:52 | SRE | The root-cause agent traces it to the autoscaling deviation. |
| 02:54 | InfraOps | A remediation agent generates corrective infrastructure as code, which passes the policy and compliance gates. |
| 02:55 | DevOps | A deploy agent ships it through the validated pipeline behind a canary. |
| 03:04 | SRE | A verification agent confirms recovery, closes the incident and drafts the postmortem. |
Seventeen minutes across four domains, with no handoff and no page. Without the shared context the drift is never checked, and root cause takes an hour across three tools.
Part 5 covers where to start: how to measure autonomy, where to expand it first, and the enablers to build along the way.
This post is part 4 of 5 drawn from our white paper. The full paper brings the series together in one place, with the figures, the market map and every source. Download the white paper.