Agentic AI for DevOps Automation

Key facts, with sources

• Gartner predicts over 40 percent of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. (Gartner)
• Gartner predicts 33 percent of enterprise software applications will include agentic AI by 2028, up from less than 1 percent in 2024. (Gartner)
• Gartner estimates only about 130 of the thousands of vendors claiming to sell agentic AI are real, with the rest engaged in agent washing of existing chatbots and RPA products. (MarTech)
• McKinsey's State of AI 2025 found 23 percent of organizations are scaling an agentic AI system somewhere in the enterprise and another 39 percent have begun experimenting with agents. (McKinsey)
• Gartner forecasts 40 percent of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5 percent in 2025. (Joget)

Where agents actually help on-call

The highest-value DevOps agent task is the first stretch of an incident: pull the alert context, list what deployed in the last few hours, grep the error logs, check saturation dashboards, and produce a structured summary of what changed and what is failing. That work is parallelizable, fully read-only, and it is the part of on-call that burns people out.

An agent doing triage does not need to be right about the root cause — it needs to assemble evidence a human can scan in thirty seconds. I prompt for a specific output shape: what fired, what changed recently, what the logs show, and top hypotheses ranked with the supporting evidence for each. Even when the top hypothesis is wrong, having the evidence pre-gathered typically shortens the human's path noticeably.

The asymmetric permission model

I split the tool surface hard: read tools and write tools, with nothing ambiguous between. Read tools — logs, metric queries, kubectl get and describe, deploy history — the agent calls freely in a loop. Write tools do not exist as direct executables; a write from the agent's perspective is a request that lands in an approval queue or becomes a pull request. The agent experiences it as a tool result saying the change is staged.

The enforcement lives in the tool handler, not in the prompt. Prompts asking the model to be careful with mutating commands are a suggestion; a handler that refuses to execute anything outside a read-only allowlist is a control. In code audits, this is the first thing I check on any DevOps agent.

import shlex
import subprocess

READ_ONLY_PREFIXES = (
    "kubectl get", "kubectl describe", "kubectl logs", "kubectl top",
)

def run_kubectl(command: str) -> str:
    """Agent-facing tool: reads run freely, mutations get queued."""
    if not command.startswith(READ_ONLY_PREFIXES):
        ticket = approval_queue.submit(command)
        return f"BLOCKED: mutating command queued for approval ({ticket})."
    result = subprocess.run(
        shlex.split(command), capture_output=True, text=True, timeout=60
    )
    return result.stdout or result.stderr

Every mutation becomes a PR or a dry run

GitOps environments are the natural home for agentic DevOps, because the write path already exists: everything is a commit. The agent's remediation proposal becomes a branch with a terraform plan or kubectl diff attached, and your existing CI, review, and rollback machinery applies unchanged. You get agent-speed drafting with human-speed merging — which is the right ratio for infrastructure.

For imperative environments, dry-run flags are the equivalent: the agent runs the command with dry-run enabled, captures the predicted effect, and attaches it to the approval request. A human approving a change that includes its own predicted diff is making an informed decision in seconds. A human approving a bare command string is rubber-stamping.

Runbooks are the best prompts you already have

Your runbooks are pre-written agent instructions — they encode exactly the tribal knowledge a model lacks: which dashboard matters for which service, what normal looks like, what to check before restarting anything. I convert runbooks into per-scenario context the agent loads when the matching alert fires, keeping each one focused: symptoms, checks in order, known false positives, escalation criteria.

The conversion also improves the runbooks. Steps that turn out to be ambiguous for a model — "check if the queue looks backed up" — were always ambiguous for the new hire at 3 a.m. too. Making them explicit enough for an agent (queue depth above what threshold, for how long) makes them better documents for humans, and the maintenance cost stays where it always was: in engineering.

Guard the blast radius

Agents amplify whatever credentials you hand them, so scope aggressively: per-environment service accounts, read-only roles for the triage path, short-lived tokens, and separate credentials per agent so revocation is surgical. Add an iteration cap and wall-clock timeout on every loop — a confused agent re-running the same log query for an hour is a real failure mode — and a kill switch that halts all agent sessions in one action.

Then test the controls, not just the agent. My pre-production checklist includes deliberately prompting the agent to exceed its permissions and verifying the handler blocks it, and killing a session mid-run to confirm nothing is left half-applied. If those tests feel paranoid, remember the agent will run unattended at whatever hour your alerts fire.

When to hire senior help

Senior help is most valuable at the architecture stage, deciding what to automate, where approval gates belong, and how business value will be measured, before any code is written. It is also worth bringing in when a stalled pilot needs risk controls and evaluation rigor to pass security and compliance review. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Agentic AI Systems projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Buying agent-washed products, since Gartner estimates only around 130 of thousands of self-described agentic AI vendors are genuine rather than rebranded chatbots or RPA
• ✕Deploying autonomy before defining risk controls and human-approval gates, one of the three causes Gartner cites for the 40 percent of projects it expects to be canceled
• ✕Measuring activity like tasks attempted instead of business value, leaving the project unable to justify escalating costs at renewal time
• ✕Wrapping agents around existing processes instead of redesigning the workflow, when McKinsey finds workflow redesign is the single biggest driver of EBIT impact from gen AI

Frequently asked questions

Sources

• Gartner
• MarTech
• McKinsey
• Joget