If the Agent Acked, Is the Incident Over?

03:12: disk usage on web-3 pages the rotation. 03:14: acknowledged. 03:16: a runbook restarts a worker pool. 03:19: web-3 is still filling, the new pool is thrashing, and nobody's phone has made a sound. The agent muted follow-up pages because, from its point of view, it was already on the incident.

That failure arrives the moment you let an operations agent ack an alert, query telemetry, or execute a fix through an MCP-style tool. PagerDuty, Datadog, ServiceNow, and the major clouds are pushing this into Q3 buying conversations right now. The pitch is blunt: August coverage is thin, senior people are out, and the agent can take the first look.

The industry is arguing about whether you should let AI help on-call. That is the wrong question. The moment an agent can acknowledge a page or change production, it is on-call, whether you put it on the schedule or not.

An ack is not a resolution

In a human rotation, acknowledgment is ownership. Someone accepted the page, started a clock, and is accountable if the next signal is quieter than it should be. Most on-call systems model that as a person: a user ID, a schedule, an escalation policy.

Agents do not fit that model. They can:

• Acknowledge or mute so the escalation never fires
• Query logs and metrics, then write a cause that is only plausible
• Restart a service, scale a pool, or roll a config because the runbook said so
• Close the incident because the symptom dropped, not because the cause did

If those actions show up as "automation ran" or "bot commented," you have a hole. After 3 a.m. you need answers in the same view as the original alert:

• Which agent identity did this?
• Which tool call, with which arguments, against which resource?
• Who approved it, or was approval skipped?
• What was the blast radius: this host, this pool, this region?

If you cannot answer those, you did not resolve the incident. You outsourced it to an unmonitored operator.

We already hit a cousin of this problem when spend limits sat in the request path. In When the AI Budget Runs Out, Is Your Service Down?, the failure was a capability that vanished while the app still looked up. This is the inverse: a capability that acted while the pager went quiet. Both are availability problems. Only one of them looks like success in the timeline.

This is the minimum record:

03:14:12  actor=agent:sre-bot-prod     action=ack
          incident=INC-1842            alert=disk_usage host=web-3
03:16:04  actor=agent:sre-bot-prod     action=tool.runbook.restart_pool
          target=workers-b             approved=false  reason=runbook_default
03:16:11  actor=agent:sre-bot-prod     action=mute
          duration=45m                 remaining_pages=0

If that record is missing, the postmortem becomes archaeology in logs that were never designed to explain an operator.

The stack still models humans, hosts, and services

Classic monitoring is good at the objects it was built for. Checkmk and Icinga will tell you which check failed on which node. PagerDuty will tell you who is on the schedule and who hit acknowledge. Those signals are necessary. They are no longer enough.

Production now includes non-human actors with control-plane access: Datadog queries, Kubernetes APIs, cloud CLIs, ticketing systems. They run as service principals and API keys. In the demo they often have broader permissions than the human they replace, because the pitch is that the agent can just handle it.

The silent path is specific:

1. The agent acks or mutes, so the human never sees the page.
2. The agent acts on the wrong object: the healthy pool, the replica, last week's hostname.
3. The symptom improves or the check is suppressed, so the incident is marked resolved.
4. The original cause continues. The next signal is a customer ticket, not a page.

None of that requires a malicious model. It only requires that remediation is treated as a feature instead of an auditable shift.

Since 2 August 2026, this is not only an ops preference. The EU AI Act's GPAI obligations are in force. Traceability of AI-system behavior is a live audit request, not a 2027 slide. If a customer, a regulator, or your own postmortem asks what the model did to production, "the bot handled it" is not an answer.

Buy attribution, not silence

Q4 monitoring decisions are being locked in this window. Vendors will show a chat that acknowledges an alert and pastes a graph. They will call it AI SRE. That demo is not the criterion.

Demand the agent as a first-class actor. In a live incident you should see:

• A stable identity for the agent, distinct from system or integration
• Every tool call: input, output, timestamp, target
• The approval path: auto-allowed, human-approved, or skipped
• Blast radius in the same language you use for change windows
• A page to a human when the agent is wrong, looping, or muted too long
• A kill switch that does not depend on finding who stood up the MCP server

If they cannot show the agent in the timeline, they are selling you a quieter pager. Silence is not reliability. It is a missing escalation.

Run this tabletop before the agent joins a real rotation:

• Disk fills on host A. The agent restarts the process on host B because a hostname was interpolated from a stale runbook. Does anyone get paged?
• The agent acks a flapping check and mutes for 45 minutes. Error rate is climbing. Which alert still fires?
• The agent loops a "clear the queue" action. Lock contention and API usage explode. Do you see an actor problem, or only a mysterious load spike?

Those are the same instincts you already need for Is Your API Meter Predicting the Next Incident?. Apply them to the operator, not just the dependency.

Write down what the agent is not allowed to close. Acknowledgments that suppress escalation need a maximum age. Changes to infrastructure should require a human the first N times on a given runbook, service, and environment. If you cannot state those rules, you do not have an on-call policy for the agent. You have a hope.

Put the agent on the schedule, or do not give it the pager

We do not let a new hire join the rotation without a name, a phone, permissions, and a way to take them off. An operations agent needs the same bar: identity, an audit trail, bounded tools, and a human to page when it is wrong. Tink attributes every diagnostic and every approved fix; nothing runs on a server without permission you can later point to.

Ask one question in the Q4 demo: show me the agent in the incident timeline. If they cannot, keep the human on the pager. The page that never rings is the one that will cost you.