Frontier Investigation Agents: The Hard Part Was Never the Fix
The alert fires at 02:51. You open a laptop in the dark: dashboards, logs, deploy history, the cluster, the database. Each tab shows a symptom. None shows the cause.
An hour later you find it. A CPU request halved in a Helm values file made the autoscaler double the pods, and the pods drained the database's connections. The fix is one line. The hour went into understanding.
I watched team after team live that night when I was a Solutions Architect at AWS. Different stacks, same shape: the fix was short, the explanation was long. That's why we build Frontier Investigation Agents. They find the why. You approve the fix.
We automated the easy half
01Scripts
Run the command
Cron jobs and shell scripts took the typing out of known tasks.
02Config
Declare the state
Infrastructure as code made environments repeatable and reviewable.
03Runbooks
Encode the fix
Auto-remediation ran a known answer when a known condition fired.
04AIOps
Group the noise
Correlation turned twenty alerts into one incident.
05Investigation
Find the why
The step every layer above still hands to an engineer.
Scripts, infrastructure as code, runbooks, AIOps, observability. Each wave was real progress, and each automated execution or data. None automated the step in between: reading the evidence, forming explanations, testing them, deciding which is true.
That step stayed with a tired engineer at 3 a.m. Observability made it heavier, because there was more data to join by hand.
Why investigation resisted automation
Every earlier technique needed the answer in advance. A runbook is a diagnosis someone already made. A correlation rule is a hypothesis someone already had. They only recognize failures someone anticipated, and the failure that pages you at night is the one nobody did.
What's left is open-ended reasoning across unfamiliar evidence, where each step depends on what the last one found. Until recently, nothing could do that.
What changed
Frontier models can now read a trace, a metric, a Kubernetes event and a diff, and reason about how they connect. That's the "frontier" in the name.
But the model isn't the product. A frontier model knows the internet, not your system. The harness around it (access to your systems, how work is split, what it may touch, what it remembers) turns reasoning into an answer about your production.
We measured this. On SREGym, the same model, Claude Opus 5, closed 16 of 21 faults inside a general coding agent and 18 of 20 inside CloudThinker Resolve. Same weights, different harness, different outcome.
What a Frontier Investigation Agent is
A frontier AI model inside a harness built for one job: find the why behind a production issue, show the evidence, and propose the fix, while an engineer decides what changes.
01The agent
Finds the why
- Forms hypothesesSeveral explanations, held open at once
- Gathers evidenceRead-only, across code, cloud and telemetry
- Rules things outAnd records why
- Proposes the fixTied to the cause it named
Shows its work
02The engineer
Approves the fix
- Sets intentWhat matters, what may run on its own
- Reviews the verdictEvidence first, confidence second
- DecidesWhat changes in production
- Owns the outcomeAccountability stays with people
Keeps the judgment
The lines we hold
Investigation is read-only. An agent that can change the system can destroy its own evidence. Fixing is a separate step with separate rules.
The human approves the fix. Production changes carry accountability, and accountability belongs with people. Teams choose what may run on its own through Auto Mode, and that boundary moves only as fast as trust is earned.
"I don't know" is a valid answer. A confident wrong answer at 3 a.m. costs more than "not found". Confidence sits next to the evidence, never instead of it.
A fix names its target. A fix that makes the graph recover without explaining why is a gamble with a delay on it.
Memory can be wrong. Lessons need more than one incident behind them, and engineers can correct or remove anything the agent believes.
Access is the outer boundary. No agent does more than its connection allows. Secrets are masked before they reach a model. Every action leaves a record.
The evidence
Every vendor has a demo where the agent finds the answer. Here's how we measure it instead.
01Resolve
18 of 20 faults closed
SREGym, Claude Opus 5. The same model closes 16 of 21 inside a general coding agent.
02Review
30 of 37 bugs caught
Real production bugs from Cal.com, Sentry, Grafana and Keycloak. Faulty line plus impact, or it does not count.
03Cyber
38 confirmed findings
OWASP Juice Shop, black box, in 27 minutes for about $57. One run each, side by side with AWS Security Agent.
- Resolve on SREGym: 18 of 20 faults closed with Opus 5, 20 of 20 with GPT-6 Astra. Read the evaluation.
- Review on 37 real production bugs: 30 caught, faulty line plus impact. Read the benchmark.
- Cyber on OWASP Juice Shop: 38 confirmed vulnerabilities in 27 minutes for about $57, against AWS Security Agent's 23 in 5 hours 9 minutes. Read the comparison.
In production: F88 automated 80% of daily operations and cut AWS spend by 30%. FPT Cloud reached roughly 97% precision on live merge requests. Diaflow runs three regions at 99.9% uptime with 80% fewer operational tasks.
How it keeps getting better
It learns your environment. Resolve keeps lessons from past incidents. Review learns from the findings your team fixed. Cyber re-checks old findings on every scan. Each connection widens what the agent sees in one pass.
We benchmark every release. Every release and every new model runs the same fixed suites before it reaches customers, graded the same way, compared with the release before.
01Candidate
New release or model
A harness change, a prompt change or a new frontier model.
02Fixed suites
Same faults, same bar
SREGym for Resolve, real bugs for Review, Juice Shop for Cyber.
03Compare
Against the last release
Accuracy, coupling of diagnosis and fix, time and cost per result.
04Decide
Ship and publish
The numbers decide what ships, and the method goes out with them.
That's how we picked Resolve's default model, and how we know model choice alone moved its resolution rate from 40% to 100%. We publish the method with the numbers, including the parts that don't flatter us: self-run, single runs, not yet official leaderboard submissions.
What changes for engineers
On-call stops starting from a blank page. It starts from a finished investigation: a cause, the evidence, what was ruled out, and a fix waiting for review. The job moves from searching to judging.
Engineers get their time back. For creative work.
Try it on incidents you've already solved
Take three incidents from last month whose root causes you know. Compare the agent's verdicts with your postmortems. That afternoon will tell you more than any demo, including ours.
Start a trial or book a walkthrough.