When AI Agents Join the On-Call Rotation: Practical AI in DevOps

3:47 AM. The phone rings, the dashboard is solid red, and a half-asleep on-call engineer is wrestling thirty browser tabs. That scene hasn't changed in twenty years. Now it might — but not the way the marketing says.

I don't believe the sentence "AI will take over on-call." I believe this one: "AI will sit next to the on-call engineer as a very good apprentice." The difference is what this post is about.

Three jobs that genuinely work today

1. Alert triage. An enterprise environment produces hundreds of alerts a night; most are noise. The LLM's first real contribution is here: reading the alert storm and saying "these 40 alerts look like one root cause — that service's connection pool." It doesn't decide — it assembles the scene. At 3:47 AM the on-call engineer's scarcest resource isn't intelligence, it's context; an agent builds context in seconds.

2. Log and change summarization. The answer to "what changed in the last two hours?" is scattered across five systems: deploy records, config changes, feature flags. Having an agent read those sources and produce a one-paragraph summary is today's lowest-risk, highest-return use. Even when it's wrong, the cost is low — because the output is a summary, not an action.

3. Runbook execution — behind an approval gate. Mature teams' runbooks are already semi-automated. The agent's contribution is finding the right runbook, filling in the parameters, and saying "I propose running this." Execution obeys the laws from the first post: idempotent tools, bounded authority, human approval, full audit trail.

Where I draw the line

The jobs I do not give an agent today are just as clear:

• Irreversible actions — deleting data, triggering failover, scaling down. Propose, yes; execute autonomously, no.
• The root-cause "verdict" — generating hypotheses is brilliant; but "this was definitely it" must be a human sentence. Models are convincingly wrong.
• Customer communication — let it draft the status-page message; a human presses send.

The on-call engineer's new job description

The role isn't disappearing; it's being promoted. Yesterday's on-call engineer was a log archaeologist; tomorrow's is a decision-maker evaluating the scene their apprentice assembled. That is less exhausting and more valuable work. The practical consequence for teams: make your on-call handbook agent-readable — your runbooks are no longer written only for humans.

A starting recipe

Start small: a read-only agent + the alert channel + a "summarize and propose" mandate. Observe for two weeks; measure how often the proposals are right. Trust is the precondition for expanding authority — do it in the other order, and you'll measure trust in production outages.

3:47 AM will still be hard. But starting with one summary instead of thirty tabs is a different kind of night. Let the work speak.