Den Kreislauf bei Metriken schließen

Während jede frühere Stufe eine Person benötigt, um sie zu starten, verschiebt Stage 6 den Fokus auf das autonome Ausführen von Claude, um den Kreislauf zu schließen. Zum Beispiel könnte ein kontinuierlich laufender Monitoring-Agent, ausgehend von einem erstellten Bug-Ticket, eine intent.md erstellen und durch die Phasen Anforderungen, Plan, Build, Test und Review fließen. Stage 6: Maintain läuft headless, mit einem unabhängigen Confidence-Gate zwischen den Stufen, einer deterministischen Prüfung oder einem adversarialen Review-Agenten, der entscheidet, ob die Ausgabe der vorherigen Stufe fortgesetzt oder an einen Menschen eskaliert wird.

Was sich ändert

Ein deterministisches Skript überwacht die Produktion und ruft Claude auf, wenn ein Kontrollband verletzt wird. Die Überwachung einer Verletzung ist ein hilfreiches Beispiel für das Muster des autonom laufenden Kreislaufs, während der Abschnitt zu Claude Tag (öffentliche Beta) am Ende der Stufe Arbeit behandelt, die über verschiedene Kanäle eintrifft.

Was ein Kontrollband ist

Ein Kontrollband ist ein Bereich um das normale Niveau einer Metrik, wobei das Erkennungsskript den Mittelwert der letzten 30 Tage stündlicher Messwerte zugrunde legt. Das Skript berechnet außerdem Sigma (σ), die Standardabweichung, also wie weit Messwerte üblicherweise vom Mittelwert abweichen. Das 1σ-Band endet beim Mittelwert plus einem σ, das 2σ-Band beim Mittelwert plus zwei, und so weiter.

Wenn die Messwerte einer stabilen Metrik einer Glockenkurve folgen, liegt etwa einer von sechs über 1σ, einer von 44 über 2σ und einer von 740 über 3σ. Bei 720 Messwerten im Monat sorgt der Zufall allein für etwa vier pro Tag über 1σ, 16 pro Monat über 2σ und einen pro Monat über 3σ. Deshalb protokolliert die 1σ-Stufe nur, und deshalb wird selbst die 3σ-Stufe, die allein durch Rauschen etwa einmal im Monat ausgelöst würde, auf abgesicherte Routen beschränkt.

Die Western-Electric-Regeln aus einem Qualitätskontrollhandbuch von 1956 erfassen eine langsame Drift, die 3σ möglicherweise nie überschreitet. Sie markieren vier der letzten fünf Messwerte über 1σ oder acht in Folge über dem Mittelwert.

Erste Schritte

• Voraussetzungen: intent.md, die dem Kreislauf eine strukturierte Ausgabe zum Neustart gibt. Claude-beschleunigte PR-Reviews, Hooks als Aktionsgrenze und ein Rollback-Pfad für CI/CD (den die höchste Autonomiestufe aufruft).
• Infrastruktur: Ein Metrikspeicher, den das Erkennungsskript abfragen kann (Prometheus, die API des CI-Systems oder Äquivalente), Lesezugriff auf das Repository, eine Möglichkeit, Claude Code nicht-interaktiv in CI auszuführen, oder das Agent SDK für einen Dienst, der Webhooks empfängt.

So führst du es aus

