How to Use AI Agents for DevOps: A Practical Guide

The question has shifted. A year ago DevOps teams asked whether AI agents were ready for operational work; now they ask which work to hand over first, and how to bound the blast radius while trust builds. Both halves matter, because the failure modes are asymmetric: an agent that reads too little wastes an opportunity, and an agent that writes too freely creates the incident it was meant to prevent.

This guide is organized around that asymmetry. First, the six DevOps jobs where agents earn their keep today — ordered roughly by how much writing to production they require. Then the trust ladder we recommend for rolling them out, one workflow at a time. (Disclosure: we build Kestrel, an automation platform built on the agent-builds/workflow-executes split described here; we'll note where it's relevant.)

Six DevOps jobs AI agents do well today

1. Diagnosing CI and pipeline failures

Pipeline failures are the highest-volume, lowest-stakes place to start. When a build or deploy job fails, an agent reads the logs, correlates against the diff that triggered the run, distinguishes a flake from a real break, and posts the diagnosis — with the failing test, the likely cause, and a suggested fix — to the PR or the team channel. Nobody context-switches into a 400-line log dump; the failure arrives pre-digested. This is entirely read-only, which is what makes it the right first agent to deploy. Kestrel wires this as a signal-triggered workflow: a failed GitHub Actions run triggers the diagnosis automatically (see the GitHub integration docs).

Click to expand

2. Verifying deploys and gating the rollback

The minutes after a deploy are a diagnosis problem on a timer: is the error-rate bump noise, or the start of an incident? An agent compares post-deploy metrics against the pre-deploy baseline, checks logs for new error signatures, and renders a verdict. The write side — rolling back — runs as a deterministic workflow behind an approval gate: the agent presents its evidence, a human taps approve in Slack, and the rollback executes the same way every time. As confidence grows, the gate can come off for specific, well-understood failure signatures.

3. Triaging alerts and running root cause analysis

The most expensive part of on-call isn't fixing things — it's the 30 to 45 minutes of gathering before anyone can decide what to fix. An agent does that gathering the moment the alert fires: pulls the relevant logs and metrics, checks recent deploys and config changes, walks the dependency chain, and pages the human with findings attached instead of a bare alert name. For change-caused incidents — the most common kind — the agent can go further and identify the specific PR that caused the incident, turning triage into a review of evidence rather than a search for it.

4. Answering on-call questions in Slack

During an incident, half the channel traffic is questions with objective answers: which version is deployed where, when did this alert last fire, what changed in the last two hours, who owns this service. An agent with read access to your infrastructure answers these in-thread, immediately, without pulling a second engineer into the incident. The same interface handles routine requests outside incidents — deploy statuses, log lookups, resource states — which quietly removes a large class of interruptions:

5. Checking for drift and policy violations

Configuration drift is a diagnosis problem that nobody schedules time for: resources that no longer match their IaC definitions, security groups that widened during an incident and never narrowed, untagged infrastructure accumulating cost. An agent running on a schedule audits the live state against the declared state, files the discrepancies with context, and — where the fix is safe and well-defined — proposes the remediation as a gated workflow run rather than a wiki task.

6. Drafting new automation from plain English

The most leveraged job on this list: instead of executing operations, the agent builds the automation that will. Describe a procedure in plain English — "when a deploy fails, diagnose it, post to #deploys, and offer a gated rollback" — and the agent assembles a workflow with the trigger, steps, conditions, and approval gates, which you review on a canvas before it goes live. This is how Kestrel's Workflow Agent works (the workflow creation docs walk through it), and it inverts the economics of automation: the cost of automating a procedure drops from an engineering project to a paragraph.

The trust ladder: read-only, gated writes, full automation

The mistake teams make with agent adoption is treating trust as organization-wide — a long evaluation, then a big switch. Trust is per-workflow, and it climbs a ladder:

• Rung 1: read-only. The agent investigates, diagnoses, and answers questions. It cannot change anything, so the worst case is a wrong diagnosis a human catches. Jobs 1, 3, 4, and 5 above start here. Most teams see value within the first week.
• Rung 2: writes behind approval gates. The agent (or the workflow it triggers) can act — roll back, restart, scale, remediate — but every write pauses at a gate a human answers from Slack with the evidence attached. The human is still in the loop, but at the decision, not in the terminal.
• Rung 3: full automation, narrowly scoped. For workflows with a proven track record and bounded blast radius — restart a crash-looping pod, expire a temporary access grant, retry a flaky job — the gate comes off. The audit trail stays.

Each workflow climbs independently: your rollback automation might sit at rung 2 for a quarter while pod restarts run at rung 3 from week two. The ladder only works if the platform enforces it — which is why permission fencing (this workflow may touch these clusters, these accounts, nothing else) and gate placement need to be properties of the workflow itself, not conventions in a doc.

The architecture that makes it safe

Underneath the ladder is one architectural rule: agents reason, workflows execute. The agent handles the open-ended work — diagnosing a novel failure, deciding which procedure applies, drafting new automation. The execution is a deterministic workflow: explicit steps, versioned, reviewed once, identical on every run. An agent that improvises writes against production makes every incident a first encounter; a workflow that executed correctly four hundred times is a known quantity. This split is also what makes the audit story tractable — every run has a step-by-step log, and failed runs can be diagnosed and replayed like any other software artifact.

