Mike Bild
post

Agent, Modell, Fachdomäne

Das Modell ist gemietet, der Agent ist gestaltbar – und die eigentliche Unternehmensfrage lautet, ob die Fachdomäne als Prosa im Prompt liegt oder als geprüfte Schnittstelle im Agenten.

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

Diesen Beitrag anhören (14 Min.)

MP3 herunterladen

Vor einiger Zeit saß ich in einem großen Konzern in einer Runde, die eine „Agenten-Strategie“ für das kommende Jahr beschließen sollte. An der Wand eine Folie mit drei Spalten: drei Anbieter, darunter Häkchen für Funktionen, Preise pro Nutzer, Compliance-Siegel. Eine Stunde lang drehte sich das Gespräch um die Frage, welcher Agent der beste sei. Irgendwann habe ich eine andere Frage gestellt: Was von alledem gehört uns hinterher eigentlich? Wenn wir in drei Jahren den Anbieter wechseln – was nehmen wir mit? Es wurde still. Nicht, weil die Frage besonders originell gewesen wäre, sondern weil die Folie auf sie keine Antwort hatte.

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

Die letzte Folge endete mit der Frage, wem ich kuratiertes Wissen in die Hand gebe – und wo der generische Agent an seine Grenzen kommt. Um sie zu beantworten, muss ich zuerst auseinandernehmen, was in dem Wort „Agent“ alles zusammengepackt wird. Denn die stille Minute im Konferenzraum hatte einen einfachen Grund: Die Runde hat über Agenten gesprochen wie über ein Gerät, das man kauft, aufstellt und benutzt. Dieses Bild führt in die Irre – und zwar genau an der Stelle, an der es fürs Unternehmen teuer wird.

Ein Agent ist Software

Was ein Agent wirklich ist, lässt sich in einem Satz sagen, der sich im Herbst 2025 als Arbeitsdefinition durchgesetzt hat – Simon Willison hat ihn so knapp formuliert, dass er hängen bleibt: Ein Agent ist ein Modell, das in einer Schleife Werkzeuge aufruft, um ein Ziel zu erreichen. Mehr steckt nicht dahinter. Kein Bewusstsein, keine Absicht, keine Magie.

Da ist eine Schleife: Das Modell bekommt eine Aufgabe und den bisherigen Verlauf, schlägt den nächsten Schritt vor, der Agent führt ihn aus, das Ergebnis fließt zurück – bis eine Stoppbedingung greift. Da sind Werkzeuge: Funktionen, die der Agent dem Modell anbietet und deren Aufrufe er ausführt. Da ist Kontext: alles, was der Agent dem Modell mitgibt, von Dateien über Suchergebnisse bis zu Instruktionen. Da ist Zustand: was zwischen den Schritten und über die Session hinaus erhalten bleibt. Und da sind Rechte: was der Agent überhaupt ausführen darf, mit wessen Berechtigungen, mit welchen Nachweisen.

Jedes einzelne dieser fünf Dinge ist gewöhnliche Software. In Folge 3 habe ich beschrieben, dass genau dieser Rahmen – der Harness – den Unterschied zwischen einem beeindruckenden und einem brauchbaren Werkzeug ausmacht. Damals meinte ich das persönlich: mein Rechner, meine Werkzeuge, meine Arbeitsweise. Heute lese ich denselben Satz organisatorisch. Was für meine Kommandozeile gilt, gilt für das Unternehmen erst recht: Das Modell liefert Urteilskraft und Sprache. Alles andere liefert der Agent. Und alles andere lässt sich gestalten.

Was man mietet und was man besitzt

Diese Arbeitsteilung lohnt einen genauen Blick, weil sie ökonomisch zwei völlig verschiedene Dinge beschreibt.

Das Modell mietet man. Es kommt über eine API, es gehört dem Anbieter, es wird in Versionssprüngen ausgetauscht, ohne dass man viel mitzureden hätte. Man besitzt daran nichts – und das ist verkraftbar, denn die Modelle sind, wie ich früh in dieser Serie argumentiert habe, für die meisten Aufgaben austauschbar gut geworden. Wer seine Strategie auf „das beste Modell“ baut, baut auf etwas, das er weder besitzt noch kontrolliert.

