Running in productionAI Agents

Incident Diagnosis and Approval

Read-only AI diagnosis during a production incident, with a human approving every action — because the fastest wrong fix is worse than a slower right one.

Runtime state: Running: the agent worker has completed more than 53,000 diagnostic runs across three agents. Production mutation still requires a human, and the read-only diagnosis path is what executes.

Business objective: Shorten the time from symptom to correct diagnosis without letting anything change production without human approval.
Trigger: A monitoring alert fires, or an operator reports a symptom.
Inputs: The alert or reported symptom
Metrics, queue state and recent deployment history
Runbooks and the catalog of known failure modes
The written invariants for the affected system
Outputs: A ranked set of hypotheses with supporting evidence
A proposed remediation for human review
An applied fix, once approved by a person
A post-incident artifact — an invariant, a check, or a runbook

The rule

Diagnosis is read-only. Mutation requires a human.

Not a guideline — a structural property. Diagnostic capabilities are registered without mutation rights, and the categories that could make an incident worse (deploy, migration, security-adjacent actions) are denied from automatic action by pattern rather than by case-by-case review.

An incident is exactly when an autonomous system is most likely to be wrong: the signal is unusual, the context is incomplete, and the pressure to act is highest.

The workflow

Alert to closed incident

One AI step. It is read-only, and everything after it is human-gated.

Monitoring / feedback
Alert fires
Deterministic monitoring detects. Not an agent.
Automated software
Context assembled
Metrics, queue state, recent deployments and flag changes, gathered read-only.
Data store
Runbooks and failure modes retrieved
Including the catalog of how this system actually breaks, which is mostly silently.
Automated software
Route to premium reasoning
Decision point: Production incidents get the strongest available model. This is the one task class where cost is not a consideration.
AI / LLM
Read-only diagnosis
Hypotheses ranked with the evidence for each, plus what would confirm or eliminate them. No mutation capability exists in this context.
Human action
Operator evaluates
Decision point: Which hypothesis fits? What evidence would settle it?
Automated software
Read-only verification
Queries and checks that confirm or eliminate, still without changing anything.
AI / LLM
Remediation drafted
A proposed change, with its risk and its reverse path stated.
Approval gate
Human approval
Decision point: A person approves, modifies or rejects. No production mutation happens without this step, regardless of confidence.
Human action
Apply the fix
Behavior changes go through a flag where possible, so the reverse path is a flag flip rather than a deploy.
Monitoring / feedback
Verify recovery
Against the documented expected state, not against the absence of alerts.
Human action
Produce the artifact
An invariant, a liveness check, or a runbook. A fix helps once; an artifact helps every time after.

Human action
Automated software
AI / LLM
Data store
Approval gate
Monitoring / feedback

Decision points

Is this a known failure mode? Check the catalog before reasoning from first principles.
Which hypothesis fits the evidence? Human, informed by the ranked set.
What confirms or eliminates it? Read-only verification before any change.
Approve, modify or reject the remediation? Human, always.
What artifact should exist so this is cheaper next time?

Responsibilities

AI / LLM

Ranking hypotheses against assembled evidence.
Explaining what a metric pattern implies.
Retrieving and summarizing the relevant runbook.
Drafting a remediation with its risk and reverse path.

Human and deterministic

Detection — monitoring, not agents.
All metrics and queue state.
Approving any change. Human, without exception.
Applying the change.
Post-fix verification against a documented expected state.
The deny patterns that keep deploy and migration actions manual.

Human approval points

Before any production mutation. The rule with no threshold.
Choosing which hypothesis to act on.
Deciding the incident is closed — against verified state, not silence.

Failure handling

Failure	Response
Diagnosis is confidently wrong	Read-only verification exists to catch this before anything changes. The cost is minutes, not an outage.
Model unavailable	Diagnosis proceeds manually from runbooks. Slower, never blocked.
Remediation makes it worse	Behavior changes ship behind flags, so the reverse path is a flag flip.
Symptom is a silent failure	The failure-mode catalog covers these specifically; checks look for movement, not for errors.
Root cause not found	Incident stays open with mitigation applied. An unexplained recovery is not a closed incident.

Monitoring

Time from alert to correct diagnosis, hypothesis accuracy, remediation rejection rate at the approval gate, recurrence rate per failure mode, and whether an artifact was produced. A recurring incident with no artifact means this workflow did not finish.

Business value

Most of this system's failures are silent, and most incident time goes on diagnosis rather than repair. Compressing diagnosis is where the recovery time actually is.

More workflow designs

Back to the library