Ein Agentic Flywheel braucht explizite Evidenz- und Autoritätsgrenzen

Behauptung

Ein Agentic Flywheel kann Fehlerursachen nur so weit untersuchen, wie relevante Systemzustände, Ereignisse und Entscheidungen zugänglich und korrelierbar sind. Es kann Verbesserungen nur so weit selbst ausführen, wie ihm dafür ausdrücklich Rechte und sichere Werkzeuge bereitgestellt werden. Fehlende Evidenz darf nicht durch scheinbar sichere Schlussfolgerungen ersetzt werden; fehlende Autorität benötigt einen erklärbaren Eskalationsweg.

Mehr Zugriff ist dabei nicht automatisch besser. Breite Rechte können Diagnose und Reparatur erleichtern, vergrößern aber zugleich Schadensradius und Governance-Aufwand. Eine tragfähige Gestaltung unterscheidet deshalb:

• beobachtbare und direkt prüfbare Ursachen;
• indirekt erkennbare Symptome hinter einer Zugriffsgrenze;
• bekannte, reversible und erlaubte Maßnahmen;
• Änderungen, die lediglich vorgeschlagen und menschlich freigegeben werden;
• Fälle, die mit einem Evidenzpaket an andere Verantwortliche eskaliert werden.

Herkunft und Evidenzlage

Die These entstand aus dem konkreten Fall der Kubernetes-Feature-Testumgebungen. Der Namespace könnte die relevanten Logs weitgehend korrelieren, doch ihre Ermittlung und Zusammenstellung ist noch nicht implementiert. Auf einzelne Infrastrukturkomponenten wie Route 53 besitzt das Team keinen Zugriff, sodass bestimmte Ursachen nicht unmittelbar automatisiert geprüft werden können.

Morris begründet die Rolle des Menschen auf der Schleife, während Anthropic harte Zugriffsgrenzen zur Begrenzung des Schadensradius hervorhebt. Der Runbook-Fall von D’Antonio und Xie zeigt eine erklärbare Wissens- und Eskalationsschnittstelle. Keine dieser Quellen prüft jedoch die hier formulierte allgemeine These über Evidenz- und Autoritätsgrenzen eines Flywheels systematisch.

Konsequenz für den Testumgebungsfall

Ein deterministischer Evidence Collector könnte je Namespace eine zeitlich geordnete Diagnoseakte aus Kubernetes-Ereignissen, Workload-Zuständen, Logs, Metriken und Testergebnissen erzeugen. Bei nicht zugänglichen Komponenten sollte der Agent beobachtete Symptome, geprüfte Alternativen, fehlende Evidenz und den zuständigen Eskalationsweg ausweisen. Direkter Infrastrukturzugriff ist dafür nicht zwingend erforderlich; eine kuratierte Read-only-Schnittstelle oder ein von der verantwortlichen Plattform bereitgestelltes Diagnoseereignis kann die Grenze sicherer überbrücken.

Im konkreten Fall existiert ein Plattform-Team für Analysen nicht zugänglicher Infrastruktur. Neue maschinenlesbare Diagnosefunktionen können angefordert werden, ihr Umsetzungszeitpunkt ist jedoch ungewiss. Das Flywheel muss deshalb mit manuellen Eskalationen arbeitsfähig bleiben und deren Häufigkeit, Wartezeit und Kosten sichtbar machen. Diese Evidenz kann später die Priorisierung einer stabilen teamübergreifenden Schnittstelle begründen; die Schnittstelle sollte nicht ungeprüft zur Vorbedingung des gesamten Experiments werden.