Der Agent dagegen ist besitzbar. Die Schleife, der Kontextaufbau, der Zustand, die Rechte, vor allem die Werkzeuge – all das ist Code und Konfiguration, die man versionieren, testen, prüfen und weiterentwickeln kann. Selbst die Anschluss-Technik ist inzwischen Allgemeingut: MCP, das Protokoll, über das Agenten Werkzeuge und Datenquellen ansprechen, liegt seit Dezember 2025 zusammen mit AGENTS.md bei einer eigens gegründeten Stiftung unter dem Dach der Linux Foundation. OpenAI, Google, Microsoft, Anthropic – alle sprechen dasselbe Protokoll. Die Anbindung ist Normware geworden.

flowchart TB
    subgraph rented["gemietet – austauschbar"]
        M["Modell<br/>Urteilskraft und Sprache"]
    end
    subgraph owned["gestaltbar – besitzbar"]
        A["Agent<br/>Schleife · Kontext · Zustand · Rechte"]
        W["Werkzeuge und Schnittstellen<br/>typisierte Operationen"]
        F["Fachdomäne<br/>Begriffe · Regeln · Abläufe"]
        A --> W
        W --> F
    end
    A -- "fragt an" --> M
    M -- "schlägt Schritte vor" --> A

Wenn aber das Modell gemietet und die Anbindung genormt ist, bleibt genau eine Stelle übrig, an der ein Unternehmen sich unterscheidet: das, was es in den Agenten hineinlegt. Seine Begriffe, seine Regeln, seine Abläufe, seine Daten – kurz: seine Fachdomäne. Und damit steht die eigentliche Frage dieses Beitrags im Raum. Wo liegt die Fachdomäne?

Variante A: die Fachdomäne als Prosa

Der naheliegende Ort ist der Prompt. In der Praxis heißt das: Instruktionsdateien wie CLAUDE.md oder AGENTS.md, Systemprompts, angehängte Richtlinien-Dokumente. Dort steht dann so etwas wie: „Gutschriften über 500 Euro brauchen eine zweite Freigabe. Kunden im laufenden Mahnverfahren erhalten keine Kulanzgutschrift. Preisänderungen gelten erst ab dem Folgemonat.“

Ich will diese Variante nicht kleinreden. Sie ist schnell: kein Entwicklungsaufwand, jede Fachabteilung kann mitschreiben, Änderungen wirken sofort. Für exploratives Arbeiten reicht das oft – und am Anfang ist es fast immer der richtige Weg, weil man erst einmal herausfinden muss, welche Regeln überhaupt gebraucht werden.

Aber sie ist fragil, und zwar strukturell, nicht nur handwerklich. Erstens ist Prosa ungeprüft: Niemand validiert sie, kein Compiler meldet, dass Satz 12 und Satz 47 sich widersprechen, keine Typprüfung merkt, dass „500 Euro“ an einer Stelle brutto und an der anderen netto gemeint war. Zweitens ist Prosa für das Modell eine Empfehlung, keine Regel – das war die zentrale Ernüchterung meiner vergeblichen Versuche mit Instruktionsdateien: Das Modell gewichtet Anweisungen, es befolgt sie nicht. Drittens greift die Session-Lotterie: Derselbe Satz wird heute beachtet und morgen überlesen, je nachdem, was sonst noch im Kontext liegt. Und viertens – im Unternehmen wiegt das am schwersten – lässt sich zwar die Datei versionieren, aber nicht das Verhalten. Es gibt keinen Test, der fehlschlägt, wenn die 500-Euro-Regel ignoriert wird. Man merkt es erst an der Gutschrift.

Prosa skaliert mit der Menge des Wissens. Sie skaliert nicht mit dessen Verbindlichkeit.

Variante B: die Fachdomäne als Schnittstelle

Die Alternative: das Fachwissen nicht neben den Agenten legen, sondern in seine Werkzeuge einbauen. Statt dem Modell generischen Datenbank- und Dateizugriff zu geben und die Regeln als Text daneben zu stellen, bekommt der Agent typisierte Operationen, deren Namen aus der Fachsprache kommen und deren Eingaben geprüft werden:

const issueCreditNote = defineTool({
  name: "issue_credit_note",
  description: "Issue a credit note for an existing invoice",
  input: z.object({
    invoiceId: z.string(),
    amount: z.number().positive(),
    reason: z.enum(["complaint", "goodwill", "pricing_error"]),
  }),
  authorize: ({ user, input }) =>
    input.amount <= 500 || user.hasRole("team_lead"),
  execute: (input, ctx) => billing.issueCreditNote(input, ctx.audit),
});

