Five Strangers, One Architecture: The Emerging Spec for AI in Production Operations
TL;DR: Independent engineers building AI agents for DevOps are converging on a shared set of design constraints: read-only production access, evidence-first reasoning, and human-gated execution. This "converged spec" suggests that the industry has collectively identified the safety and reliability requirements necessary for AI to move from experimental chatbots to production-ready operations tools.
Six builders, no coordination, one spec
In the last two weeks, six unaffiliated practitioners—including staff engineers at major cloud providers, open-source contributors, and independent developers—published findings on their attempts to build AI for operations. They were not working together. They were solving different problems, from payment failures to incident response.
Yet, when you look at their architectural diagrams and design philosophies, they are nearly identical. This is a classic example of convergent evolution. Just as fish and dolphins independently evolved streamlined bodies to navigate the same physical constraints of water, these builders have evolved the same architectural constraints to navigate the high-stakes environment of production software.
The five constraints they all landed on
The consensus isn’t about which Large Language Model (LLM) is best; it’s about the "harness" that keeps the model from causing a catastrophic outage. According to the systems being built today, there are five non-negotiable constraints:
1. Read-only against production
The most consistent design choice is the removal of write access. Whether it’s an open-source DevOps agent or a specialized internal tool, builders are favoring a model where the AI can query logs, trace metrics, and inspect code, but cannot execute a kubectl delete or terraform apply without an external trigger.
2. Evidence before conclusions
There is a move away from "black box" reasoning. Builders are demanding that agents provide the specific log lines or metric spikes that led to a hypothesis. According to a recent autopsy of payment failures, the most valuable AI intervention wasn't a guess at the fix, but the gathering of disparate evidence that humans missed (e.g., matching a 200 OK API response with a silent downstream failure).
3. Verification independent of the proposer
A major architectural shift is the separation of the "Actor" and the "Verifier." As documented in Microsoft-adjacent research on deep agents, the model that proposes a plan should not be the one that verifies its safety or success. Using a different model or a deterministic rule-set to check the proposer’s work reduces correlated errors.
4. A human-owned gate and a refuse-able artifact
The output of an AI agent should not be an action, but a "refuse-able artifact"—usually a Pull Request (PR) or a plan document. According to practitioners like Sandipan Kundu, whose open-source DevOps agent follows this pattern, the human remains the final authority, reviewing a proposed patch rather than watching an agent mangle a production cluster.
5. An immutable trail of what was queried and concluded
Finally, there is a push for auditability. David Khourshid (creator of XState) and others have argued for immutable event logs and state machines to track exactly what an agent did. This ensures that if things go wrong, the investigation isn't "why did the AI do this?" but "what evidence was in the log that the AI processed?"
Key Takeaway: When independent practitioners converge on the same constraints without coordination, that consensus provides a proven rubric for evaluating any agentic system near production.
Why convergence is the interesting signal
When a single vendor claims their "autonomous SRE" is safe, it is marketing. When six different developers—including those at Microsoft, independent consultants, and open-source hobbyists—build the exact same "read-only, evidence-first, human-gated" architecture, it is evidence of a fundamental truth. This convergence suggests that the era of "unbounded autonomy" in AIOps is over before it truly began.
What classic AIOps got wrong that forced this consensus
Previous iterations of AIOps—often referred to as "AIOps 1.0"—failed because they attempted to automate the action without mastering the context. According to Muhtalip Dede's analysis of why AIOps failed, these systems lacked a "load-bearing wall": a gate where a human could understand the reasoning. LLMs have changed the interface, making it easier to extract context, but the requirement for that load-bearing gate remains.
What this means if you are evaluating vendors
If you are looking at AI agents for DevOps, don't ask about the LLM version or the number of integrations. Ask these Five Constraint questions:
- Does the agent require write access to my prod cluster, or can it work read-only?
- Can the agent point to specific log lines (evidence) for every claim it makes?
- Is there a separate verification step using a different logic path or model?
- Is the output a refuse-able artifact (like a PR) or a direct execution?
- Is there an immutable audit trail of every API call the agent made?
Where the consensus is still thin
While the architecture is settling, two challenges remain: Who verifies the verifier? and Correlated model error. If two different agents use the same underlying model (e.g., GPT-4o), they may both hallucinate the same false logic. The industry is still experimenting with how to ensure truly independent verification in a world dominated by a few foundation models.
Why this matters
As production environments grow more complex, the cost of a "wrong" autonomous action increases exponentially. We are currently in the "Safety Second" phase of AI adoption, where the excitement of what AI can do is being balanced by the reality of what it should do. This architectural convergence isn't a limitation; it’s the bridge that allows AI to move from a toy in a sandbox to a tool in the production environment.
At Operate, we have watched this convergence closely because our own architecture follows this exact spec. We deploy a four-agent pipeline where the agent proposing a fix is distinct from the agent verifying the evidence, resulting in a read-only investigation that terminates in a human-reviewed PR. By aligning with these five constraints, we ensure that AI serves the SRE, rather than creating new problems for them to solve.
Sources & further reading:
- According to Muhtalip Dede, LLMs change the interface but the need for a gate remains.
- Sandipan Kundu's OpenDevOps implements a human-in-the-loop approval gate.
- David Khourshid highlights the importance of state machines for auditable agent logic.
- Arpit Bhayani argues that AI should augment, not replace, the operator.
- ITNext documents a "plan-act-verify" harness for operational data.
- A Medium case study on payment failures shows the value of investigative, evidence-first AI.