PriorStates · Writing · Automate Ops Monitoring & Incident Response

How to Automate Ops Monitoring and Incident Response with LLM Agents (Without Making It Worse)

A practical guide to putting an LLM agent on the pager. Its companion idea matters more than the build: in research, the danger is an agent that fools itself; in ops, the danger is an agent that takes a confident wrong action at 3am and turns a blip into an outage. Detecting issues is the easy part. The guardrail that stops a bad action is the product.

Scope note: this builds toward an ops copilot that watches, triages, diagnoses, and proposes — and takes only bounded, reversible actions on its own. Anything irreversible or wide-blast-radius stays gated behind a human. Don’t build the version that reboots prod unsupervised.

1. The two failure modes

Automated ops fails in two opposite directions, and a good design has to defend both at once:

Alert fatigue (too passive). The agent forwards everything, pages on noise, and humans learn to ignore it. A monitor nobody trusts is worse than no monitor — it launders real signals into background hum.
Runaway action (too aggressive). The agent “fixes” things — restarts a service mid-recovery, scales down during a transient spike, rolls back a healthy deploy because one metric blinked. It mistakes a symptom for a cause and amplifies the incident.

The hard engineering is in the middle: an agent that is trusted enough to act on the small stuff and disciplined enough to stop before the dangerous stuff. Everything below builds that boundary.

2. Why a structured substrate makes this possible

As with research automation, an LLM is only as good as what it can read and act through. Three substrate pieces turn “an LLM near your logs” into a real ops agent:

Machine-readable runbooks. Your existing incident runbooks — if this symptom, check these signals, the safe remediation is X, escalate if Y — become the agent’s procedure library. An agent improvising a fix is dangerous; an agent executing a vetted runbook step is useful. Write runbooks as explicit symptom → checks → bounded action → stop condition, not prose.
Durable shared state. Give the agent a persistent incident board and a session memory, so it knows what’s already firing, what it tried five minutes ago, and what a human last decided. Without this it has amnesia: it re-pages the same alert and re-attempts the same failed fix forever.
A clean observe surface. Structured access to metrics, logs, and health endpoints — read-only — so triage is a query, not a guess.

If your runbooks live only in people’s heads and your state is a Slack scrollback, step one isn’t “add an LLM,” it’s “make the operational knowledge addressable.”

3. The loop

   OBSERVE     read metrics / logs / health (read-only, always safe)
      ▼
   TRIAGE      is this real? severity? known pattern? dedupe against the board
      ▼
   DIAGNOSE    correlate signals; map symptom → likely cause via runbook
      ▼
   PROPOSE     the specific bounded action + its expected effect + its rollback
      ▼
   ACT*        *only if the action class is pre-approved as safe; else escalate
      ▼
   VERIFY      did the metric actually recover? if not, revert and escalate
      ▼
   RECORD      write to the incident board: what fired, what was done, outcome

The asymmetry is the whole point: OBSERVE, TRIAGE, DIAGNOSE are always safe and should run fully autonomously. ACT is gated by action class. Most of the value is in turning a noisy firehose into a clean, deduped, diagnosed, ranked set of incidents — before any action is ever taken.

4. The autonomy ladder — gate by action class, not globally

Don’t ask “should the agent be autonomous?” Ask “which actions can it take alone?” Classify every remediation:

Class	Examples	Autonomy
Read-only	query logs, summarize, correlate, draft a postmortem	Full — no approval
Reversible & bounded	clear a cache, retry a failed job, rotate a log, restart a single stateless worker	Auto, with rate limit + verify + auto-revert
Wide blast radius	scale a fleet, restart a stateful service, change config	Propose only — human approves
Irreversible / risky	delete data, fail over, roll back a release, touch anything trading-live	Hard stop — human acts

The agent should run the top two rows in its sleep and never cross into the bottom two without a human. This single table prevents most automation disasters: it makes “don’t make it worse” a property of the system, not of the model’s judgment in the moment.

5. The guardrails (the part that matters)

This is the ops analog of “the skeptic is the product.” Each rule exists to bound the damage a confident-but-wrong agent can do:

