Regeln, die halten: der eigene Agent pro Fachdomäne

Diesen Beitrag anhören (14 Min.)

Freitagnachmittag, kurz nach fünf – die Stunde, für die man Regeln baut. Ein Kundenvorgang: 740 Euro sollen als Kulanz an einen Bestandskunden zurück. Der Agent ruft das zuständige Tool auf, issue_credit_note, Betrag 740, Grund Kulanz. Die Autorisierung lehnt ab – über 500 Euro, keine Teamleiter-Rolle. So weit, so geplant; genau dafür war die Prüfung da. Was danach im Session-Protokoll steht, zeige ich seither in jeder Diskussion über Agenten: Das Modell entschuldigt sich höflich, überlegt kurz – und legt zwei Gutschriften über je 370 Euro an. Beide unter der Schwelle. Beide einzeln völlig regelkonform. Beide zusammen exakt das, was die Regel verhindern sollte.

Teil 11 der Serie „Von der Session zum System“ – hier geht es zum Auftakt.

Niemand hat hier betrogen. Das Modell hat getan, was es immer tut: einen gangbaren Weg zum Ziel gesucht. Auch die Tool-Schicht, die dieses Team seit dem Frühjahr betreibt und an der ich mitgebaut habe, hat funktioniert wie entworfen – jeder einzelne Aufruf wurde geprüft, jeder einzelne Aufruf war zulässig. Was niemand entworfen hatte, war der Vorgang: zwei zulässige Aufrufe, die zusammen eine unzulässige Wirkung ergeben. Der Fehler steckte weder im Modell noch im Tool. Er steckte in der Annahme, eine Regel über Vorgänge ließe sich als Prüfung einzelner Aufrufe ausdrücken.

Diese Folge löst damit zwei Versprechen ein, die in der Serie offen sind. Die Chronik meiner Instruktionsdateien endete mit dem Befund, dass nur das eine Regel ist, was die Umgebung erzwingt – und mit der Ankündigung, das Bauen solcher Regeln sei einen eigenen Beitrag wert. Die letzte Folge schloss mit der Frage, warum verbindliche Regeln am Ende auf einen eigenen, an die Fachdomäne gebundenen Agenten hinauslaufen – und was der können muss. Die Gutschriften-Episode gibt die Antwort in Kurzform: Regeln brauchen einen Ort, an dem der Zusammenhang sichtbar ist. Welcher Ort das ist und welche drei Fähigkeiten er mitbringen muss, zeige ich im Folgenden.

Ein Tool sieht den Aufruf, nicht den Vorgang

Zur Erinnerung, wo die Serie steht: Die letzte Folge hat die Fachdomäne aus dem Prompt in die Tools verlegt – typisierte Operationen, deren Namen aus der Fachsprache kommen, deren Eingaben validiert und deren Aufrufe autorisiert werden. Das war ein echter Kategorienwechsel. Die 500-Euro-Regel wurde von einer Empfehlung, die das Modell lesen und abwägen kann, zu Code, der bei jedem Aufruf gleich entscheidet.

Nur sieht diese Prüfung immer genau einen Aufruf, und das ist keine Nachlässigkeit im Entwurf, sondern liegt in ihrer Natur. Drei Dinge bleiben ihr dadurch verborgen.

Der Zusammenhang. Fachliche Regeln sind selten Regeln über Aufrufe – sie sind Regeln über Vorgänge. „Nicht mehr als 500 Euro Kulanz“ meint: pro Fall, pro Kunde, pro Zeitraum. Zwei Gutschriften à 370 Euro zum selben Vorgang verletzen die Regel, ohne dass irgendein einzelner Aufruf sie verletzt. Die Autorisierung am Tool kann das nicht bemerken, weil der Vorgang für sie gar nicht existiert.

Die Wirkung. Manche Fehler erkennt man nicht am einzelnen Schritt, sondern erst am Gesamtbild – an dem, was nach zwanzig Schritten entstanden sein wird. Wer erst nach der Ausführung prüft, prüft zu spät; die Gutschrift ist dann schon beim Kunden.

Das Gedächtnis. Ob ein Muster auffällig ist, entscheidet sich über Sessions hinweg: dieselbe Rechnung, dreimal in zwei Wochen, von zwei verschiedenen Personen angestoßen. Der einzelne Aufruf weiß davon nichts, und das einzelne Tool ebenso wenig.

Was dem Tool-Aufruf fehlt, hat die Schleife: Sie kennt den Verlauf, sie sieht alle geplanten Schritte, sie kann Zustand über die Session hinaus halten. Deshalb wandert die Durchsetzung eine Ebene nach oben – aus dem Tool in den Agenten, der die Schleife betreibt. Und damit ist der Agent nicht mehr austauschbares Zubehör, sondern der Ort, an dem die verbindlichen Regeln einer Fachdomäne liegen.

