This graph has no done state — that is the point
Graph Engineering pattern 14 of 15: the Autonomous Operations Loop. Monitor→detect→diagnose→plan→execute→verify→monitor, a risk fork through a human, and the question every persistent system must answer: who monitors the monitor?
Every pattern so far in this series finishes. This one must not. Production systems drift — jobs fail, disks fill, certificates expire, regressions land — and the work of noticing and correcting is continuous, mostly routine, occasionally consequential. Modeling it as a task misdescribes it. It is a persistent feedback system.
Context for new readers: pattern 14 of 15 in the Graph Engineering series. One of the ten questions the discipline asks of every topology is "when is the work actually complete?" — and this is the pattern whose honest answer is never, by design.
The topology
Monitor -> Detect -> Diagnose -> Plan
^ |
| routine v
+----- Verify <----- Execute <-+
|
risky action -> Human --+
Monitor watches the signals. Detect turns signal into events worth attention, filtering noise. Diagnose identifies what an event means and why. Plan produces a corrective action — and here the graph forks on risk: routine actions (restart the job, expand the volume) flow straight to execute; risky actions — anything irreversible, data-touching, customer-visible — detour through a human approval edge. Verify confirms the action had its intended effect and no others, then hands control back to monitor.
Verify, or you built an amplifier
An unverified corrective loop can amplify a fault as efficiently as it corrects one. Verify checks global health, not just the local action's success — and repeated corrections of the same condition must trip an escalation, not a retry. Fix A triggering condition B whose fix re-triggers A is the classic oscillation, and only the verify step sees it.
The policy stays outside the loop
The routine/risky boundary is written policy the loop operates under and cannot edit. That is a governance statement disguised as a scheduling detail: the loop executes classifications; it does not make them.
Who monitors the monitor?
A dead operations loop looks exactly like a healthy quiet system. The loop needs an external liveness signal — a heartbeat a separate system or a human review watches. Every persistent structure in this series inherits this question; this pattern is just where it becomes unavoidable.
Where it breaks
- Oscillating corrections — see the amplifier point; escalate repeats.
- Risk classification drift — the boundary is policy, reviewed like policy.
- Silent loop death — no heartbeat, no organization noticing the silence.
The dimension answers
| Dimension | Answer |
|---|---|
| Nodes | Monitor, detect, diagnose, plan, execute, verify; human for risky actions |
| Edges | Closed loop with a risk-fork approval detour |
| Cycles | The whole pattern is one — deliberately unterminated |
| Humans | Approve risky actions; own the risk policy; watch the heartbeat |
| Exit rule | None by design — bounded per iteration, not terminated |
Where rysh fits
Persistent agents spend continuously, so metering is part of the pattern, not an accounting afterthought. In rysh, every agent's token spend is metered per pane, per named agent and — through the governance proxy — per customer, shown in the status bar and rolled up weekly.
Honest scope
- The operations loop is an organizational design; rysh ships the bounded-loop, policy and metering primitives it runs on.
- Metering is per pane / per named agent / per customer — there is no P&L dashboard, and budget enforcement is a cost control by documented design.
- rysh is open-core: the CLI is Apache-2.0, the server is proprietary. It runs on Claude, with your own key.
Next, the series finale: pattern 15, the AI-Native Organization Graph — where the human becomes a node.
Building this with design partners → rysh.ai/design-partner