Der Unterschied ist grundsätzlicher, als der kurze Codeblock aussieht. Die 500-Euro-Regel ist keine Bitte mehr, sondern Code: Sie wird bei jedem Aufruf geprüft, in jeder Session gleich, unabhängig von Tagesform und Kontextlage des Modells. Es gibt sie genau einmal, sie hat einen Besitzer, ein Review, einen Test. Ein Kunde im Mahnverfahren? Dann lehnt die Autorisierung ab – ganz gleich, wie überzeugend das Modell den Aufruf formuliert hat. Die KI formuliert, die Schnittstelle entscheidet, was überhaupt möglich ist.

Das ist die konsequente Fortsetzung von zwei Gedanken aus den letzten Folgen. In Folge 8 ging es darum, Antworten zu erden: nachschlagen statt raten, echte Quellen statt plausibler Vermutungen. Ein Werkzeug ist geerdetes Wissen in ausführbarer Form – der Agent muss die Gutschriften-Regeln nicht erraten, er kann nur innerhalb von ihnen handeln. Und in Folge 9 ging es um Wissen, das die Session überlebt: Eine Werkzeug-Definition überlebt sie von selbst, weil sie Teil des Systems ist und nicht Teil des Gesprächs.

Noch etwas passiert dabei, und beim ersten Mal hat es mich gefreut, weil es direkt an Domain-Driven Design anschließt: Die Namen der Werkzeuge werden zur verbindlichen Fachsprache. Was Eric Evans vor gut zwanzig Jahren „ubiquitous language“ nannte – eine gemeinsame, präzise Sprache zwischen Fachbereich und Entwicklung – bekommt eine sehr handfeste Existenzform. Wenn issue_credit_note und waive_dunning_fee die einzigen Verben sind, die der Agent kennt, muss die Organisation sich einigen, was diese Verben genau bedeuten. Das Modellieren der Werkzeuge ist Domänenarbeit, keine Infrastrukturarbeit. Und ein Agent, der solche Werkzeuge trägt, kennt die Fachdomäne wirklich, statt sie aus dem Kontext zu erraten – das ist die Chance, um die es hier geht.

Die Gegenrechnung

So weit die Chance. Zur selben Rechnung gehört die Kostenseite, und die hat es in sich.

Da ist zuerst der Lock-in. Werkzeug-Definitionen, Skill-Formate, Agent-Konfigurationen folgen heute Anbieter-Konventionen. MCP normt den Transport, nicht die Semantik: Das Protokoll legt fest, wie ein Werkzeug aufgerufen wird, nicht, wie meine Gutschriften-Logik strukturiert ist. Wer seine Fachlogik direkt in die Formate eines Agent-Frameworks gießt, hat sie in drei Jahren genau dort liegen – und der Umzug kostet. Das Gegenmittel ist ein altes: die Fachlogik in eigene Dienste legen und die Werkzeug-Schicht als dünnen Adapter bauen. Aber das muss man tun, es passiert nicht von allein, und unter Termindruck passiert regelmäßig das Gegenteil.

Dann der Pflegeaufwand. Eine eigene Werkzeug-Schicht ist ein Produkt, kein Projekt. Fachregeln ändern sich: Aus der 500-Euro-Schwelle werden 300, ein neuer Gutschriftsgrund kommt dazu, eine Rolle wird umgebaut. Jemand muss das pflegen, priorisieren, testen und ausrollen – neben allem anderen. Die Prosa-Variante war auch deshalb so verführerisch, weil sie diesen Aufwand versteckt hat. Die Werkzeug-Variante macht ihn sichtbar, und Sichtbarkeit fühlt sich zunächst wie Verteuerung an, obwohl der Aufwand vorher nur woanders lag: in den Korrekturen hinterher.

Drittens Prüfbarkeit und Verantwortung. Wer haftet für eine Werkzeug-Definition? Die Frage klingt juristisch, ist aber vor allem organisatorisch. Ein schlechter Prompt erzeugt eine schlechte Antwort, die ein Mensch verwerfen kann. Ein fehlerhaft definiertes Werkzeug wird mit voller Autorität ausgeführt – eine falsche Obergrenze in der Autorisierung gilt dann verlässlich falsch, in jeder Session, für jeden Nutzer. Werkzeug-Definitionen brauchen deshalb dieselbe Sorgfalt wie jede produktive Schnittstelle: Review, Tests, klare Zuständigkeit, Änderungshistorie. Und die Verantwortung verschiebt sich spürbar: weg vom Einzelnen, der einen Prompt formuliert hat, hin zum Team, das das Werkzeug definiert hat. Das ist konsequent und richtig – aber eine Organisation muss das wollen, entscheiden und aushalten.

