AI for Platform Engineering Is a Different Problem

The industry has settled on a mental model for making AI agents safe: watch their actions. An agent proposes a command, and a policy layer allows it, blocks it, or escalates to a human. The guardrail products being built today, and they are good products, are versions of this model. It treats an agent the way we treat a person: is this actor trusted to take this action?

For coding agents, this is probably the only available model. The space of things a programmer does is unbounded. You cannot enumerate the valid actions of someone writing arbitrary software, so you monitor at the action level, learn from history, and accept the gap between the 80% you can classify and the 20% you cannot.

I want to argue that the layer underneath the code is a different problem, and that importing the action-monitoring model into it is a mistake. AI for platform engineering is not the problem of supervising an agent's actions. It is two problems:

1. The creation of valid declarative configuration. What should the system be?
2. The evaluation of the path from one state to the next. How does it safely get there?

Everything else follows from those two.

Why this layer is different

Two properties separate platform engineering from general-purpose coding.

The configuration space is tractable. A programming language can express anything, which is why the actions of a coding agent cannot be enumerated. Infrastructure configuration cannot express anything. It describes a bounded vocabulary: accounts, networks, identities, clusters, versions, policies, wiring. The set of valid shapes is large but definable. That changes what is possible: you can write down what a valid state is, completely, in a way you never could for a codebase.

The unit of correctness is the estate, not the file. A code change can be judged largely in isolation: does this function do what it claims? An infrastructure change cannot. The failure modes live between systems: the IAM edge that severs a service in another account, the network path a new caller needs, the version skew between a cluster and the workloads on it, the migration that must land before the deploy that depends on it. Reviewing infrastructure change file-by-file, or action-by-action, is reviewing the pieces of a machine while ignoring the machine.

Action-level monitoring inherits both problems. It asks "is this command safe?", which is unanswerable without context and intent, and it evaluates one action at a time in a domain where correctness is a global property.

The first problem: valid states

Ask a platform team today how they know their estate is valid and you will get a list of fragments. Scanners that find invalid states after they are already running in production, filed as ticket four thousand in a backlog nobody burns down. Policy checks that evaluate a diff against generic rules and never see the whole. Hand-built golden modules that encode cross-system knowledge by convention, living in the heads of whoever wired them. Validity has no definition. It has residue.

The first job of AI in platform engineering is to author configuration, and the first job of the system around the AI is to make validity computable. That means the state is a value: one versioned description of everything, the workload versions and the platform they stand on, in one place. Valid is then a computation over the whole value: the cross-system derivations hold, every ratified requirement passes, and every rule learned from a past failure holds too. A state that fails the computation is not flagged. It cannot be committed.

This is where the declarative move earns its keep. Instead of writing the action rule deny rm -rf mydatabase.sql, you declare the property exists(mydatabase.sql) == true. The first is one point in an infinite action space. The second is a property of the state, and it holds against every action, tool, agent, and human, forever.

Which leads to the position I hold that most current guardrail work does not: stop asking whether the actor is trusted, and ask whether the system is allowed to be in that state. The gate does not care who is knocking. The ledger still records who knocked, because accountability needs names. But permission belongs to states, not actors.

The second problem: the path

A valid destination is not a safe journey. The second problem is evaluating the movement itself, and it decomposes into questions that are answerable before and during the move:

• What does this transition destroy? The delta between two declared states is computable. Whether it replaces a database or merely edits a tag is knowable statically, before anything runs, and a destructive move should demand a different level of ceremony than a safe one.
• In what order, through what intermediates? Some states cannot be reached directly. Version floors are real: you cannot jump a fleet from N to N+5 if N+5 can only be reached from N+3. The path is derived from the current state and the target, not written by hand.
• Is it working as we move? Validity is static, but behavior is not. Each step of a transition should hold its metrics inside a declared envelope for a declared window before the next step is permitted. The tool exiting zero is not evidence. Silence is not evidence. Absence of evidence is never success.
• Can we go back? A reverse path that has never been rehearsed is not a rollback plan, it is a hope. Where the reverse transition has been proven, retreat can be automatic. Where it has not, the honest posture is to declare the move irreversible and treat it accordingly.

Credit where it is due: Terraform has answered much of this, in a trusted fashion, for years. Its plan tells you what a change destroys, and its dependency graph works through intermediate states, for the resources under its control. Bolt-on tools evaluate the diff itself against policy. Modules define golden setups that work, provided you fit the mold, though tracing back to why the mold was shaped that way is left to wikis and the memories of senior engineers. Platform teams rightly trust this stack for what it does. But it stops at successfully making the change. Terraform can tell you the apply worked. It cannot tell you whether the change is working: whether the system behind the new configuration is holding its metrics, whether the next region should proceed, whether it is time to go back. Those questions fall to systems outside Terraform, and to humans, especially when something goes wrong. Terraform is a language for describing changes, not a change management system.

None of this is exotic. It is what the application world built for its deploys over the past fifteen years: progressive delivery, metric gates, bake time, automated rollback. The application world built it because deploys were frequent and painful. The platform layer, where changes are less frequent but far more dangerous, never got it. Infrastructure as code solved representation. Delivery is still an open question we all answer uniquely in our own companies.

The execution model matters as much as the evaluation. The AI authors the configuration and the plan. Deterministic actuators, the same reconcilers and appliers we already trust, are the only things that touch the world, and they only move the system between evaluated states along evaluated paths. The agent never holds production credentials, not as a policy, but as an architecture.

What the human does

In the action-monitoring model, escalation hands a human a command and asks for a verdict. The human lacks the context and the intent, so frequent escalation decays into rubber-stamping. The model asks people for judgment at exactly the level where people cannot judge.

In the state model, escalation hands a human a consequence: this transition destroys these resources, here is the diff, here is the classification, here is the evidence from the last environment it ran in. That is a reviewable object. The human ratifies definitions of valid, approves plans whose effects are stated, and owns every rule the machinery enforces. The work is done by agents. The judgment, and the accountability, stay with named people.

And when something escapes anyway, as things do, the failure becomes a new rule in the validity computation. Not a lesson in a post-mortem document. A permanent, mechanical guard. The system gets monotonically harder to break, which is a property no amount of action-level learning over an unbounded space can deliver.

The definition

So here is the definition I am proposing. AI for platform engineering is the creation of valid declarative configuration, and the evaluation of the path that moves a running estate from one valid state to the next. Not agent supervision. Not action filtering. States and paths.

The action-monitoring model is right for the layer where the space is unbounded: agents writing software. Underneath the software, where the space is definable and the correctness is global, we can hold a much stronger line: invalid states that cannot be committed, transitions that prove themselves as they run, and humans who judge consequences instead of commands.

That layer is where the worst incidents already come from, and it is about to receive more change, faster, than it has ever seen. It deserves better than an imported model built for a different problem.