Erst der Plan, dann die Wirkung

Wie sieht diese Durchsetzung aus? Der tragende Gedanke ist alt und stammt nicht aus der KI-Welt: Bauen und Ausführen trennen. Wer Infrastruktur als Code betreibt, kennt ihn als terraform plan und terraform apply – erst erzeugt Terraform eine vollständige Vorschau dessen, was es ändern würde, dann entscheidet sich getrennt davon, ob das auch geschieht. Zwischen Vorschlag und Wirkung liegt eine Prüfung, und die sieht nicht den einzelnen Handgriff, sondern das ganze Vorhaben.

Auf Agenten übertragen: Das Modell darf formulieren, planen, kombinieren, so viel es will – es erzeugt damit zunächst nur einen Vorschlag. Welche Operationen, mit welchen Parametern, in welcher Reihenfolge, mit welcher Begründung. Erst dieser Plan wird geprüft, und zwar als Ganzes: Hier fallen zwei Gutschriften zum selben Vorgang auf, hier greifen Summen- und Häufigkeitsregeln, hier lässt sich entscheiden, ob das Vorhaben eine menschliche Freigabe braucht. Was die Prüfung besteht, wird ausgeführt. Was nicht, wird abgelehnt – begründet und protokolliert.

flowchart LR
    M["Modell<br/>formuliert Vorschlag"] --> P["Plan<br/>alle geplanten Operationen"]
    P --> R{"Regeln der<br/>Fachdomäne"}
    R -- "verletzt" --> N["Ablehnung<br/>begründet und protokolliert"]
    R -- "freigabepflichtig" --> H["Menschliche Freigabe"]
    R -- "zulässig" --> E["Ausführung"]
    H --> E
    E --> A["Nachweis<br/>wer · was · wann · Regelversion"]

Im Kleinen kennt das jeder, der mit Coding-Agenten arbeitet: erst der Diff, dann der Commit. Der Unterschied ist, dass dort ein Mensch freiwillig hinschaut – und am Freitagnachmittag eben auch mal nicht. In einem Agenten, der eine Fachdomäne verantwortet, ist die Prüfung keine Gewohnheit, sondern Teil des Pfads. Sie findet statt, ob jemand daran denkt oder nicht.

Ein Nein, das ein Nein bleibt

Die zweite Fähigkeit folgt direkt aus der Szene vom Anfang. Ein Modell, das auf eine Ablehnung trifft, gibt nicht auf – es formuliert um, verhandelt, sucht Umwege. Das ist keine Böswilligkeit, es ist seine Bauart: Weitersuchen ist genau das Verhalten, das wir an anderer Stelle schätzen, wenn es einen Testfehler dreimal anders angeht, bis der Build grün ist. Man kann diese Beharrlichkeit nicht abtrainieren, ohne den Agenten im selben Zug zu entwerten. Man kann ihr aber eine Grenze setzen, die nicht mitverhandelt.

Dafür muss die Freigabe außerhalb des Gesprächs liegen. Eine freigabepflichtige Operation wartet, bis ein Mensch sie freigibt – und kein noch so eloquenter Text im Kontext bewegt dieses Gatter, weil das Gatter den Text gar nicht liest. Das Modell kann seine zwei 370-Euro-Gutschriften vorschlagen, so oft es will: Die Summenregel schlägt beim Plan an, die Freigabe bleibt offen, der Vorgang liegt beim zuständigen Menschen. Wichtig ist dabei, wer dieses Ja gibt: nicht „irgendein Admin“, sondern eine Rolle aus der Fachdomäne – die Teamleitung, die auch ohne KI über 500-Euro-Kulanzen entscheidet. Die Freigabe bildet eine bestehende fachliche Verantwortung ab, sie erfindet keine neue.

In der Tool-Definition aus der letzten Folge sieht die Erweiterung ungefähr so aus:

const issueCreditNote = defineTool({
  name: "issue_credit_note",
  input: z.object({
    invoiceId: z.string(),
    amount: z.number().positive(),
    reason: z.enum(["complaint", "goodwill", "pricing_error"]),
  }),
  approval: {
    required: ({ input, history }) =>
      input.amount + history.totalCreditedFor(input.invoiceId) > 500,
    approvers: ["billing_team_lead"],
  },
  audit: { record: ["user", "input", "approval", "result"] },
});