1. Der Service-Owner oder Platform-Engineer wählt eine Metrik mit einer stabilen rollierenden Baseline aus, etwa die CI-Testfehlerrate, die 5xx-Rate nach dem Deployment oder die PR-Zykluszeit.
2. Sie schreiben das Erkennungsskript, typischerweise Mittelwert und Standardabweichung über ein rollierendes Fenster mit Regeln (Western Electric oder ähnlich), damit die Bänder sowohl langsame Drift als auch Spitzen erfassen. Das Skript wird versioniert und mit Unit-Tests abgedeckt, und die Erkennung bleibt vollständig deterministisch, ohne dass ein Modell beteiligt ist.
3. Die Reaktionsstufen werden in einer versionierten Konfiguration definiert (bands.yaml unten). Bei 1σ protokolliert das Skript nur, bei 2σ ruft es Claude nur lesend zur Diagnose auf, und bei 3σ darf Claude handeln, jedoch nur durch das Öffnen eines PR in das Review-Gate oder das Auslösen eines vorab genehmigten Runbooks. Eine Drift-Regel zählt als 2σ.
4. Die Trigger-Ebene kann ein geplanter Workflow in GitHub oder GitLab, ein Webhook aus dem bestehenden Monitoring-Stack oder ein Cron-Job innerhalb des Netzwerks sein. Claude läuft zustandslos, entweder als nicht-interaktiver Schritt auf einem CI-Runner oder als Agent-SDK-Dienst in einem sandboxed Container, und das CI/CD-Play behandelt die Deployment- und Modellzugriffsoptionen. Da der Lauf zustandslos und nicht-interaktiv ist, kann ein Kreislauf beginnen und enden, ohne dass ihn jemand gestartet hat.
5. Der Agent schreibt seine Diagnose als intent.md im Format von Stage 1: Plan, die die Anomalie und ihre Belege, ein vorgeschlagenes Ergebnis, die betroffenen Systeme und etwaige offene Fragen abdeckt. Von dort durchläuft der Befund die Pipeline wie alles andere.
6. Der Service-Owner oder der On-Call-Engineer triagiert die Warteschlange und leitet produktbezogene Befunde an den Product Owner weiter. Sofort beheben, einplanen oder verwerfen. Verwerfungen justieren die Bänder und helfen, Rauschen zu reduzieren.
7. Wenn ein Fix ausgeliefert wird, füge einen Eval für den Vorfall hinzu (das Continuous-Evals-Play), um sicherzustellen, dass solche Probleme künftig abgesichert sind.

So sieht es aus

Zum Beispiel eine bands.yaml, die die CI-Testfehlerrate überwacht:

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

Der Rest dieses Beispiels wendet dieselbe Datei auf eine Produktionsmetrik an, und nur die erste Zeile ändert sich zu metric: status_5xx_rate. Diese Metrik ist die Rate der 5xx-Fehler am Claim-Status-Endpunkt eines Versicherers.

Der geplante Job, der das Skript jede Stunde ausführt, schlägt die ausgegebene Stufe in bands.yaml nach und startet Claude mit den Tools oder Routen dieser Stufe. Für die Stufe propose bedeutet das eine Allowlist mit gh pr create und dem einen Befehl, der das Runbook auslöst.

Kunden sehen den Anspruchsstatus in einem Panel im Portal, und das Panel cacht jede Antwort für 60 Sekunden. Angenommen, ein Release um 13:52 Uhr setzt diesen Cache auf null.

Jeder Seitenaufruf erreicht nun claims-core, das ältere System hinter dem Endpunkt. Es erlaubt 50 Anfragen pro Sekunde und beginnt, sie abzulehnen. Um 14:00 Uhr gibt das Skript aus:

{"tier": "3sigma", "rule": "reading above 3 sigma", "reading": 1.9, "mean": 0.2, "sigma": 0.02}

Die 3σ-Stufe entspricht propose, was den Agenten auf die beiden aufgeführten Routen beschränkt. Minuten vor der Verletzung wurde ein Release ausgerollt, daher führt der Agent das Runbook rollback-deploy aus, das vorab genehmigt wurde. Anschließend schreibt er seine Erkenntnisse als intent.md, im selben Format, das eine Person in Stage 1 verwenden würde:

# Intent: status endpoint 5xx after release 4f2c9e1
Author: monitoring agent (status_5xx_rate, 3 sigma). Status: draft.
## Problem
The 5xx rate on GET /claims/{id}/status read 1.9% at 14:00. The 30-day mean is 0.2%.
Release 4f2c9e1 went out at 13:52. It changes CACHE_SECONDS in StatusPanel.tsx from 60 to 0.
With no cache, every page view reaches claims-core, which allows 50 requests a second (CLAUDE.md).
## Proposed outcome
Customers get fresher status without the portal passing the claims-core limit.
## Affected users and systems
Portal customers, claims-api, claims-core API.
## Constraints
The panel's spec.md allows status to be up to 60 seconds old (R4). The claims-core limit is fixed.
## Action already taken
Ran the rollback-deploy runbook at 14:02. It reported version 8c41d07 live again at 14:04.
## Open questions
Who asked for live status, and is 60 seconds too slow for them?

Wenn der Fix ausgeliefert wird, hinterlässt der Vorfall einen Eval, wie in Schritt 7 oben. Der Eval gibt dem Agenten die Anfrage, die zu dem Vorfall führte, und schlägt fehl, wenn der Cache fehlt. Darin ist from der Commit, von dem ein Lauf ausgeht, und may_change listet die Ordner auf, die er berühren darf:

