Human-in-the-Loop-Theater
Die falsche Debatte, die immer wieder geführt wird: vollständige Automatisierung versus vollständige manuelle Kontrolle.
Hochleistungsfähige Teams tun keines von beidem. Sie automatisieren die deterministische Ausführung und reservieren menschliche Entscheidungen für Risikogrenzen, wo das Urteilsvermögen das Ergebnis wesentlich verändert.
Die Frage ist nicht „sollten Menschen involviert sein?“. Sondern „wo verbessert ein Mensch tatsächlich die Entscheidung?“
Menschliche Überprüfung schafft echten Mehrwert, wenn:
- Es einen mehrdeutigen Risikoabwägung gibt
- Eine Richtlinienausnahme behandelt wird
- Ein teamübergreifender Prioritätskonflikt gelöst werden muss
- Ein kundenrelevanter Vorfall im Kontext steht
Sie schafft keinen Mehrwert für repetitive, deterministische Prüfungen, die bereits explizite Pass/Fail-Kriterien haben. Dort um Genehmigungen zu bitten, erhöht nicht die Sicherheit – es erhöht die Wartezeit.
Definieren Sie Genehmigungsgrenzen als Architektur-Entscheidungen, nicht als Gewohnheiten. Produktionsfreigabe, Überschreibungen von Sicherheitskontrollen, temporäre Richtlinienausnahmen, Umgehungen von Notfall-Rollbacks – das sind die echten Grenzen. Alles andere sollte workflow-gesteuert sein.
In den Jahren 2025 und 2026 gehört eine weitere Grenze auf diese Liste: Änderungen des Upstream-Vertrauens.
Wenn ein Workflow eine neue Drittanbieter-Aktion einführt, eine Aktion von der Festlegung auf einen Commit-SHA zurück zu einem veränderbaren Tag ändert, den Umfang des Runner-Tokens erweitert oder einen neuen geheimnistragenden Ausführungspfad öffnet, ist das keine routinemäßige Anpassung. Das ist ein Governance-Ereignis. Behandeln Sie es auch so.
Drei Governance-Zustände:
- Pass: alle erforderlichen automatisierten Gates erfolgreich durchlaufen
- Block: erforderliches Gate fehlgeschlagen oder schwerwiegender Richtlinienverstoß
- Eskalieren: unzureichende automatisierte Beweise; menschliche Entscheidung erforderlich
Wenn eine Eskalation erforderlich ist, muss die Übergabe kompakt sein: was fehlgeschlagen ist, welche Gates betroffen sind, Links zu Beweismitteln, operatives Risiko, empfohlene Optionen. Keine Log-Dumps. Prüfer benötigen Entscheidungsunterstützung, keine Archäologie.
Das Warnzeichen, dass etwas nicht stimmt: Schatten-Governance. Ingenieure sagen „wir haben eine mündliche Genehmigung erhalten“ ohne Artefakt. Manuelle Wiederholung von Entscheidungen, die nicht in den Workflow-Aufzeichnungen widergespiegelt werden. Entscheidungskriterien unterscheiden sich zwischen Teams. Wenn dies geschieht, ist Ihr Governance-Modell nicht stark genug kodiert.
Springen Sie nicht von manuellen Operationen zur vollständigen Autonomie. Bauen Sie Vertrauen durch Beweise auf:
- Beobachtungsmodus – Workflow empfiehlt, Menschen entscheiden.
- Assistierter Modus – Workflow führt risikoarme Gates automatisch aus, Menschen genehmigen an den Grenzen.
- Gesteuerte Autonomie – Workflow handhabt die meisten Pfade, eskaliert definierte Ausnahmen.
Die jüngsten Supply-Chain-Vorfälle machen diesen Fortschritt noch wichtiger. Teams, die direkt zu „die Automatisierung weiß, was zu tun ist“ übergehen, entdecken meist zu spät, dass die Automatisierung auch bereitwillig vergiftete Abhängigkeiten, von Angreifern kontrollierte Tags oder kompromittierte Maintainer-Releases ausführt, wenn niemand die Vertrauensgrenze im Quellcode kodiert hat.
Was wir bei Kolsetu entwickelt haben: Governance ist einkompiliert, nicht durch Konvention erzwungen. allow_default_branch=false lässt den Lauf hart fehlschlagen, wenn jemand die Orchestrierung von main oder master auslöst – keine Ausnahmen, keine mündlichen Überschreibungen. Jedes Gate löst sich in einen von drei expliziten Zuständen auf: passed, skipped-by-input oder failed. strict_full_plan=true lässt den Lauf hart fehlschlagen, wenn ein definiertes Gate sich nicht in einen expliziten Zustand auflöst – keine stillen Durchläufe. Die Eskalation beinhaltet immer ein strukturiertes Paket: was fehlgeschlagen ist, welche Gates betroffen sind, Links zu Beweismitteln, empfohlene Optionen. Das Paket ist nicht verhandelbar, denn ohne es wird die Eskalation zu einem Feueralarm ohne Adresse.
Observability für einen einzelnen Job
Agentische Workflows werden oft als „intelligentere Automatisierung“ eingeführt.
Operativ verhalten sie sich wie verteilte Systeme – mehrere Stufen, asynchrone Abhängigkeiten, Teilausfälle, Wiederholungsversuche, Timeouts, menschliche Übergaben.
Wenn Ihr Observability-Modell einen einzelnen linearen Job annimmt, wird die Incident-Bearbeitung langsam sein. Und wenn Sie die Gates 8–11 aus Teil 2 (Sprachabdeckung, Systemmetriken, Datensatzintegrität, Log-Hygiene) erstellt haben, haben Sie bereits genau diese Art von Abhängigkeit mit verteiltem Zustand geschaffen. Sprachabdeckungs-Evaluierungen umfassen beispielsweise mehrere Aufrufe, mehrere Sprachen, Kontext auf Session-Ebene. Es gibt keine einzelne Log-Zeile, die Ihnen sagt, dass es bestanden wurde.
Beobachten Sie vier Schichten:
- Orchestrierungsschicht – Dispatch-Ereignisse, Gate-Übergänge, Timing
- Worker-Ausführungsschicht – individuelle Gate-Läufe, verwendete Eingaben, erzeugte Ausgaben
- Ausgabe-/Mutationsschicht – was sich tatsächlich wann geändert hat
- Governance-Entscheidungsschicht – Pass/Block/Eskalationsentscheidungen und deren Beweise
Erfassen Sie für jeden Lauf: Lauf-Identität und Korrelations-IDs, Gate-Übergänge mit Zeitstempeln, Dispatch- und Abschlussereignisse, Artefakt-Referenzen und Hashes, durchgeführte Ausgabeoperationen, endgültigen Entscheidungszustand und Grund.
Und für jeden Workflow, der Geheimnisse, Builds, Pakete oder Bereitstellungspfade berühren kann, erfassen Sie auch die Vertrauensnachweise: welche Aktions-SHAs tatsächlich ausgeführt wurden, welche Paketversionen aufgelöst wurden, welche ausgehenden Hosts kontaktiert wurden, welche Token-Scopes verwendet wurden und ob der Lauf eine Genehmigungsgrenze überschritten hat.
Ohne dies sind Wiederholungsversuche blind und Audits teuer.
Bauen Sie für die Wiederholung (Replay), nicht nur für den Wiederholungsversuch (Retry).
Ein Wiederholungsversuch ist nützlich, wenn ein vorübergehender Fehler wahrscheinlich ist. Eine Wiederholung (Replay) ist unerlässlich, wenn Sie Vertrauen in die Kausalanalyse benötigen – das erneute Ausführen eines Segments mit denselben Eingaben, Einschränkungen und dem gleichen Richtlinienkontext, um zu verstehen, warum etwas fehlgeschlagen ist, nicht nur, dass es fehlgeschlagen ist.
„Es funktioniert jetzt, unbekannt warum“ ist kein akzeptabler Wiederherstellungszustand.
Klassifizieren Sie Fehler konsistent: Eingabefehler, Richtlinienfehler, Abhängigkeitsfehler, Logikfehler, Ausgabefehler. Diese Klassifizierung gehört in Ihre Zusammenfassungen und Warnmeldungen.
Dieser Eimer für Abhängigkeitsfehler ist nicht mehr theoretisch. Er deckt nun genau die Szenarien ab, an denen sich Teams immer wieder die Finger verbrennen: ein kompromittierter Aktions-Tag, ein vergiftetes Release-Artefakt, verdächtiger Runner-Speicherzugriff oder unerwarteter ausgehender Traffic während eines Build-Schritts, der „normalerweise nur Tools installiert“.
Warnmeldungen sollten in unter einer Minute umsetzbar sein: Gate-Name, Fehlerklasse, Korrelations-ID, direkter Lauf-Link, vorgeschlagene erste Aktion und jedes anormale Vertrauenssignal (neues Netzwerkziel, nicht fixierte Abhängigkeit, Änderung des Token-Umfangs oder unerwarteter Ausführungspfad). Wenn eine Warnmeldung einem Ingenieur nicht hilft, den ersten Schritt in unter 60 Sekunden zu unternehmen, ist sie unvollständig.
Fragen Sie nach jedem bedeutsamen Vorfall: War dies durch Quellregeln vermeidbar? Wurde der Fehler im richtigen Stadium aufgedeckt? Welches einzelne Instrumentierungsfeld hätte die Diagnose verkürzt? Kodifizieren Sie die Antwort im Quellcode und in Tests. Nicht im Gedächtnis.
Was wir bei Kolsetu entwickelt haben: Jedes Gate in der Pre-Merge-Zusammenfassung enthält Workflow-Namen, Lauf-ID, Lauf-URL und Status. Gate-Fallback-Eingaben werden protokolliert, damit Prüfer sehen, was die Orchestrierung tatsächlich verwendet hat, nicht nur, was übergeben wurde. Wenn eine Wiederholung (Replay) erforderlich ist, sind exakte Eingaben, Einschränkungen und die Gate-Ausführungsreihenfolge zur Kompilierzeit im Quell-.md festgelegt – nicht aus dem Gedächtnis rekonstruiert. Der Fehlermodus ist explizit: „Sofort bei erstem schwerwiegenden Fehler anhalten und einen prägnanten Fehlerbericht mit Lauf-URLs und nächster Aktion erstellen.“
Operativ ist die Lehre aus der letzten Welle von Supply-Chain-Kompromittierungen einfach: Wenn Sie nicht schnell beantworten können „welcher genaue Upstream-Code ausgeführt wurde, mit welchen Berechtigungen und womit hat er versucht zu kommunizieren?“, dann ist Ihre Observability nicht bereit für die Produktionsautomatisierung.
Aktivität statt Ergebnisse messen
Die meisten Teams messen die falschen Dinge:
- Anzahl der erstellten Workflows
- Anzahl der Agentenläufe
- Reduzierung manueller Kommentare
Dies sind Aktivitätsmetriken. Die eigentliche Frage ist, ob die Liefergeschwindigkeit verbessert wurde, während Qualität und Kontrolle erhalten blieben.
Dreischichtiges Metrikmodell:
Schicht 1 – Lieferleistung:
- Merge-Lead-Time
- Zeit von PR-Bereitschaft bis zur endgültigen Entscheidung
- Wartezeit an Governance-Grenzen
Schicht 2 – Qualität und Zuverlässigkeit:
- Entwichene Defekte, die mit Merge-Prozessfehlern verbunden sind
- Wiedereröffnungs-/Revert-Rate für zusammengeführte Änderungen
- Häufigkeit fehlgeschlagener Gate-Wiederholungen
Schicht 3 – Risiko und Governance:
- Richtlinienverstoßrate
- Bedrohungserkennungs-Blockierungsrate
- Rate menschlicher Interventionen nach Kategorie
- Anzahl der Ausnahmegenehmigungen
Verwenden Sie sowohl führende als auch nachlaufende Indikatoren. Führende (Gate-Pass-Stabilität, Prompt-Ambiguitätsdefekte, Alert-to-Action-Latenz) zur schnellen Steuerung. Nachlaufende (Incident-Rate, mittlere Wiederherstellungszeit, Stakeholder-Vertrauen in die Bereitschaft zur automatisierten Zusammenführung) zur Validierung der Richtung.
Legen Sie eine Baseline vor dem Rollout fest: vorherige 30-Tage-Merge-Entscheidungszeiten, Anzahl bestehender manueller Berührungspunkte, aktuelles Release-Incident-Profil. Messen Sie nach 30/60/90 Tagen nach der Einführung. Dies ermöglicht einen fairen Vergleich und verhindert narrative Berichterstattung.
Wenn sich die Leistung verbessert, fragen Sie, was der Grund dafür war. Workflow-Design? Verhaltensänderung des Teams? Reduziertes Volumen? Umgebungsstabilisierung? Schreiben Sie nicht alles dem agentischen Workflow zu.
Nach 90 Tagen sieht „gut“ so aus:
- Geringere Latenz bei Merge-Entscheidungen
- Weniger manuelle Übergabeschritte
- Stabiles oder verbessertes Defekt-/Revert-Profil
- Klare Grenzen für menschliche Eskalation
- Bessere Auditierbarkeit von Release-Entscheidungen
Das einzige Problem? Wenn die Geschwindigkeit steigt, aber die Risikosignale sich verschlechtern, haben Sie das Problem nicht gelöst. Sie haben es nur schneller gemacht, es zu erzeugen.
Und genau das haben diese jüngsten Vorfälle aufgedeckt. Viele Teams hatten schnelle Pipelines. Sie hatten keine vertrauenswürdigen Pipelines.
Was wir bei Kolsetu entwickelt haben: Das Pre-Merge-Gate endet mit einem Abdeckungsbericht – 11 Gates, jedes mit explizitem Status (bestanden / übersprungen / fehlgeschlagen). Nach 90 Tagen wissen wir genau, welche Gates am häufigsten fehlschlagen, welche am langsamsten sind und wo sich Wiederholungsversuche häufen. Das Signal ist nicht „wie viele Workflows liefen“ – es ist „wie viele Branches alle 11 Gates sauber ohne Wiederholungsversuch durchlaufen haben“. Das korreliert mit der Produktionsstabilität.
Die vollständige Checkliste der Serie – alle 8 Grundlagen:
- Expliziter Gate-Graph
- Quell-/Kompilierungs-verwaltete Workflow-Logik
- Native Sicherheitskontrollen, nicht nachträglich angebracht – einschließlich unveränderlicher Referenzen, strenger Berechtigungen und expliziter Vertrauensgrenzen
- Trennung von Orchestrierungs- und Worker-Verantwortlichkeiten
- Prompts als Protokolle verfasst
- Menschliche Genehmigungen grenzbasiert, nicht gewohnheitsmäßig
- Wiederholbare Observability
- Messung von Ergebnissen, nicht von Aktivitäten
Boom. Wenn Sie alle acht Punkte mit Ja beantworten können, läuft Ihr agentisches Workflow-Programm als Ingenieursystem, nicht als Demo.
Weiterführende Literatur:
