AI Agents for Infrastructure and DevOps: What Actually Works in 2026

Every vendor deck this year promises an AI agent that will "run your infrastructure." We use AI agents daily — they helped us ship three open-source infrastructure tools — and we operate a real network, AS210622, where a bad change means real packets stop flowing. That combination has given us a fairly unsentimental view of what agents are good for in infrastructure work, and where the marketing gets ahead of reality.

The short version: agents are excellent at proposing infrastructure changes and terrible at being trusted to apply them. Almost everything else follows from that distinction.

Where Agents Earn Their Keep

The wins are real, and they cluster around work that has a clear pattern to follow and a human checkpoint at the end:

• Terraform and Kubernetes manifests against an existing pattern. Once your repo has one well-built module or one properly configured Deployment, an agent can produce the next ten variants faster than anyone on the team — and, importantly, consistent with the existing style. The pattern is the spec. This works because Terraform at scale is mostly disciplined repetition, and disciplined repetition is exactly what agents do well.
• Dockerfiles and CI pipelines. Multi-stage builds, cache mounts, matrix builds, release workflows — this is well-trodden ground with strong conventions. Agents produce good first drafts and catch the flags you forgot.
• Runbook drafts. Give an agent the alert definition, the dashboard, and the escalation policy, and it will produce a runbook skeleton that an on-call engineer can correct in twenty minutes instead of writing in three hours. The correction step is not optional — but it is much cheaper than the blank page. Our incident response playbook got its first drafts this way.
• Log and incident summarization. Feeding an agent a noisy incident channel or a wall of logs and asking "what actually happened, in order" is one of the highest-value, lowest-risk uses we know. It is read-only by construction.
• Migration chores. Renaming a resource across forty modules, updating a provider version and fixing the deprecations, converting one CI system's syntax to another's. Mechanical, boring, and exactly the work nobody wants.

Notice what these have in common: the agent's output lands in a file, a PR, or a document. A human — or a pipeline acting on a human's approval — stands between the output and production.

Where They Don't

The failure mode is not agents writing bad configuration. They do sometimes, and review catches it. The failure mode is wiring an agent so that its output takes effect without review.

An agent that can run kubectl apply against production, or push to a branch that auto-deploys, or modify a security group directly, has a blast radius equal to its credentials — and unlike a human operator, it will act on a misunderstanding with total confidence and machine speed. We have watched agents (our own, in sandboxes) confidently "fix" a problem by deleting the thing that was reporting it. In a sandbox that is funny. With production credentials it is an incident with an unusual root-cause section.

This is not a temporary limitation that the next model release fixes. It is a structural property: agents act on text, text can be wrong or malicious, and production is where mistakes become outages.

The Golden Rule: Agents Propose, Pipelines Apply

The pattern that works — the one we would recommend to any team wiring agents into infrastructure — is that agents propose, pipelines apply.

Concretely: the agent's write access is a pull request. Nothing more. The PR triggers the same machinery a human's PR triggers — terraform plan, policy checks, kubeconform, CI. A human reads the plan output. Merge deploys through the same GitOps reconciliation that applies every other change.

GitOps turns out to be the natural harness for AI-generated infrastructure changes, for the same reason it was worth adopting before agents existed: it forces every change through a reviewable, auditable, revertible path. If you already run plan-on-PR and continuous reconciliation, you have most of the guardrail infrastructure agents need. If you don't, that — not agent tooling — is the first thing to build.

The corollary for access: read-only first. An agent that can query your metrics, read your manifests, and inspect your state files can already do most of the valuable work — summarize, diagnose, draft. Write access, when you grant it, goes through the same PR gates a new team member's would. We wrote more about wiring this up safely in our post on giving agents access to real infrastructure.

The Blast-Radius Question

Before wiring any agent to any system, we ask one question: if this agent does the worst plausible thing its access allows, what happens?

Not the worst likely thing — the worst plausible one. An agent with a read-only Grafana token can leak a dashboard. An agent with cluster-admin can delete namespaces. An agent that can merge its own PRs can bypass every review gate you built. If the answer to the question is worse than "we revert a commit," the access is too broad.

This is the same reasoning we apply to human credentials and to any automation, agents included. The difference is that teams who would never hand a contractor cluster-admin on day one will hand it to an agent because the demo was impressive. The demo is always impressive. Scope the credentials anyway.

An Honest Assessment

Where does that leave AI agents in infrastructure work in 2026? They are leverage, not replacement. The judgment calls — what to build, what "correct" means, what risk is acceptable, when the plan output smells wrong — remain human work, and in our experience become more important, not less, because the volume of proposed change goes up. An engineer with a well-harnessed agent produces more than one without. An agent without an engineer produces incidents.

We say this as people bullish enough on the technology to have built our workflow around it. The teams getting real value are not the ones with the most autonomous setup. They are the ones with the best guardrails.

Takeaways

1. Use agents where output lands in a reviewable artifact — manifests, pipelines, runbooks, summaries, migrations
2. Never let agent output reach production unreviewed — agents propose, pipelines apply
3. GitOps and plan-on-PR are the harness — if you don't have them, build them before wiring in agents
4. Read-only access first; write access only through the same PR gates humans use
5. Ask the blast-radius question before granting any credential: what is the worst plausible action this access allows?
6. Treat agents as leverage for engineers, and invest in the engineers' judgment accordingly

If you want help putting the guardrails in place — GitOps, CI gates, scoped access — so your team can use agents without betting production on them, that is exactly the kind of work we do.