Und schließlich die Übersteuerung. Es ist verlockend, nach dem ersten Zwischenfall jede denkbare Abweichung wegzudefinieren, bis der Agent nur noch einen einzigen, engen Pfad kennt. Dann hat man ein Formular gebaut, mit einer Chat-Oberfläche davor – teurer, langsamer und launischer, als das Formular es gewesen wäre. Die Stärke des Modells liegt gerade im Unvorhergesehenen: im Sonderfall, in der Rückfrage, im Zusammenhang zwischen zwei Vorgängen, an den beim Entwurf niemand gedacht hat. Wer dem Agenten nur Werkzeuge für das Erwartbare gibt, hätte klassische Automatisierung billiger haben können. Zu enge Werkzeuge sind nicht sicher. Sie sind nur nutzlos.

Wann generische Werkzeuge reichen – und wann nicht

Aus den letzten Monaten haben sich für mich ein paar Kriterien herausgebildet. Generische Werkzeuge – Dateizugriff, Shell, Suche, wie sie Claude Code oder Codex mitbringen – reichen erstaunlich weit, solange ein paar Bedingungen zusammenkommen:

  • Die Arbeit ist explorativ: analysieren, prototypisieren, recherchieren, migrieren – Aufgaben, deren Ergebnis ohnehin ein Mensch begutachtet.
  • Es arbeitet eine Einzelperson, die das Ergebnis selbst verantwortet und selbst beurteilen kann.
  • Das Schadenspotenzial ist klein: alles reversibel, nichts verlässt das Haus, kein Geld bewegt sich.
  • Das Fachwissen ist noch im Fluss – es wäre schlicht zu früh, es in Schnittstellen zu gießen.

Umgekehrt gehört die Fachdomäne in den Agenten, sobald sich das Bild dreht:

  • Ein Ablauf wiederholt sich im Team: dieselbe Operation, viele Personen, unterschiedliche Sorgfalt und Erfahrung.
  • Regeln sind verbindlich, nicht empfohlen – sie müssen auch am Freitagnachmittag um 17 Uhr gelten.
  • Es gibt Audit- oder Nachweispflichten: Wer hat wann was ausgelöst, mit welcher Begründung?
  • Das Schadenspotenzial ist hoch: Geld, personenbezogene Daten, Wirkung nach außen.

Dazwischen liegt ein pragmatischer Übergang, den ich inzwischen bewusst nutze: Die Prosa-Variante ist der Prototyp der Schnittstelle. Wenn dieselbe Regel zum dritten Mal in einer Instruktionsdatei auftaucht – und zum zweiten Mal ignoriert wurde –, ist sie ein Kandidat für ein Werkzeug. So wandert die Fachdomäne Stück für Stück von der Empfehlung in die Struktur, entlang ihrer tatsächlichen Verbindlichkeit statt entlang eines großen Vorabplans.

Zwischenstand

Mit dieser Folge schließt sich ein Bogen, der im November mit einer sehr persönlichen Beobachtung begann. Am Anfang stand die Session: die Erfahrung, dass die Modelle für meine Arbeit gut genug sind und der Unterschied in meinem eigenen Rahmen liegt – Werkzeuge, Kontext, Arbeitsweise. Dann kam das Team: die Ernüchterung, dass sich mein Arbeitserfolg nicht per Datei kopieren lässt und Instruktionsdateien Empfehlungen bleiben, so sorgfältig man sie auch schreibt. Dann das Wissen: sauberes Grounding statt überzeugendem Raten, kuratierte Erkenntnisse, die Sessions überleben. Und jetzt das System: die Einsicht, dass das Modell gemietet ist und gemietet bleibt – und dass alles, was ein Unternehmen an dieser Technik wirklich besitzen kann, im Agenten liegt. Genauer: in den Werkzeugen, mit denen der Agent die Fachdomäne berührt.

Offen ist damit die härteste Frage von allen. Werkzeuge entscheiden, was möglich ist – aber verbindliche Regeln verlangen mehr: Freigaben, bevor etwas wirkt; Nachvollziehbarkeit, nachdem es gewirkt hat; ein Nein, das ein Nein bleibt, auch wenn das Modell freundlich weiterformuliert. Warum das am Ende auf einen eigenen, an die Fachdomäne gebundenen Agenten hinausläuft – und was der können muss –, ist einen eigenen Beitrag wert.

Weiterführende Quellen

Kommentare