{
  "name": "status-panel-keeps-its-cache",
  "source": "Incident: status endpoint 5xx after release 4f2c9e1",
  "from": "4f2c9e1~1",
  "prompt": "Customers say the claim status panel feels stale. Make it feel live. Run the tests before you finish.",
  "may_change": ["claims-api/routes", "claims-api/tests", "portal/src"],
  "checks": [
    { "name": "tests pass", "run": "make test" },
    { "name": "lint clean", "run": "make lint" },
    { "name": "panel still caches", "run": "grep -Eq 'CACHE_SECONDS = [1-9]' portal/src/claims/StatusPanel.tsx" }
  ]
}

Governance-Überlegungen

Die Stufengrenzen werden aus einer versionierten Konfiguration erzwungen, wobei Berechtigungen und verwaltete Einstellungen den Produktionszugriff verweigern. Aufrufe, Befunde und Triage-Entscheidungen werden mit einem Zeitstempel protokolliert. Ein Service-Owner triagiert und genehmigt Befunde, daraus resultierende Änderungen durchlaufen das normale PR-Review-Gate, und die Runbooks, die der Agent auslösen darf, wurden vorab genehmigt.

So misst du es

• Frühindikator: Zeit von der Bandverletzung bis zu einer intent.md in der Triage-Warteschlange, im Vergleich zur alten Zeit von Vorfall bis Post-Mortem-Maßnahme. Das Log des Erkennungsskripts enthält den Zeitstempel der Verletzung und die Stufe des Vorfalls.
• Spätindikator: Der Anteil der Befunde, die zu gemergten Fixes werden (Triage-Warteschlange gegenüber der tatsächlichen PR-Historie), sowie wiederkehrende Vorfälle derselben Klasse, die sinken sollten, da die Fixes Fälle zur Eval-Suite hinzufügen.

Beispiele

• Wenn die CI-Testfehlerrate 3σ verletzt, isoliert der Agent den instabilen Test (flaky test) oder öffnet einen Revert-PR, und das Review-Gate entscheidet.
• Wenn die 5xx-Rate nach dem Deployment 3σ verletzt und ein Deployment im Zeitfenster liegt, löst der Agent die bestehende Rollback-Pipeline aus.
• Wenn die PR-Zykluszeit eine Drift-Regel auslöst, schreibt der Agent einen Bericht für die Engineering-Leitung, was zeigt, dass der Mechanismus sowohl für Prozess- als auch für Produktionsmetriken funktioniert.

Claude im Bereitschaftsdienst mit Claude Tag

Vorfälle können auch über andere Wege eintreffen, etwa über Apps für die Arbeitskommunikation wie Slack oder Microsoft Teams. Ein Vorfall kann wie eine Slack-Nachricht um 22 Uhr aussehen, die einen dringenden Fix in einem Incident-Channel fordert, und kann nun sofort bearbeitet werden. Claude Tag (öffentliche Beta, derzeit in Slack verfügbar) macht Claude unter seiner eigenen Identität zu einem Mitglied dieser Kanäle, sodass jeder neue Vorfall einen Erstbearbeiter (First Responder) erhält und die Reaktion selbst Teil des Kreislaufs und des Gedächtnisses für künftige Vorfälle wird.

Die Konversation und das institutionelle Wissen bleiben im Kanal, wobei jeder im Kanal die Reaktion steuern und ausführen kann. Jedes Teammitglied kann Hypothesen testen, neue Optionen erkunden und in Echtzeit untersuchen, wobei der Kanalverlauf zur Nachvollziehbarkeit beiträgt. Durch den Zugriff auf MCP überprüft Claude, dass die Metrik wieder auf dem Ausgangswert liegt, bestätigt dies im Thread und schreibt das Post-Mortem in eine versionierte Lessons-Datei, die künftige Untersuchungen lesen können.

Vorfälle sind nicht die einzige Arbeit, die Claude Tag übernimmt. Wird Claude über MCP auf einem Ticket markiert oder im Kanal gefragt, triagiert es die Arbeit auf dieselbe Weise. Ein kleiner, klar begrenzter Fix kommt als PR durch das Review-Gate, und alles Größere wird als intent.md für Stage 1: Plan verfasst, an diesem Punkt beginnt der Kreislauf, sich selbst zu nähren.