AI agents in the DevOps loop: where they help and where they hurt

Over the last year, almost every team I talk to has asked me some version of: “Can we put an AI agent in our pipeline?”

My honest answer is yes, for some things, with guardrails. It’s not the most exciting answer, but it’s the one that holds up. Here’s how I think about it.

Where agents actually earn their keep

1. Reviewing IaC pull requests. Picture an agent that reads a Terraform plan and says, in plain English, “heads up, this destroys and recreates the production database”. That catches the stuff tired humans miss at 6pm on a Friday. It doesn’t replace the human reviewer. It makes the human a lot faster.
2. Gathering context during incidents, read-only. Pod logs, recent deploys, the relevant dashboards: the agent pulls it all together and hands the on-call engineer a summary. The human still makes the call.
3. Toil with a clear finish line. Bumping Helm chart versions, updating base images, fixing lint findings. If “done” means “CI is green”, an agent is a great fit.
4. Answering “how do I…?” questions. An assistant grounded on your platform docs will answer “how do I get a new namespace?” better than the wiki page nobody has updated since 2022.

Where they hurt

• Write access to production with no review step. Please don’t. I treat agent actions like a new junior engineer’s: same PR, same pipeline, same approvals. No shortcuts because “the AI did it”.
• Fuzzy tasks. “Improve our architecture” isn’t a prompt, it’s a workshop. Without a way to check the result, you just get confident-sounding noise.
• Secrets in the context window. Scope credentials per task, use short-lived tokens, and log every tool call. You’ll thank yourself during the first audit.

The setup I usually recommend

 developer / alert
        │
        ▼
  ┌─────────────┐   read-only tools    ┌──────────────┐
  │  AI agent   │ ───────────────────▶ │ k8s, logs,   │
  │ (sandboxed) │                      │ cloud APIs   │
  └─────┬───────┘                      └──────────────┘
        │ proposes change as a PR
        ▼
  ┌─────────────┐  plan + policy checks  ┌────────────┐
  │   Git repo  │ ─────────────────────▶ │  CI / CD   │
  └─────────────┘   human approval       └────────────┘

The key idea: the agent never talks to production directly. Git stays the source of truth, and all the controls you already have (code review, policy checks, environment promotions) keep doing their job. You’re adding a teammate, not a back door.

Start small, and measure

Pick one workflow. Measure something boring but real, like time to review a PR or time to mitigate an incident. Only expand once the numbers say it’s worth it.

That’s the approach I keep coming back to whenever I build one of these: pick one workflow, build the agent alongside the people who’ll actually use it, and keep an evaluation setup around so it keeps getting better over time.