Alle reden über KI-Agenten. Autonom dies, agentisch das. Aber was fast keiner der großen KI-Befürworter laut sagen will: Man kann (sollte?) KI nicht einfach Dinge tun lassen und hoffen dass nichts schlimmer passiert. Nicht mit echten Daten. Nicht mit echtem Geld.
KI braucht Aufsicht. Und im Moment ist das Beste, was wir haben... JSON.
Das war's. Die große Innovation in der KI-Output-Kontrolle ist "lass es JSON zurückgeben." Mit einem Schema, weil man sich ja was gönnt. Und klar, JSON ist besser als Freitext. Aber es hat keine Semantik. Es weiß nichts über deine Domäne. Du kannst validieren, dass ein Feld ein String ist, aber du kannst nicht validieren, dass es eine sinnvolle Aktion ist.
Eine naheliegende Antwort ist, domänenspezifische Sprachen (Domain Specific Language = DSL) zu verwenden. Und ich glaube, fast niemand redet darüber, weil die meisten von euch noch nie eine DSL erstellt haben haben.
Konkret
Du sagst einer KI, sie soll irgendeinen Business-Workflow abarbeiten. Statt eines JSON-Blobs, den du entziffern musst um ihn zu verstehen, oder einer Textwand, in der die KI drei Absätze lang ihre Überlegungen erklärt bevor sie zum Punkt kommt, bekommst du sowas zurück:
SEND invoice #4821 TO client@example.com
APPLY 10% DISCOUNT TO order #1192
SCHEDULE followup call FOR 2026-03-10
Jede Zeile ist eine klar definierte Operation. Sie bildet direkt ab, was dein System tatsächlich kann. Du kannst jede Operation einzeln genehmigen, ablehnen oder mit der KI darüber diskutieren. Die KI kann nichts Seltsames einschmuggeln, weil der Parser es nicht zulässt.
Und wenn die KI etwas produziert, das nicht stimmt? Dann gibt der Parser einen Fehler, und dieser Fehler ist domänenspezifisch. Nicht "unexpected token at position 47", sondern "SEND erfordert eine gültige Rechnungsnummer, bekommen: 'alle'." Die KI bekommt nützliches Feedback, versucht es nochmal, und am Ende stehen dort Operationen die dein System auch ausführen kann.
Warum nicht einfach JSON Schema
"Nimm einfach JSON Schema, das löst das gleiche Problem."
Nein, tut es nicht. JSON Schema beschränkt die Form von Daten. Es kann dir sagen "das muss ein Array von Objekten mit diesen Feldern sein." Es kann dir nicht sagen "das muss eine gültige Abfolge von Operationen in unserem Abrechnungssystem sein, bei der Rabatte 15% nicht überschreiten dürfen und man keine Rechnungen an Adressen schicken kann, die nicht in der Kundendatenbank sind."
Eine DSL gibt dir semantische Validierung, nicht nur strukturelle. Und - das ist wichtiger als die meisten denken - sie ist menschenlesbar. Ein Reviewer kann zehn DSL-Anweisungen überfliegen und in Sekunden verstehen, was gleich passieren wird. Versuch das mal mit einem verschachtelten JSON-Objekt.
Es gibt keine eine DSL, sie alle zu knechten
Es wird keine universelle "KI-Aktionssprache" geben. Das wäre einfach nur eine weitere Allzweck-Programmiersprache mit extra Schritten.
Was es geben sollte, sind eine Million kleine, fokussierte DSLs. Eine für Abrechnungs-Workflows. Eine für E-Mail-Automatisierung. Eine für Lagerverwaltung. Eine für Terminplanung. Jede ist winzig, zweckgebaut und leicht zu validieren.
Und ja, ich weiß - eine Million DSLs klingt nach einem Albtraum. Ist es aber nicht. Jede einzelne ist klein genug, um in deinen Kopf zu passen. Die Grammatik hat vielleicht 20-30 Regeln. Der Parser ist ein paar hundert Zeilen Code. Das ist nicht schwer zu bauen, wenn man die richtigen Werkzeuge hat.
Hier kommt OCaml ins Spiel
Ich bin voreingenommen, offensichtlich. Aber OCaml ist wirklich eine der besten Sprachen überhaupt für den Bau von Parsern und DSLs. Pattern Matching, algebraische Datentypen, ein Typsystem, das ganze Kategorien von Bugs zur Kompilierzeit abfängt - als wäre die Sprache dafür gebaut. (Wurde sie teilweise auch. OCaml hat tiefe Wurzeln in der Programmiersprachenforschung.)
Du kannst den abstrakten Syntaxbaum einer DSL als Typ definieren, einen Parser mit Menhir oder einfach per Recursive Descent schreiben und hast an einem Nachmittag einen funktionierenden, typsicheren Interpreter. Der Compiler sagt dir, wenn du vergessen hast, einen Fall zu behandeln. Versuch das mal mit Python.
Der Großteil der KI-Tooling-Welt ist in Python und TypeScript gebaut. Und das sind akzeptable Sprachen für viele Dinge. Aber der Bau von zuverlässigen Parsern und Sprach-Tooling gehört nicht dazu. Wenn DSLs ein echtes Pattern in der KI-Supervision werden - und ich glaube, das werden sie - haben die Leute, die wissen, wie man sie richtig baut, einen echten Vorteil.
Wo das nicht funktioniert
Allerdings: Dieses Pattern funktioniert nicht für alles. Softwareentwicklung ist zu offen. Der Raum möglicher Aktionen ist zu groß, zu vielfältig, und erfordert zu viel Kontext zur Bewertung. Deshalb nutzen Coding-Tools ein anderes Modell - berechtigungsbasierte Gates auf Tool-Nutzung, nicht strukturierte Aktionsvorschläge.
Aber viele Workflows sind nicht wie Coding. Es gibt eine endliche, klar definierte Menge möglicher Aktionen. Und für die ist ein Reviewer, der eine Liste von zehn vorgeschlagenen Aktionen überfliegt und sagt "ja, los" oder "nein, ändere die dritte" genau das richtige Level an Supervision.
Das Pattern
- Mensch beschreibt in natürlicher Sprache, was er will
- KI produziert eine Liste vorgeschlagener Aktionen in einer domänenspezifischen Sprache
- Ein Parser validiert, dass die Aktionen wohlgeformt und semantisch gültig sind
- Ein Mensch reviewt die Aktionsliste - genehmigt, ändert oder lehnt einzelne Punkte ab
- Genehmigte Aktionen werden ausgeführt
Das war's. Die Werkzeuge zum Bau von Parsern und DSLs gibt es seit Jahrzehnten. Was neu ist, ist die Motivation: KI-Agenten, die strukturierten, überprüfbaren, domänenspezifischen Output brauchen statt Freitext, dem man einfach vertrauen muss.