A checklist for evaluating any agent product against this bar: Can you review what it will do before it does it? Can you fence what it may touch? Can you put an approval anywhere in the flow? Is every action logged with enough detail to reconstruct the run? Can you replay after a fix? If the answer to any of these is no, keep that product at rung 1.

Where the agents plug in: Slack, CLI, MCP

Adoption follows the interface. Agents that require a new console get used by whoever championed the purchase; agents that live where the work already happens get used by everyone. In practice that means three surfaces: Slack for on-call and requests, the terminal for engineers (Kestrel ships a CLI), and — increasingly — your coding assistant. Via the MCP server or the Python SDK, the agent in Cursor or Claude that just wrote your deployment config can also build and trigger the operational workflows around it. We covered that angle in depth in automation for AI agents; and if you approach this space from a platform engineering lens rather than a DevOps one, the companion piece is How to Use AI Agents for Platform Engineering.

A 30-day rollout plan

A concrete sequencing that has worked repeatedly:

• Week 1 — connect read-only integrations (setup guide) and turn on CI failure diagnosis. Zero risk, immediate visibility, and the team starts seeing agent output in their normal channels.
• Week 2 — wire alert-triggered investigation for your two noisiest alert types. Measure the delta in time-to-understanding; this is usually the number that converts skeptics.
• Week 3 — add the first gated write: deploy verification with an approval-gated rollback. Keep the gate on even if it feels unnecessary; the reviewed evidence trail is what builds the case for rung 3.
• Week 4— convert your most-used runbook into a workflow, and open self-service in Slack for the single most frequent developer request. Review what the month's unmatched requests were; that list is your automation backlog.

Common failure modes when adopting DevOps agents

• Starting with the scariest workflow. Teams that lead with autonomous production remediation usually end the pilot after the first surprising action. Lead with diagnosis; the write privileges come later, with evidence.
• Skipping the fence. An agent with org-wide credentials is a single compromised prompt away from an org-wide problem. Scope every workflow to the namespaces, accounts, and repos it actually needs — least privilege applies to agents more, not less.
• Measuring nothing. If you can't say what triage took before the agent, you can't defend the agent at budget time. Capture baseline MTTR and interruption counts in week zero.
• Letting diagnoses go unreviewed. Early on, wrong-but-confident diagnoses are the main risk at rung 1. Have on-call engineers grade agent findings for the first month — the feedback tightens the prompts and builds justified trust rather than assumed trust.
• Automating around the incident process instead of into it. Agent findings should land in the same channels, tickets, and postmortems the team already uses. A parallel AI process is a process nobody checks.

What changes for the on-call rotation

The practical effect of all six jobs landing is a different shape of on-call. Pages arrive with the investigation attached, so the first minutes are spent deciding rather than gathering. The mid-incident interruptions — status questions, log lookups — answer themselves in-thread. Known failure modes remediate behind a gate or, eventually, without one. What remains for the human is what actually requires one: novel failures, judgment calls with real trade-offs, and the postmortem work of turning this incident's lessons into next month's automation. Teams consistently report the same qualitative shift — on-call stops being a week of dread and becomes a week of supervision.

How to evaluate agents before trusting them

Trust should be earned by measurement, not by vibes. Three numbers cover it. Diagnosis accuracy: of the agent findings your on-call engineers graded this month, what fraction were correct and what fraction were confidently wrong? The second category is the one that gates promotion up the ladder. Time saved per event: baseline the manual version (triage minutes, log-reading minutes) in week zero, then track the delta — this is the number that survives budget review. Approval-to-override ratio: for gated writes, how often do humans approve the agent's proposed action versus change it? A consistently high approval rate over a meaningful sample is the objective case for removing a specific gate; a low one tells you exactly where the agent's judgment still lags yours.

Frequently asked questions

What DevOps tasks can AI agents automate?

The diagnosis- and procedure-shaped ones: CI failure diagnosis, deploy verification with gated rollback, alert triage and RCA, on-call Q&A in Slack, drift checks, and tracing incidents to the causing change. The agent investigates and proposes; deterministic workflows execute.

Can AI agents safely operate in production?

Yes, if writes never come from improvisation. Climb the trust ladder per workflow: read-only first, then writes behind approval gates, then full automation only for proven, bounded workflows — all permission-fenced and logged.

AI agent vs. runbook automation — which do I need?

Both, doing different jobs. Runbook automation executes fixed procedures reliably; agents handle the open-ended parts — diagnosing what's wrong, choosing the procedure, and drafting new automation. The strongest setups pair an agent's judgment with a workflow's determinism.

Will AI agents replace DevOps engineers?

No — they change the ratio of reacting to designing. Agents absorb investigation toil and repetitive execution; engineers own what gets automated, where the gates go, novel failures, and post-incident improvement.

The bottom line

Give agents the jobs they're provably good at — diagnosis, triage, verification, Q&A, and drafting automation — and give the writes to deterministic, gated, permission-fenced workflows. Climb the trust ladder one workflow at a time, and within a month the on-call experience is different in kind: humans arrive at incidents with the investigation already done, and routine requests resolve themselves.

That architecture — agents reason, workflows execute — is exactly what Kestrel is. Start with the incident response quickstart or browse the docs.