The On-Call Agent: What It Should and Shouldn't Touch During an Incident

An agent that helps during an incident is one of the highest-value applications available, and one of the easiest to build badly. Incidents are exactly when a system is least understood, most fragile, and most consequential — which is a poor setting for an autonomous actor, and an excellent one for an autonomous investigator.

The distinction between those two roles is the whole design.

What it should do: compress the first ten minutes

The opening of an incident is mechanical and slow. Someone gets paged, opens five dashboards, checks recent deploys, greps logs, works out which services are downstream, and tries to remember whether this looked like the thing from March.

Every one of those is a read, and an agent does them in parallel while a human is still finding the right browser tab.

A useful incident agent, triggered by the page, produces something like:

Alert: checkout p99 > 3s, started 14:02Z

Deploys in the last 2h:
  - payments-svc v4.21  13:47Z   ← 15 min before onset
  - web v9.8            11:20Z

Error rates:  payments-svc 0.2% → 4.1% at 13:58Z
              checkout     unchanged until 14:02Z
Dependencies: checkout → payments-svc → ledger-db
ledger-db:    connection pool 198/200, climbing since 13:50Z
Similar past incidents: INC-4471 (pool exhaustion after payments deploy, Mar)

That's not a diagnosis, and it shouldn't pretend to be. It's the context-gathering that a responder does first, done before they arrive. ✅ The measure of a good one: how much of the responder's first ten minutes it removes.

What it shouldn't do: act on a system it can't model

The temptation is remediation — restart the service, roll back the deploy, scale the pool, fail over. Resist it, for reasons specific to incidents:

The system is in an unusual state, which is why you're here. An agent's judgment rests on patterns from normal operation. An incident is the case where those patterns don't hold, and that's precisely when it will act confidently on a wrong model.

Actions during an incident are hard to reverse and easy to compound. A rollback during a partial failure can produce a worse partial failure. A restart can clear the evidence needed to understand what happened. Some remediations are only correct in a specific order that depends on the actual cause.

Attribution becomes impossible. If the agent took four actions and the system recovered, nobody knows which mattered, and the postmortem loses the thing it exists to produce.

The middle ground: prepared actions, human trigger

Rather than acting or not acting, have the agent prepare actions and let a human execute:

Suggested actions (none executed):
  1. Roll back payments-svc to v4.20  → ready, command prepared
  2. Raise ledger-db pool 200 → 400   → ready, requires DBA approval
  3. Shed load on /checkout            → prepared, affects ~8% of traffic

Recommend 1 first — onset correlates with the deploy, and it's
the most reversible of the three.

The responder gets the speed of preparation with none of the surprise. One click, but the click is theirs, and the reasoning is visible before it happens.

The narrow exception

A small class of remediations is safe to automate, and it's worth naming so this doesn't read as a blanket prohibition: actions that are idempotent, bounded, reversible, and already trusted enough to be a runbook one-liner. Clearing a specific known-safe cache. Restarting a stateless worker that has a documented restart procedure and no in-flight state.

The test is whether the action is already automated for non-incident conditions. If a human wouldn't need to think about it at 3pm, an agent can do it at 3am. If it requires judgment at 3pm, it requires a human at 3am — and the fact that the human is sleepy is an argument for better preparation, not for removing them.

⚠️ Two failure modes specific to this

Confident wrong correlation. Something always deployed recently. The agent will find it and it will look causal. Have it report correlations with timing and explicitly state what it did not check — "no evidence gathered on network or upstream provider status" is a valuable line, and its absence makes the report feel more complete than it is.

The evidence trail. An agent reading logs and dashboards should record exactly what it queried and what came back, timestamped. Postmortems depend on reconstructing what was known when, and an agent that summarized without preserving sources makes that reconstruction impossible.

The takeaway

Give the incident agent broad read access and no write access. Have it gather, correlate, and prepare — and let the human decide. The value is in the ten minutes it saves at the start, which is substantial and boring, rather than in autonomous remediation, which is exciting and where a wrong model of a broken system does its damage.