Agent, Modell, Fachdomäne

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. Simon Willison formulierte im Herbst 2025 eine dafür brauchbare Arbeitsdefinition: Ein Agent ist ein Modell, das in einer Schleife Tools 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 Tools: 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 erzeugt Ausgaben, etwa Vorschläge, Klassifikationen und Formulierungen. Der Agent bestimmt Schleife, Kontext, Zustand, Rechte und Tool-Anbindung. Diese Teile lassen sich gestalten.

Was man mietet und was man kontrollieren kann

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

Ein proprietäres Modell, das man über die API eines Anbieters bezieht, mietet man: Es gehört dem Anbieter, und über Versionswechsel bestimmt man nur in dem Rahmen mit, den API-Vertrag und Anbieter vorgeben. Man besitzt daran nichts – und das ist verkraftbar, wenn mehrere Modelle die eigenen, konkret geprüften Aufgaben hinreichend gut lösen. Wer seine Strategie auf „das beste Modell“ baut, baut auf etwas, das er weder besitzt noch kontrolliert. Den ausführlichen Gedanken dazu habe ich früh in dieser Serie beschrieben.

Der Agenten-Layer kann dagegen unter eigener Kontrolle stehen. Die Schleife, der Kontextaufbau, der Zustand, die Rechte, vor allem die Tools – all das kann eigener Code und eigene Konfiguration sein, versionierbar, testbar und überprüfbar. Auch die Anbindung wird weniger proprietär: MCP liegt seit Dezember 2025 zusammen mit AGENTS.md und goose bei der Agentic AI Foundation unter dem Dach der Linux Foundation. Eine Garantie, dass jeder Anbieter dieselben Fähigkeiten auf dieselbe Weise bereitstellt, ist das nicht.

flowchart TB
    subgraph rented["gemietet – austauschbar"]
        M["Modell<br/>Vorschläge · Klassifikation · Sprache"]
    end
    subgraph owned["gestaltbar – unter eigener Kontrolle"]
        A["Agent<br/>Schleife · Kontext · Zustand · Rechte"]
        W["Tools 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 das Modell gemietet und die Anbindung zunehmend standardisiert ist, bleibt ein besonders wichtiger eigener Anteil: das, was ein Unternehmen in den Agenten hineinlegt. Seine Begriffe, seine Regeln, seine Abläufe, seine Daten – kurz: seine Fachdomäne. Damit steht die 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 darf nur eine Teamleitung auslösen. Kunden im laufenden Mahnverfahren erhalten keine Kulanzgutschrift. Preisänderungen gelten erst ab dem Folgemonat.“

Ich will diese Variante nicht kleinreden. Sie ist schnell: Wenn es einen freigegebenen Pflegeweg gibt, kann die Fachabteilung den Text ändern, ohne die Fachanwendung anzufassen. Die geänderte Fassung steht dem Modell zur Verfügung, sobald der Agent sie lädt. 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 bloß 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, kein verlässlicher Enforcement-Mechanismus – das war die zentrale Ernüchterung meiner vergeblichen Versuche mit Instruktionsdateien: Das Modell kann Anweisungen befolgen, ihre Einhaltung lässt sich damit aber nicht erzwingen. 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. Die Instruktionsdatei allein stellt keine deterministische, blockierende Prüfung bereit, die eine regelwidrige Gutschrift verhindert; ohne zusätzliche Prüfung fällt der Verstoß erst hinterher auf.

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 Tools 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. 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 Tool 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 Tool-Definition überlebt sie von selbst, weil sie Teil des Systems ist und nicht Teil des Gesprächs.

Die Tool-Namen schließen dabei direkt an Domain-Driven Design an: Sie 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 Tools ist Domänenarbeit, keine Infrastrukturarbeit. Die Schnittstelle kann Eingaben und Berechtigungen einzelner Aufrufe verlässlich prüfen; Ablaufregeln über mehrere Aufrufe brauchen zusätzliche Zustandsprüfung und gegebenenfalls eine Prüfung des geplanten Ablaufs.

Die Gegenrechnung

So weit die Chance. Zur selben Rechnung gehören Lock-in, Pflegeaufwand, Verantwortung und Übersteuerung.

Da ist zuerst der Lock-in. Tool-Definitionen, Skill-Formate, Agent-Konfigurationen folgen heute Anbieter-Konventionen. MCP normt den Transport, nicht die Semantik: Das Protokoll legt fest, wie ein Tool 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 Tool-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 Tool-Schicht verursacht dauerhaften Pflege- und Betriebsaufwand. 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 Tool-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 Tool-Definition? Die Frage klingt juristisch, ist aber vor allem organisatorisch. Bei rein beratender Nutzung kann ein Mensch die Antwort verwerfen. Darf der Agent Tools ohne Freigabe ausführen, kann ein Fehler in deren Autorisierung unmittelbar wirken: Eine falsche Obergrenze gilt dann verlässlich falsch, in jeder Session, für jeden Nutzer. Tool-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 Tool 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 Tools für das Erwartbare gibt, hätte klassische Automatisierung billiger haben können. Zu enge Tools können Risiken begrenzen, aber auch so viel Handlungsspielraum nehmen, dass klassische Automatisierung die passendere Lösung wäre.

Wann generische Tools reichen – und wann nicht

Für meine Entscheidung sind vier Kriterien maßgeblich: die Art der Arbeit, die Verantwortlichen, das Schadenspotenzial und der Reifegrad des Fachwissens. Generische Tools – Dateizugriff, Shell, Suche – 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 nutze ich einen pragmatischen Übergang: 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 für mich ein Kandidat für ein Tool. 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

Für mich verschiebt die bisherige Serie die Verantwortung von der Session zum System. 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 – Tools, 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 der dauerhaft kontrollierbare Anteil im Agenten liegt. Genauer: in den Tools, mit denen der Agent die Fachdomäne berührt.

Offen bleibt die Frage, wie verbindliche Regeln über einzelne Tool-Aufrufe hinweg durchgesetzt werden. Tools entscheiden, was in einem einzelnen Aufruf möglich ist – darüber hinaus braucht es 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

• Building Effective AI Agents – Anthropics Unterscheidung von Workflows und Agenten
• Writing effective tools for AI agents – Tool-Design für Agenten aus der Praxis
• Designing agentic loops – Simon Willison über Schleifen, Tools und Stoppbedingungen
• Model Context Protocol – Spezifikation und Dokumentation des Tool-Protokolls
• Gründung der Agentic AI Foundation – MCP, AGENTS.md und goose unter dem Dach der Linux Foundation

Wie fandest du diesen Beitrag?

Kommentare