Governance-Framework für KI-Agenten-Auslieferung
Ein deterministisches Framework, das KI-Agenten-Software-Auslieferung reproduzierbar, auditierbar und genehmigungs-gegatet macht — ein No-LLM-Kernel, Single-Shot-Agenten, erzwungene Invarianten und ein manipulationssicheres Audit-Log.
Ein Framework-Level-System (eigene Workflow-DSL, 132 Tests, CI gegated auf Determinismus), das die Architektur bewies — und das ich dann bewusst ausgemustert habe. Die Governance-Ziele leben heute in einem deutlich kleineren, konfigurationsbasierten Setup; dieses zu bauen und es zu ersetzen ist die Über-Engineering-Lehre hinter meinen Texten zum Bauen mit KI.
KI-Agenten in Auslieferungs-Pipelines sind nicht-deterministisch, schwer zu auditieren und neigen dazu, ihre eigene Arbeit implizit zu genehmigen. Dieses Framework kehrt das um: ein Kernel ohne LLM-Aufrufe bringt eine Workflow-State-Machine pro Aufruf um genau eine Transition voran, Agenten sind Single-Shot, Handoffs geschehen nur über versionierte Artefakte, und jedes Ereignis wird in einem append-only, manipulationssicheren Log festgehalten.
Diese Seite behandelt die Architektur und die Begründung dahinter. Die Mess-Infrastruktur ist eingebaut; dies ist eine Design- und Architektur-Leistung, vor gemessenen Produktionsläufen.
Ein No-LLM-Kernel bringt den Workflow pro Aufruf um eine Transition voran, durch Gates, die jeweils ein Artefakt und explizite Genehmigung verlangen; jedes Ereignis landet in einem append-only, manipulationssicheren Audit-Log.
Hintergrund
KI-Agenten die Software-Auslieferung treiben zu lassen, wirft ein Governance-Problem auf, bevor es ein Fähigkeits-Problem aufwirft: die Arbeit muss reproduzierbar, auditierbar und an jedem Schritt explizit genehmigt sein — nichts davon liefern Agenten von allein. Das Framework behandelt diese Eigenschaften als Architektur, erzwungen vom System statt von den Agenten erbeten.
Design-Entscheidungen
Der Kernel enthält keine LLM-Aufrufe. Er bringt eine deklarative Workflow-State-Machine pro Aufruf um genau eine Transition voran, sodass Fortschritt deterministisch und inspizierbar ist. Agenten machen die offene Arbeit; der Kernel entscheidet, was als Nächstes passieren darf.
Agenten sind Single-Shot, mit artefakt-only Handoffs. Ein Agent läuft einmal und übergibt ein versioniertes Artefakt an das nächste Gate — keine versteckten Loops, kein impliziter State. „Warum kann ein Agent nicht einfach iterieren?" wird explizit in einem Anti-FAQ beantwortet: Iteration ist eine Entscheidung, die sichtbar und genehmigt sein muss.
Architektonische Regeln sind Runtime-Guards. Verletzungen — ein Agent, der versucht zu loopen, eine implizite Genehmigung — werfen typisierte Exceptions, statt der Konvention überlassen zu werden. Jedes Gate verlangt sowohl ein Artefakt als auch eine explizite Genehmigung, um voranzuschreiten.
Jedes Ereignis wird in einem append-only, manipulationssicheren Audit-Log festgehalten (Content-Hashing plus monotoner Zähler), sodass eine Auslieferung im Nachhinein rekonstruiert und verifiziert werden kann.
Operative Überlegungen
Framework-Level: ~14k Zeilen Python mit 132 Tests über 24 Test-Dateien, CI gegated auf Determinismus (ein fixer Hash-Seed). Die Disziplin ist der Punkt — das System existiert, um Agenten-Arbeit vertrauenswürdig zu machen, nicht schneller.
Die Mess-Infrastruktur war von Anfang an eingebaut; es gibt keine Produktionslauf-Ergebnisse, weil ich das System ausgemustert habe, bevor ich mich im Ernstfall darauf verließ — die bewusste Entscheidung, dass Integrate-don't-build bereits gewonnen hatte. Dies ist ein Architektur- und Judgement-Artefakt, keine Impact-Zahl.
Möchten Sie das vollständige Bild hinter diesem System? Nehmen Sie Kontakt auf — oder sehen Sie sich die Engineering-Prinzipien an, die durch alle laufen.