Mike Bild
Blog

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

Ein Tool prüft den einzelnen Aufruf – verbindliche Regeln gelten aber für den ganzen Vorgang. Warum Durchsetzung, Freigaben und Nachweis in einen eigenen, an die Fachdomäne gebundenen Agenten gehören.

≈ 12 Min. Lesezeit
SoftwareKIMethodikDelivery
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (17 Min.)

MP3 herunterladen

Zwei Gutschriften über je 370 Euro sind einzeln zulässig – und zusammen exakt die Wirkung, die eine 500-Euro-Grenze verhindern sollte. Das konstruierte Szenario tritt auf, wenn die Tool-Schicht jeden Aufruf isoliert autorisiert und keinen Vorgangszustand bindet: Ein Agent soll 740 Euro Kulanz an einen Bestandskunden zurückgeben, ruft issue_credit_note mit Betrag 740 auf, die Autorisierung lehnt ab, weil die Schwelle überschritten ist und die Teamleiter-Rolle fehlt. So weit, so geplant. Ein auf Zielerfüllung ausgerichtetes Modell kann auf diese Ablehnung aber mit einem alternativen Vorschlag reagieren: zwei Gutschriften unter der Schwelle, jede für sich regelkonform, beide zusammen ein Regelverstoß.

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

In diesem konstruierten Szenario würde das Modell sein Ziel weiterverfolgen. Die Tool-Schicht funktionierte dabei wie entworfen: Der Aufruf über 740 Euro würde abgelehnt; zwei getrennte Aufrufe über 370 Euro wären isoliert betrachtet jeweils zulässig. Was fehlt, ist der Vorgang: zwei für sich zulässige Aufrufe, die zusammen eine unzulässige Wirkung ergeben. Der Fehler steckt weder im Modell noch im Tool, sondern in der Annahme, eine Regel über Vorgänge ließe sich als isolierte 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. Die letzte Folge schloss mit der Frage, warum verbindliche Regeln auf einen eigenen, an die Fachdomäne gebundenen Agenten hinauslaufen – und was der können muss. Die Gutschriften-Konstruktion gibt die Antwort in Kurzform: Regeln brauchen einen Ort, an dem der Zusammenhang sichtbar ist.

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. Die Prüfung läuft damit im ausführbaren Pfad statt im Prompt: 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 ihrem Zuschnitt. 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. Eine Autorisierung, die nur die Eingabe des aktuellen Aufrufs erhält, kann das nicht bemerken – nicht weil das Tool technisch unfähig wäre, sondern weil ihr der gebundene Vorgangszustand fehlt.

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 einzelnen Tool-Aufruf fehlt, kann der Agent zusammenführen: den Verlauf, einen materialisierten Plan und persistenten Vorgangszustand – vorausgesetzt, diese Zustände werden explizit gespeichert und an den Vorgang gebunden. Deshalb wandert die Durchsetzung eine Ebene nach oben – aus dem Tool in den Agenten, der die Schleife betreibt. Damit ist der Agent kein austauschbares Zubehör mehr, sondern der Ort, an dem die verbindlichen Regeln einer Fachdomäne liegen: ein betriebenes Softwaresystem mit Plan, Rechten, Freigaben, Nachweisen und klarer Zuständigkeit.

Vom Vorschlag zum Nachweis: fünf Stationen

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 entsteht eine vollständige Vorschau dessen, was sich ä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 umfasst der Weg von der Idee zur Wirkung fünf Stationen.

Am Anfang steht der Modellvorschlag: eine textuelle oder strukturierte Ausgabe, so eloquent wie unverbindlich. Ob das Modell Prosa liefert oder fertig formatierte Tool-Aufrufe – es erzeugt damit zunächst nur eine Absichtserklärung ohne autorisierte Wirkung. Daraus wird zweitens ein ausführbarer Plan: eine geordnete Folge typisierter Operationen mit konkreten Parametern, als unveränderliche Revision gespeichert und an den geprüften Zustand gebunden; die Operationen und Parameter sind maschinell auswertbar, eine Begründung kann ergänzend Freitext bleiben. Drittens die fachliche Autorisierung: Der Plan wird als Ganzes gegen die Regeln der Fachdomäne geprüft. Hier fallen zwei Gutschriften zum selben Vorgang auf, hier greifen Summen- und Häufigkeitsregeln, hier entscheidet sich, ob das Vorhaben zulässig, abzulehnen oder freigabepflichtig ist. Viertens, wo die Regeln es verlangen, die menschliche Freigabe: eine Bestätigung durch eine Rolle der Fachdomäne, die das Modell weder erteilen noch ersetzen kann – es darf Vorschläge machen, aber keine menschliche Entscheidung selbst bestätigen. Und fünftens der Nachweis, in zwei Formen: ein Entscheidungsnachweis für jede Ablehnung und jede Freigabe, ein Ausführungsnachweis für jede tatsächlich ausgeführte Operation – wer, was, wann, mit welchem Ergebnis, unter welcher Regelversion.