Separate the observer from the actor. Run a report-only monitoring agent with read-only credentials. It can page and propose but physically cannot execute. A separate, more-privileged actor handles approved actions. Most of the time you only need the observer.
Every action carries its rollback. The agent must state how to undo an action before taking it. No stated rollback → the action is not in the auto-approved class. Period.
Idempotent and bounded only. Auto-actions must be safe to repeat and limited in scope (one worker, not the fleet). If repeating it could compound damage, it’s not auto.
Rate-limit actions, not just alerts. Cap auto-remediations per unit time. A flapping service must not trigger 200 restarts. After N attempts, stop and escalate — flapping is itself a signal a human needs to see.
Verify, then revert. After any action, confirm the target metric actually recovered. If it didn’t, undo and escalate. An action that didn’t help is an action to roll back, not to repeat harder.
Stop conditions, explicit. Borrowed from a good worker brief: stop if the evidence is inconclusive, stop if the fix requires broader change, stop if another process already owns the same resource. Make these first-class, not hoped-for.
Single source of truth for action. One coordinator decides; leaf agents execute. Never let two agents act on the same resource concurrently — racing remediations are how you get the outage you were trying to prevent.
Adversarial check before risky acts. For anything above the auto line, a second agent (or a hard human gate) reviews the proposed action and its blast radius before it runs. Default to “don’t act” under uncertainty.

If the loop in §3 is the body, this section is the brake. An ops agent without it doesn’t reduce incidents — it manufactures novel ones faster than a human could.

6. The team architecture

The shape that works mirrors a human on-call org:

One scheduled coordinator. A single recurring pass (e.g. every few minutes) owns the observe→triage→diagnose loop and the incident board. Exactly one — multiple scheduled loops collide, double-page, and race on remediation.
Domain managers. Separate, mostly-manual agent contexts per domain (platform, data, app, infra) so a focused agent reasons over one area’s signals and runbooks instead of drowning in everything. Each keeps its own state.
Leaf workers, briefed. Execution agents are leaf nodes, not alternate coordinators. Hand each a tight brief: objective, allowed scope, out of scope, required validation, return format, and stop conditions. Bounded autonomy beats open-ended autonomy every time.
Privileged actions are centralized. Risky/irreversible operations run from one controlled place with a human in the loop — never delegated to a leaf.

The throughline: many eyes observing, one brain coordinating, narrow hands acting.

7. What the LLM is good and bad at here

Good at	Bad/dangerous at
Triage: is this real, how severe, known pattern?	Judging blast radius of an action it hasn’t seen before
Correlating logs/metrics across services into a cause	Novel incidents with no runbook — improvises confidently
Drafting the remediation, the comms, the postmortem	Irreversible decisions under time pressure
Deduping noise into a clean, ranked incident list	Knowing when not acting is the right move
Never sleeping, never getting alert-fatigued	Calibrated uncertainty — it rarely says “I don’t know”

Division of labor follows: the LLM owns observation, triage, diagnosis, and drafting; the authority to take a risky action stays with the action-class gates and a human.

8. Measure the ops agent itself

Instrument the system so you can trust and improve it:

False-page rate — fraction of pages that were noise. Too high and humans tune it out; this is the alert-fatigue meter.
Auto-resolved rate — fraction of incidents closed by safe auto-actions without a human. The real leverage metric.
Action-revert rate — fraction of auto-actions that had to be undone. This is the “is it making things worse” meter; watch it like a hawk.
MTTR delta — time-to-resolution with the agent vs. without.

When auto-resolved is high but action-revert is also climbing, the agent is acting past its competence — tighten the auto class before you trust it further.

9. The open problem

Research automation is about not fooling yourself; ops automation is about not making things worse. Both reduce to acting wisely under uncertainty, but ops has a crueler clock and irreversible moves. The throughput that lets an agent watch everything tirelessly is exactly what lets it act wrongly at scale and at 3am. The teams that win won’t have the cleverest auto-remediation — they’ll have the most disciplined sense of when not to act. A great ops agent, like a great on-call engineer, is defined less by what it fixes than by what it knows to leave alone and escalate.

Drawn from running a multi-agent operations setup for a live trading stack — scheduled coordination, domain managers, report-only monitoring, and bounded worker briefs with explicit stop conditions. Every guardrail here is one I rely on in production. For the research-side counterpart, see Autonomous Alpha Research — A Design That Doesn’t Fool Itself.