Investigate mode vs repair mode: two speeds of AI in operations

The fastest way to lose an ops team’s trust is to blur “here is what we think happened” with “here is what we already changed.”

Yet many AI demos do exactly that: one button, one flow, production updated before anyone on-call has context.

Investigate mode: hypothesis ready

Investigate mode is for the messy middle of an incident or ticket:

• Alerts, metrics, tickets, and endpoint telemetry land in one workspace.
• The system proposes ranked hypotheses with linked evidence.
• Output is an RCA brief and recommended next steps, for humans to review, share, and act on.

Examples where investigate-only is the right default:

• Helpdesk triage on a vague “Outlook is slow” ticket.
• On-call parallel triage while PagerDuty is still paging.
• Security validation on a suspicious script before anyone talks about isolate.
• Discovery mapping during a partial regional outage.

In these flows, the win is speed to understanding, not speed to mutation.

Repair mode: awaiting approval

Repair mode is for when the team is ready to change something:

• Scale a pool, shed traffic, roll back a cert ring, pause an Intune rollout.
• Playbooks are drafted, risk-scored, and queued.
• Execution waits on a human sign-off.

This is where automation pays off, but only after the investigation trail exists. The approver should see the same evidence the triage engineer saw, not a black-box summary.

Why the boundary helps ML adoption

Machine learning in ops often fails for cultural reasons, not model reasons:

Fear	Investigate / repair split addresses it
“It will break prod.”	Investigate mode does not execute.
“We cannot audit it.”	Trails + explicit approval on repair.
“It hallucinates.”	Evidence rows; humans rank and reject.

Teams that start with investigate-only can validate value on real incidents without a change-management fire drill. Repair mode becomes a deliberate upgrade path once playbooks and approvals match your runbook culture.

Same stack, different outcomes

Whether you are SRE chasing an SLO burn, IT ops untangling a fleet rollout, or helpdesk structuring a tier-1 note, the underlying pattern is the same:

1. Ingest signals from tools you already use.
2. Correlate across time and dependencies.
3. Rank what is most likely.
4. Hand off a brief, or approve a fix.

Fixed.sh labels those steps explicitly in the workspace: signal map, timeline, confidence, and a callout that says whether you are looking at a ready hypothesis or a playbook waiting for approval.

Practical takeaway

If you are planning AI for your operations team, define two modes on paper before you buy or build:

• What must never run without a human?
• What does “ready” look like in the UI, RCA posted, playbook queued, risk labeled?

Get that right and the ML becomes a collaborator. Blur the modes and you get another tool engineers work around.