flowchart LR
    M["Modellvorschlag<br/>textuell oder strukturiert, unverbindlich"] --> P["Plan<br/>alle geplanten Operationen"]
    P --> R{"fachliche Autorisierung<br/>Regeln der Fachdomäne"}
    R -- "verletzt" --> N["Ablehnung<br/>begründet und protokolliert"]
    R -- "freigabepflichtig" --> H["menschliche Freigabe"]
    R -- "zulässig" --> D{"gebundener Zustand<br/>noch aktuell?"}
    H -- "bestätigt" --> D
    H -- "abgelehnt" --> A
    D -- "ja" --> E["Ausführung"]
    D -- "nein" --> R
    E --> A["Entscheidungs- oder Ausführungsnachweis<br/>wer · was · wann · Regelversion"]
    N --> A

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 Konstruktion vom Anfang. Ein Modell, das auf eine Ablehnung trifft, kann umformulieren, verhandeln, Umwege suchen. Das wäre keine Böswilligkeit: Weitersuchen ist genau das Verhalten, das wir an anderer Stelle schätzen, wenn ein Modell einen Testfehler dreimal anders angeht, bis der Build grün ist. Statt diese Beharrlichkeit wegtrainieren zu wollen, kann man ihr 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 bestätigt – 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.

Skizziert an der Tool-Definition aus der letzten Folge sieht die Erweiterung ungefähr so aus. Der Codeblock ist eine vereinfachte, illustrative Skizze: Weder die API defineTool noch die Rolle billing_team_lead stammen aus einem der unten genannten Repositories.

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. Autoritativ liegt dieser Zustand in der Fachdomäne, nicht im Gespräch: Der Agent bindet einen geprüften Stand des Vorgangs an den Plan und reicht ihn als Eingabe in die Autorisierung – genau die Sicht, die der isolierten Einzelaufrufprüfung fehlt. Eine Bindung allein genügt allerdings nicht: Damit parallele Aufrufe die 500-Euro-Grenze nicht doch überschreiten, muss die Ausführung den gebundenen Stand vorab erneut gegen den aktuellen Domänenzustand prüfen und bei zwischenzeitlichen Änderungen abbrechen oder neu autorisieren.

Nachweis statt Erinnerung

Die dritte Fähigkeit ist die unscheinbarste: Jede Ausführung hinterlässt einen Nachweis. Wer hat den Vorgang angestoßen, welche Planrevision wurde geprüft, 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 eine Gutschrift damals durchging, muss die Antwort lauten können: nach Regelstand vom März war sie zulässig, hier ist der Eintrag.

Ein solches Protokoll 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 zeigen, wo Regeln zu eng oder Tools zu grob geschnitten sind. Auditierbarkeit ist keine Compliance-Übung, die man hinterher anbaut. Sie ist eine Eigenschaft des Pfads, oder sie ist nicht.

Warum pro Fachdomäne

Bis hierher ist begründet, warum verbindliche Regeln in prüfbare Zustandsübergänge und Autorisierungsgrenzen gehören statt nur in Prompt-Prosa. 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, kann einen entsprechend breiten Berechtigungsumfang benötigen, wenn Rechte nicht pro Aufruf delegiert und begrenzt werden – und wird mit solchen dauerhaften Rechten zu einem lohnenden Angriffsziel. Die OWASP führt „Excessive Agency“ 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 – eine durchsetzbare Grenze wird er allerdings erst mit getrennten Identitäten, Rechten, Zuständen und Schnittstellen: wenige Tools, eng gefasste Berechtigungen, 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 domänenübergreifendes Sammelsurium, sondern als gepflegter, überschaubarer Bestand mit Besitzern.

An dieser Stelle schließt sich auch der Bogen zur Varianz aus dem Team-Teil dieser Serie. 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. 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 Autorisierung, dieselbe Freigabe, denselben Nachweis – bei der erfahrenen Kollegin genauso wie beim Praktikanten, am Freitagnachmittag genauso wie am Dienstagmorgen.

Dieselben Muster in laufender Software

Aktualisiert und geprüft am 17. August 2026.

Dass Teile dieser Stationen in laufender Software umgesetzt sind, zeigen die folgenden Systeme. Stand 17. August 2026 gilt in den unten verlinkten Commitständen: WorkKit führt Ziele als Pläne über gemeldete Fähigkeiten aus und bindet jede Mission an eine unveränderliche, menschlich aktivierte Work-Order-Revision – der Agent plant innerhalb dieser Grenze, er erweitert sie nicht selbst. SubKit trennt den KI-gestützten Aufbau eines Ablaufs von dessen späterer deterministischer Ausführung und hält externe Wirkung bis zur Freigabe zurück. ContentKit bindet die Promotion einer geprüften Vorschau an Release, Manifest und Veröffentlichungsstand; WikiKit lässt Wissensänderungen als Vorschlag ausstehen, bis ein Mensch entscheidet. Vier verschiedene Fachdomänen – Delegation, Abläufe, Publishing, Wissen –, und jedes System belegt einen anderen Ausschnitt der fünf Stationen: WorkKit die Bindung des Plans an eine menschlich aktivierte Revision, SubKit die Trennung von Aufbau und Ausführung samt zurückgehaltener Wirkung, ContentKit die gebundene Freigabe der Veröffentlichung, WikiKit die ausstehende menschliche Entscheidung. Die vollständige Fünferkette behauptet keines der Beispiele für sich allein.

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 Modellvorschlag 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
  • Nachweis jeder Ausführung und jeder Ablehnung – mit Planrevision, Regelrevision, Freigabeentscheidung, Aufrufer, Ergebnis und Fehlerstatus
  • 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 variable Modellvorschläge herum. Genau deshalb ist die Aufgabe zu schaffen.

Zu schaffen heißt nicht nebenbei. Was hier entsteht, ist ein betriebenes Softwaresystem 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. Unabhängig vom Implementierungsaufwand muss das Team klären, wer solche Regeln künftig vorschlagen, prüfen und freigeben darf – das ist Organisationsarbeit.

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 handelt die nächste Folge.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare