Definition · DARV loop
What is the DARV loop?
DARV is the closed loop that agentic operations run on: Detect, Analyze, Remediate, Verify. Most automation stops at Remediate — it fires an action and hopes. The Verify step is what turns an open-loop script into a system you can trust in production.
Last updated
The short answer
The DARV loop is CloudThinker’s closed-loop model for autonomous cloud operations: Detect a problem in the signal, Analyze its root cause, Remediate through a scoped and reversible action, then Verify that the fix actually resolved the issue and had no side effects. The Verify step closes the loop — without it, automation is open-loop and unaccountable. DARV is the operational shape of AgenticOps, executed under team policy and tamper-evident audit.
What are the four steps of the DARV loop?
DARV is one continuous cycle, not a pipeline that ends. Detect finds the deviation, Analyze reasons about cause, Remediate takes a reversible action under policy, and Verify confirms the outcome — then the loop rearms. Each pass writes a tamper-evident receipt.
- Detect — The agent watches the signal layer — correlated alerts, metrics, logs, traces, drift — and identifies a deviation worth acting on. Detection inherits your existing observability and AIOps stack rather than replacing it.
- Analyze — The agent investigates root cause — walking the dependency graph, replaying prior incidents from memory, and correlating changes — instead of pattern-matching a symptom to a canned response.
- Remediate — The agent executes the matching runbook inside a sandbox with brokered, task-scoped credentials — a reversible, audited change gated by the team’s approval policy for that autonomy level.
- Verify — The agent confirms the fix actually resolved the problem and introduced no regressions — re-checking the original signal and adjacent blast radius. If verification fails, the loop escalates or rolls back rather than declaring victory.
Why is Verify the differentiator?
Open-loop automation ends at the action: it fires a remediation and assumes success. The DARV loop treats an unverified fix as an incomplete one. Verify is what makes autonomous action accountable — it produces evidence that the outcome matched intent, not just that a command ran.
A remediation that “ran successfully” is not the same as a problem that got fixed. Restarting a service returns exit code 0 while the underlying memory leak keeps climbing; scaling a node group succeeds while the real bottleneck is a downstream database. Without a Verify step, automation manufactures false confidence — the incident looks closed on the dashboard while the customer impact continues.
Verify closes that gap by re-observing the world after the action. It re-checks the signal that triggered Detect, watches the adjacent blast radius for regressions, and only then writes the receipt that the loop is complete. When verification fails, the loop does the honest thing: it rolls back the reversible change or escalates to an engineer, and it records why. That feedback is also what lets the platform learn which runbooks earn more autonomy over time.
How does the DARV loop relate to AgenticOps and graduated autonomy?
DARV is the operational shape of AgenticOps — the discipline of running production cloud operations through autonomous agents under team policy. Graduated autonomy (L1–L4) governs how much of each DARV pass the agent may complete on its own before a human on the loop signs off.
AgenticOps is the discipline; DARV is the loop that discipline runs. At lower autonomy levels the agent may Detect, Analyze, and propose a Remediate, but a human approves the action and reviews Verify. As a runbook earns trust, more of its DARV cycle runs unattended — until, at higher levels, the agent completes Detect → Analyze → Remediate → Verify autonomously within a defined guardrail and the engineer reviews outcomes rather than each step.
The guardrails that keep every DARV pass safe are the same ones AgenticOps requires: brokered per-task identity, credentials issued at task time and living in the sandbox rather than the prompt, deterministic data tokenization at egress, and tamper-evident audit. DARV without those controls is just an autonomous script with production access — the failure mode, not the model.
DARV loop vs open-loop automation vs OODA
The DARV loop is closed by design. Open-loop automation fires and forgets. OODA is a human decision cycle DARV borrows from but adapts for autonomous execution under policy.
| Dimension | Open-loop automation | OODA loop | DARV loop |
|---|---|---|---|
| Ends at | Action fired | Act (human judgement) | Verify (outcome confirmed) |
| Confirms the fix worked | No — assumes success | Via the next human observation | Yes — Verify is a required step |
| Executor | Script / trigger | Human operator | Agent under approval policy, human on the loop |
| On failure | Silent — false confidence | Re-enter loop manually | Auto rollback or escalate, audited |
| Accountability | Log line, if any | Human memory / notes | Tamper-evident receipt per pass |
How to adopt the DARV loop
You do not adopt DARV all at once. You close the loop one runbook at a time, and you graduate autonomy per runbook — never per team.
Step 1
Instrument Detect on your existing signal
Keep whatever is correlating your alerts today. Point the agent at that signal so Detect fires on the same incidents your team already trusts — no duplicate ingest layer.
Step 2
Encode Analyze and Remediate as a Skill
For a recurring incident, capture the team’s playbook as a Workspace Skill: the queries that establish root cause (Analyze) and the reversible action that fixes it (Remediate). Start with the three most-paged runbooks.
Step 3
Define Verify as an explicit success check
Write down what “fixed” means for that runbook — the signal that must return to baseline and the blast radius that must stay quiet. This check is what closes the loop and what promotes the Skill from proposal to autonomous.
Step 4
Graduate autonomy per runbook
New Skills start with a human approving Remediate and reviewing Verify. As each Skill’s DARV passes prove out, promote it up the L1–L4 ladder within a guardrail — the engineer moves from approving steps to reviewing outcomes.
Frequently asked questions
- What does DARV stand for?
- DARV stands for Detect, Analyze, Remediate, Verify — the four steps of CloudThinker’s closed-loop model for agentic cloud operations. Detect finds the problem, Analyze reasons about root cause, Remediate takes a reversible action under policy, and Verify confirms the fix actually worked before the loop closes.
- Why is Verify separate from Remediate?
- Because a remediation that ran is not the same as a problem that was fixed. A command can succeed while the underlying issue persists or a regression appears elsewhere. Verify re-observes the world after the action, confirms the original signal recovered, and checks the blast radius — turning an open-loop action into an accountable, closed loop.
- How is the DARV loop different from the OODA loop?
- OODA (Observe, Orient, Decide, Act) is a human decision cycle. DARV adapts that closed-loop thinking for autonomous execution: it adds an explicit Verify step, runs under a team approval policy with brokered credentials and tamper-evident audit, and is executed by an agent with a human on the loop rather than by a person in the moment.
- How does the DARV loop relate to AgenticOps?
- AgenticOps is the discipline of running production cloud operations through autonomous agents under team policy; the DARV loop is the operational shape that discipline takes. Every AgenticOps action is one pass of Detect → Analyze → Remediate → Verify, governed by graduated autonomy (L1–L4) and the platform’s brokered credentials, sandboxed execution, tokenization, and audit.
- What happens when the Verify step fails?
- The loop does not declare success. Because Remediate uses a reversible, sandboxed action, a failed Verify either rolls the change back or escalates to an engineer, and it records why in a tamper-evident receipt. That feedback also informs which runbooks earn more autonomy over time.
Put DARV loop into operation safely
CloudThinker turns the concept into a governed AgenticOps workflow: grounded in your stack, controlled by your policy, and verified after every action.