The Loop Every Module Runs: Detect, Analyze, Resolve, Validate
A service goes down. Someone restarts it, the graph turns green, and the incident closes. The postmortem names a cause. Nobody checks whether that cause was the real one, because the service is up and there's a queue of other work.
We saw this in our own benchmark. On SREGym, one model restored service in six runs while its write-up named the wrong component. A scoreboard that only checks "is it working again" counts those as wins. A person reading that postmortem learns the wrong lesson.
That gap is why the last stage of our loop is its own stage. This post covers the loop behind every Frontier Investigation Agent we ship, and how it looks in each of the four modules.
The loop
01Detect
Pick up the signal
Metrics, cost data, pull requests and alerts from your connections.
02Analyze
Form a plan
Check the signal against topology, history and team knowledge.
03Resolve
Act under policy
The plan runs under Manual or Auto, with approvals on sensitive actions.
04Validate
Check the outcome
Confirm what actually happened and write the result back to memory.
Detect. Agents pick up signals from your connections: metrics, cost data, pull requests, alerts.
Analyze. They check each signal against topology, history and team knowledge to form a plan.
Resolve. The plan runs under the workspace's autonomy mode, Manual or Auto, with approvals gating sensitive actions. See Auto Mode.
Validate. The agent checks the outcome and writes the result back into memory, so the next run starts further ahead.
Engineers stay on the loop rather than in every step. They set intent, choose the autonomy mode, and approve the fixes that need judgment.
Why most automation stops at Resolve
A runbook or an auto-remediation script ends when its last command exits zero. Exit zero means the command ran. It doesn't mean the problem is gone, and it says nothing about whether the diagnosis behind it was right.
Diagnosis and fix are separate skills. In our SREGym evaluation, grading had two parts: a judge checked whether the agent named the faulty component, and an oracle checked whether the application actually worked again. A run only counted end to end when both passed on the same fault.
That's the shape we wanted in the product. Validate asks the second question after Resolve answers the first: did the change produce the result the diagnosis predicted? When it didn't, that's information, and the loop should keep it.
One loop, four kinds of signal
Resolve, Review, Optimize and Cyber run on the same harness and share one memory. The loop is the same. The signal is different.
01Resolve
Incidents
- DetectPulse suppresses noise and routes Incidents
- AnalyzeThree-phase RCA with read-only subagents
- ResolveA matching runbook becomes a Scoped Action
- ValidateOne follow-up check, then incident memory
02Review
Pull requests
- DetectA pull request opens on a connected repo
- AnalyzeDiff, linked ticket and docs as context
- ResolveInline findings with a suggested fix
- ValidateThe next review checks the pushed fix
03Optimize
Cloud spend
- DetectBilling evidence from one cloud connection
- AnalyzeRead-only checks of every billed service
- ResolveRanked findings your team works
- ValidateVerified, Inferred or Assumed on each finding
04Cyber
App security
- DetectA scan maps the reachable surface
- AnalyzeTests inside your scope and intensity
- ResolveFindings with a replayable proof
- ValidateThe next scan re-tests old findings
Resolve handles incidents. Pulse is the Detect stage: it takes in raw events, suppresses known noise through eight layers, groups survivors into Clusters, and routes actionable ones into Incidents. Analyze is a three-phase root-cause analysis, covered in Inside an Investigation. Resolve is a Scoped Action: a matching, enabled runbook whose commands policy allows, holds for approval, or denies. Validate is a follow-up check and incident memory.
Review handles pull requests. Opening one on a connected repository is the signal. The review reads the diff, any linked Jira ticket and relevant Confluence docs, then runs security, quality and cloud-infrastructure checks in parallel. Findings land as inline comments with a suggested fix. When you push a fix, the next review verifies it, and resolved findings feed the Learnings that later reviews apply.
Optimize handles cloud spend. It reads billing evidence from one AWS, Google Cloud or Azure connection, and an agent checks every billed service with read-only cloud commands. The output is a ranked board of findings your team works.
Cyber handles application security. A scan maps the reachable surface and tests inside the scope and intensity you set. Each confirmed finding carries a proof you can replay. The next scan re-tests old findings and confirms fixes without being asked.
What Validate looks like in Resolve
Resolve is where the stage is most explicit, so it's worth walking through.
When a runbook includes a verification command, CloudThinker can schedule one follow-up check after the action and record the outcome on the incident-memory entry it wrote.
01Verified
The check passed
A follow-up check confirmed the expected result.
02Unverified
No answer yet
No conclusive follow-up result is recorded.
03Failed
Counter-evidence
The expected result did not hold, so the entry warns instead of guides.
The Failed outcome is the one we care about. A fix that didn't hold is never presented to a later investigation as valid guidance. It stays as counter-evidence, so the next RCA doesn't repeat the same assumption. More on that in Memory That Can Be Wrong.
An investigation also has two outcomes that only Validate can produce. Resolved means remediation was verified with a person in the loop. Auto-resolved means the agent verified it with nobody in the loop. Neither is the same as "the command ran".
Design decisions
Validate writes to memory as well as to a status field. A green check on one incident helps nobody next month. A recorded outcome, tied to the evidence and the action, does.
One follow-up check, not a monitoring loop. Resolve schedules a single check when a runbook gives it a verification command. It doesn't run a universal post-remediation process for every incident. We'd rather be clear about that than imply coverage we don't have.
Recall enters at Analyze. Lessons from past incidents come back at the start of a later root-cause analysis. Pulse never reads raw incident-memory files when classifying events, so a past lesson can't quietly suppress a new alert.
The next run is the validator. In Review and Cyber, validation is the next pass over the same code or app. That's cheap, and it doesn't depend on anyone remembering to ask.
Honest limits
Not every signal reaches every stage. The Resolve docs say so plainly, and we repeat it here:
- An investigation can end without a root cause. Not found is a valid outcome.
- A runbook may not match, so there's no Scoped Action to run.
- Post-fix verification in Resolve depends on the runbook having a verification command and on the agent writing a follow-up. Without one, the memory entry stays Unverified.
- With On Duty off, Pulse still detects and files Incidents, but analysis waits for a person to click Investigate.
- Optimize closes the loop least today. Each finding says whether it's Verified (the agent read the live resource), Inferred or Assumed, but moving a finding to Implemented is your team's call.
Try it
Pick a module you already run, and ask what the last stage told you:
"Show me the incidents from the last two weeks where the fix was applied, and which of them have a verified outcome."
"Which Review findings on this repository were fixed and confirmed by a later review?"
"For the last Cyber scan on this app, which findings were re-tested and confirmed fixed?"