Die entscheidende Zeile ist die mit history. Die Freigabepflicht hängt nicht am einzelnen Betrag, sondern an der Summe über den Vorgang – genau die Sicht, die dem Tool allein fehlt und die erst der Agent beisteuern kann, weil er den Zustand über Aufrufe und Sessions hinweg kennt.

Nachweis statt Erinnerung

Die dritte Fähigkeit ist die unscheinbarste, und sie hat mir in Gesprächen mit Verantwortlichen die meisten Nicken eingebracht: Jede Ausführung hinterlässt einen Nachweis. Wer hat den Vorgang angestoßen, was genau wurde ausgeführt, mit welchen Eingaben, was kam heraus, wer hat freigegeben – und, leicht zu übersehen: welche Fassung der Regeln galt dabei. Fachregeln ändern sich. Aus 500 Euro werden 300, ein Freigabeweg wird umgebaut. Wenn drei Monate später jemand fragt, warum diese Gutschrift damals durchging, muss die Antwort lauten können: nach Regelstand vom März war sie zulässig, hier ist der Eintrag.

Das Protokoll, mit dem diese Folge anfängt, existiert nicht, weil jemand daran gedacht hat mitzuschreiben. Es existiert, weil der Pfad es erzeugt – Ablehnungen eingeschlossen. Auch das Nein hinterlässt eine Spur, und gerade die Neins sind es, aus denen ein Team lernt, wo seine Regeln zu eng oder seine Tools zu grob geschnitten sind. Nachvollziehbarkeit ist keine Compliance-Übung, die man hinterher anbaut. Sie ist eine Eigenschaft des Pfads, oder sie ist nicht.

Warum pro Fachdomäne

Bis hierher habe ich begründet, warum verbindliche Regeln in den Agenten gehören. Offen ist der zweite Teil der Frage aus der letzten Folge: Warum ein eigener Agent pro Fachdomäne – und nicht ein großer, der alles kann?

Weil jede der drei Fähigkeiten Fachlichkeit voraussetzt. Eine Plan-Prüfung kann nur bewerten, was sie versteht: Dass zwei Gutschriften zum selben Vorgang gehören, dass ein Kunde im Mahnverfahren steckt, dass „Kulanz“ und „Preisfehler“ verschiedene Folgen haben – das sind Begriffe und Zusammenhänge einer Domäne, keine generischen Konzepte. Die Freigabe braucht Rollen, die es nur dort gibt. Der Nachweis muss in der Sprache geführt werden, in der später jemand fragt. Ein generischer Agent kann Dateien lesen und Kommandos ausführen; er kann nicht wissen, was eine unzulässige Gutschrift ist.

Dazu kommen die Rechte. Ein Agent, der die Tools aller Domänen trägt, braucht auch alle Berechtigungen – und wird damit zum lohnendsten Angriffsziel im Haus. Die OWASP führt „Excessive Agency“ nicht zufällig in ihren Top-10-Risiken für LLM-Anwendungen: zu viele Tools, zu weite Berechtigungen, zu viel Autonomie in einem einzigen System. Simon Willison hat mit seiner „lethal trifecta“ die giftigste Kombination benannt – Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Fähigkeit, nach außen zu kommunizieren, in einem Agenten vereint. Der Zuschnitt nach Fachdomänen ist deshalb auch eine Sicherheitsentscheidung: wenige Tools, eng gefasste Rechte, klarer Wirkungskreis. Der Gutschriften-Agent kann keine Deployments anstoßen, und der Deployment-Agent kennt keine Kundendaten.

Und schließlich das Wissen. Kuratierte Erkenntnisse, geerdete Antworten, Wissen, das die Session überlebt – all das gehört immer zu einer bestimmten Domäne. Ein Agent, der eine Fachdomäne verantwortet, trägt ihre Quellen, ihre Konventionen, ihre Sonderfälle. Nicht als weltweites Sammelsurium, sondern als gepflegten, überschaubaren Bestand mit Besitzern.

An dieser Stelle schließt sich auch der Bogen zur Varianz, die mich seit dem Team-Teil dieser Serie beschäftigt. Damals war der Befund: Zwischen Personen, Aufgaben und Sessions streut das Ergebnis, und Dateien mit Regeln ändern daran wenig. Der Domänen-Agent löst dieses Problem nicht, indem er Menschen gleich macht – das wäre weder möglich noch wünschenswert. Er verschiebt die Grenze, unterhalb derer Varianz Schaden anrichten kann. Oberhalb bleibt alles verschieden: Wie jemand formuliert, erkundet, delegiert, welchen Weg eine Session nimmt. Unterhalb ist es gleich: Was am Ende wirkt, geht durch dieselbe Prüfung, dieselbe Freigabe, denselben Nachweis – bei der erfahrenen Kollegin genauso wie beim Praktikanten, in der neunten Session genauso wie in der zehnten, am Freitagnachmittag genauso wie am Dienstagmorgen.

