Self-Maintaining Systems

Cheap, parallel agents exhaustively monitor a codebase and autonomously triage, reproduce, and fix issues — surfacing to a human only the alerts that mean something. Detection is exhaustive; notification is selective.

A self-maintaining system inverts the usual ownership of observability and QA. Instead of engineers watching dashboards and triaging alerts, an agent watches every signal, judges impact, fixes what it can, and files the rest for review. The economic premise: agents are cheap to run, infinitely patient, and trivially parallelized, which makes exhaustive monitoring feasible at production scale. Source: Ramp Labs, https://ramplabs.substack.com/p/self-maintaining, 2026-03-24

The Ramp Labs case

Ramp made Ramp Sheets (a ~10,000-user app) self-maintaining with roughly one AI-generated monitor for every 75 lines of code — over a thousand monitors, up from ten hand-written ones. The system runs on Ramp Inspect, an internal background coding agent where each session spins up a sandboxed dev environment so the agent can make real API calls, run tests, and reproduce bugs end-to-end against live code. No code merges without engineer review. Source: Ramp Labs, 2026-03-24

The design evolved through three stages, each fixing the prior stage's weakness:

1. Scheduled auditing. A nightly agent ran a QA pass — sanity-testing core features, stress-testing recent PRs, probing for latent bugs — and opened a PR when it found a real issue. It surfaced several real production bugs a day, but with no specific mission it always walked the same paths and could not catch narrow, situational bugs. It also could not synthesize a large codebase against a large telemetry surface to decide what deserved attention. Source: Ramp Labs, 2026-03-24
2. Monitor-driven maintenance. On PR merge, an agent reads the diff and generates monitors instrumenting the new code. When a monitor fires, a webhook starts a fresh agent with the alert context; it reproduces the issue in its sandbox, pushes a fix, and notifies on Slack. In its first week the system caught 40 real bugs, each within minutes of a user triggering it. Source: Ramp Labs, 2026-03-24
3. Triage to filter noise. Auto-generated monitors have bad thresholds, so routine activity triggered cascades of false positives and duplicate alerts. The fix was a triage step: on every alert the agent first assesses scope — real issue gets a fix plus a Slack post; noise gets the monitor tuned or deleted. To prevent duplicate alerts, the agent stores state on the monitor itself (appends the PR link to the monitor description); later agents see the link and stand down. Source: Ramp Labs, 2026-03-24

Principles

The lessons Ramp drew, framed as reusable principles: Source: Ramp Labs, 2026-03-24

• Detect everything, notify selectively. Watch every signal, but make each alert that reaches a human mean something. Teams ignore noisy monitors, and they will ignore noisy agents too.
• Delegate to the agent. Let it scope the problem, judge impact, make the change, and filter the noise. Models are good at this and improving.
• Sandboxed reproduction improves results. Reproduce the failure against live code and only push a fix once the reproduction test passes — proof the issue is real and the fix works.
• Model choice matters. Ramp found GPT-5-class models thorough debuggers, but Opus 4.6 a more accurate triage evaluator, specifically better at filtering noisy alerts. Split the roles.
• Tight observability breeds empathy. When every slow load or bad output fires a notification, the team feels the product the way users do, and catches bugs it never would have prioritized.
• Keep your existing stack. Auto-generated monitors are capable but opaque and not yet reliable enough to be the only line of defense. Keep the instrumentation you wrote and trust.

The detection-to-healing loop

Generalized, a self-maintaining system is a closed loop on top of a detection layer:

The hard parts are not detection — exhaustive detection is the easy, cheap half. The parts that decide whether humans trust the system are triage (is this real?), dedup state (have we already handled this?), verification (did the fix actually work?), and selective notification (does this alert deserve a human?). A system that detects everything but notifies indiscriminately is strictly worse than no system, because it trains its owners to ignore it.

How this wiki instantiates it

This wiki is a self-maintaining knowledge base, and it maps onto the same loop:

• Detection is the Doctor Pattern: scripts/doctor.ts runs five sub-doctors (wiki structure, skills, rules, automations, config sync), normalizes findings to a 0-100 score on unique rules (the Security and Review Skills methodology), and tracks the trend in wiki/meta/doctor-history.json. This is the "detect everything" half, already exhaustive (hundreds of info findings aggregated under a handful of rules).
• Scheduled auditing is the automations/ system — recurring agent tasks (code-bugfix, source-compile) that mirror Ramp's nightly QA agent.
• The closed loop is the self-heal automation (automations/self-heal.md) plus scripts/self-heal.ts. It adds the three pieces detection alone lacks: it triages each doctor finding (auto-safe / agent-fix / escalate / noise), stores per-finding state in wiki/meta/self-heal-state.json so handled findings stand down, auto-applies provably-safe deterministic fixes (regenerating the index/backlinks/discovery artifacts), verifies by re-running the doctor and confirming the score rose, and emits a selective digest instead of re-dumping every known finding.

The "sandboxed reproduction" analog for a knowledge base is re-running the doctor after a fix and confirming the specific finding cleared and the composite score did not regress — the doctor is the reproduction test. The "keep your existing stack" principle is why self-heal is built strictly on top of the doctor rather than replacing it. Source: compiled from Doctor Pattern + Ramp Labs, 2026-06-16

The orchestration layer is Automation Orchestration: detect, dedupe, persist per-finding state, run the fix, verify, write proof, and notify selectively. Without State Resumability and Proof-Carrying Work, a self-healing system becomes a noisy cron job that claims it fixed things.

Agent Company OS generalizes the same loop for agent organizations: work produces artifacts and traces; traces satisfy criteria; criteria update objective state; and accepted artifacts improve the memory/skill system. In this wiki, that means bookmark ingests, doctors, and skill maintenance should not end at an answer. They should update pages, routing, skills, tests, and logs. Source: X/@DerekNee image, 2026-06-25

Model choice and the human gate

Following Ramp's split, triage (which findings are real vs. noise) is the judgment-heavy step that benefits from a strong evaluator model, while the content fixes (resolving a broken wikilink, writing a stub) are debugging-style work. Either way, the human stays in the loop where it matters: destructive or irreversible actions (page merges, deletions, contested content) are never auto-applied — they escalate to Kevin, and additive fixes land behind a PR for review, the knowledge-base version of Ramp's "no code merged without engineer review." This is the Lint-Enforced Agent Guardrails hierarchy applied to maintenance: tooling catches drift, the agent proposes the fix, the human approves the irreversible ones.

Concept Position

---

Timeline

• 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Cheap, parallel agents exhaustively monitor a codebase and autonomously triage, reproduce, and fix issues — surfacing to a human only the a... Source: User request, 2026-07-01
• 2026-06-16 | Page created from Ramp Labs' "How we made Ramp Sheets self-maintaining." Mapped the detect-everything / notify-selectively / triage / stand-down / sandboxed-reproduction principles onto this wiki's Doctor Pattern detection layer, and motivated the self-heal loop (scripts/self-heal.ts + automations/self-heal.md) that closes detection into autonomous, verified, PR-backed healing. Source: Ramp Labs, https://ramplabs.substack.com/p/self-maintaining, 2026-03-24
• 2026-06-19 | Linked self-maintaining systems to Automation Orchestration, State Resumability, and Proof-Carrying Work so detection/repair loops have durable state and proof requirements. Source: whole-wiki concept review, 2026-06-19
• 2026-06-25 | Added Agent Company OS's proof loop as the organization-level version of self-maintenance: accepted artifacts update objectives and improve memory/skills. Source: X/@DerekNee, 2026-06-25