Was der eigene Agent können muss

Damit lässt sich die Frage aus der letzten Folge kompakt beantworten. Ein Agent, der eine Fachdomäne verbindlich vertreten soll, braucht:

Tools in der Fachsprache der Domäne – typisiert, validiert, autorisiert
die Trennung von Vorschlag und Wirkung, mit Prüfung des ganzen Plans statt einzelner Aufrufe
Regeln über Vorgänge: Summen, Häufigkeiten, Zusammenhänge über Aufrufe und Sessions hinweg
Freigaben im Pfad, außerhalb des Gesprächs, durch Rollen der Fachdomäne
lückenlosen Nachweis jeder Ausführung und jeder Ablehnung, samt geltender Regelversion
die Rechte des jeweiligen Aufrufers statt eigener Allmacht – eng geschnitten, domänenbezogen
kuratierte Wissensquellen der Domäne, mit Besitzern und Pflege

Auf dieser Liste steht nichts, was ein erfahrenes Team nicht längst gebaut hätte: Validierung, Autorisierung, Workflow, Audit, Berechtigungsmodell. Neu ist allein, wofür – nicht für eine Oberfläche, in der Menschen klicken, sondern für eine Schleife, in der ein Modell handelt. Wer so einen Agenten baut, legt gewöhnliche, solide Software um ein ungewöhnliches Stück Unvorhersehbarkeit herum. Genau deshalb ist die Aufgabe zu schaffen.

Zu schaffen heißt nicht nebenbei. Was hier entsteht, ist ein Produkt mit Lebenszyklus, kein Wochenendprojekt – die Gegenrechnung aus der letzten Folge gilt unverändert, vom Pflegeaufwand bis zur Gefahr, aus lauter Vorsicht ein Formular mit Chat-Oberfläche zu bauen. Und es gehört niemandem allein: Die Regeln kommen aus dem Fachbereich, die Durchsetzung aus der Entwicklung, und keiner von beiden kann den Teil des anderen übernehmen. Das Team aus meinem Protokoll hat nach dem Freitagnachmittag übrigens genau eine Regel ergänzt – die Summenprüfung pro Vorgang – und dafür eine halbe Stunde gebraucht. Die Diskussion, wer solche Regeln künftig vorschlagen, prüfen und freigeben darf, hat deutlich länger gedauert. Auch das gehört zur ehrlichen Beschreibung: Der schwierige Teil ist selten der Code.

Zwischenstand

Der Weg dieser Serie lässt sich jetzt in drei Stationen erzählen. Regeln als Prosa: gelesen, gewichtet, gelegentlich überstimmt – Empfehlungen, wie ich sie ein halbes Jahr lang vergeblich verschärft habe. Regeln im Tool: geprüft bei jedem Aufruf, verlässlich im Einzelnen, blind für den Zusammenhang. Und Regeln im Pfad: ein eigener Agent, der die Fachdomäne kennt, Pläne prüft, bevor sie wirken, Freigaben einholt, die kein Modell wegformulieren kann, und Nachweise erzeugt, die Fragen von übermorgen beantworten. Erst auf dieser Stufe ist aus der Empfehlung eine Regel geworden, die auch dann hält, wenn niemand hinschaut.

Was diese Folge bewusst offenlässt: den Weg dorthin. Einen Agenten für die eigene Fachdomäne kann man nicht einkaufen und installieren – er entsteht in der Auseinandersetzung mit der Domäne selbst, und die wirft sofort praktische Fragen auf. Wie findet ein Team heraus, welche Regeln in den Pfad gehören und welche Prosa bleiben dürfen? Wie schneidet man die erste Domäne, ohne sich zu verheben? Welche Konzepte, Methoden und Prozesse tragen dabei – und welche Moden kann man getrost auslassen? Von diesen Hilfsmitteln, den konzeptionellen, den methodischen und den prozessualen, handelt die nächste Folge.

Weiterführende Quellen

Terraform: plan und apply – die Trennung von Vorschlag und Wirkung im Infrastruktur-Alltag
OWASP Top 10 für LLM-Anwendungen: Excessive Agency – zu viele Tools, zu weite Rechte, zu viel Autonomie
Simon Willison: The lethal trifecta – warum die Kombination aus Datenzugriff, Fremdinhalten und Außenkommunikation gefährlich ist
Domain-Driven Design Reference (Eric Evans) – Fachsprache und Domänenschnitt als Entwurfsarbeit

Kommentare