Hilfsmittel, die tragen: Konzepte, Methoden, Prozesse

Für einen Agenten, der eine Fachdomäne verbindlich vertritt, gibt es kein Installationspaket. Installieren lassen sich verfügbare Modellgewichte und Laufzeiten; Protokolle lassen sich implementieren oder anbinden. Modellgewichte und Laufzeiten allein erzwingen jedoch keine fachliche Freigabe und erzeugen keinen fachlich aussagekräftigen Nachweis darüber, wer was entschieden hat. Der verbindliche Teil entsteht erst in der Auseinandersetzung mit der eigenen Domäne – mit ihren Begriffen, ihren Regeln und den Menschen, die für beides einstehen. Der Weg dorthin ist allerdings lernbar, und er ist unspektakulärer, als viele Framework-Debatten vermuten lassen.

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

Aktualisiert am 17. August 2026: Die genannten Produktstände wurden gegen die jeweiligen Repositories geprüft.

Die letzte Folge hat beschrieben, was so ein Agent können muss: Pläne prüfen, bevor sie wirken; Freigaben, die kein Modell wegformulieren kann; Nachweise, die Fragen von übermorgen beantworten. Offen geblieben ist der Weg dorthin. Er führt über drei Sorten von Hilfsmitteln: Konzepte, die tragen. Methoden, die den Anfang klein halten. Und Prozesse, die das Ganze im Betrieb am Leben erhalten, wenn die Aufmerksamkeit weiterzieht. Der Reihe nach.

Konzepte: nichts davon ist neu

Wer die Fähigkeiten-Liste aus der letzten Folge durchgeht, findet darin keine einzige KI-Erfindung. Fachsprache und Domänenschnitt – dass ein System die Begriffe seiner Domäne sprechen soll und dass diese Begriffe nur innerhalb eines abgesteckten Zusammenhangs eindeutig sind – hat Eric Evans vor gut zwanzig Jahren in „Domain-Driven Design“ als ubiquitous language und Bounded Context beschrieben. Die Trennung von Vorschlag und Wirkung kennt jede Organisation, die Änderungen erst prüft und dann ausrollt, vom Vier-Augen-Prinzip in der Buchhaltung bis zu terraform plan und apply. Validierung, Autorisierung, Audit sind das Handwerkszeug jeder ernsthaften Fachanwendung. Und dass Antworten auf echten Quellen stehen müssen statt auf plausiblem Raten und kuratiertes Wissen einen Kreislauf mit Besitzern braucht, haben die mittleren Folgen dieser Serie behandelt – auch das ist im Kern Dokumentations- und Bibliotheksarbeit, kein Hexenwerk.

Neu ist allein der Abnehmer: eine Schleife, in der ein Modell handelt, statt einer Oberfläche, in der Menschen klicken. Für die Konzeptauswahl ist das eine kleine Verschiebung. Mir hilft seither eine einfache Prüffrage: Hat dieses Konzept schon getragen, bevor es KI gab? Domänenschnitt, Freigabe-Workflows, Versionierung, Audit – ja, jahrzehntelang. Ein Orchestrierungs-Framework, das es seit vier Monaten gibt – eher nicht. Das ist keine Abwertung von allem Neuen; irgendwo entsteht gerade tatsächlich das nächste tragende Konzept. Aber die Beweislast liegt beim Neuen, nicht beim Bewährten.

Dass sich die alten Konzepte direkt in Agentensysteme übertragen lassen, zeigt sich an konkreten Bausteinen. WorkKit etwa trennt Mission, Plan, Lauf und die dazu erteilte Work-Order-Autorität – und nutzt für HTTP, MCP, A2A, Webhooks und Chat denselben Planungspfad. Das ist die alte Trennung von Vorschlag und Wirkung, konsequent auf jeden Eingangskanal angewendet: Egal, woher ein Vorhaben kommt, es nimmt denselben Planungspfad. Beleg dafür ist die README des WorkKit-Repositorys in Revision 788e460, geprüft am 17. August 2026; die Nennung dient hier der Einordnung, nicht der Empfehlung eines Produkts.

Für den Reflex, gleich die ganze Organisation als Agenten-Landschaft zu entwerfen, gibt es ebenfalls ein altes Konzept, und es trifft härter als jede Technikfrage. John Gall hat es in den Siebzigern als Beobachtung über Systeme formuliert: Ein komplexes System, das funktioniert, ist ausnahmslos aus einem einfachen System hervorgegangen, das funktioniert hat. Ein komplexes System, das am Reißbrett entworfen wurde, funktioniert nicht und lässt sich auch nicht reparieren – man muss von vorn anfangen, mit einem einfachen System. Zwölf verbundene Agenten auf einem Whiteboard sind der Reißbrett-Entwurf. Der erste Vorgang, der wirklich läuft und ein prüfbares Ergebnis liefert, ist der Anfang des Systems.

Methode: erst die Regeln inventarisieren

Die erste der drei Fragen vom Ende der letzten Folge lautete: Welche Regeln gehören in den Pfad, welche dürfen Prosa bleiben? Die Antwort beginnt nicht bei der Technik, sondern bei einer Bestandsaufnahme, die unbeliebter ist, als sie sein müsste. Für die Inventur würde ich zunächst vier Fundorte prüfen: das Wiki, Instruktionsdateien wie CLAUDE.md oder AGENTS.md, Code-Review-Kommentare – und Köpfe, als das Wissen der einen Kollegin, die man sicherheitshalber vor jeder Preisänderung fragt. Vollständig ist diese Liste nicht; je nach Organisation kommen Tickets, Richtlinien, Konfiguration oder Fachverfahren hinzu. Die Inventur holt die Regeln an einen Ort und notiert zu jeder vier Dinge: Wo steht sie? Wie verbindlich ist sie gemeint? Was passiert bei einem Verstoß? Und wie oft wurde sie zuletzt tatsächlich verletzt?

Die letzte Spalte ist die wichtigste, denn sie ersetzt Meinung durch Befund. In der Chronik meiner Instruktionsdateien war die Ernüchterung, dass aufgeschriebene Regeln Empfehlungen bleiben; in der Folge über Tools wurde daraus ein Übergangskriterium: Wenn dieselbe Regel zum dritten Mal in einer Instruktionsdatei auftaucht und zum zweiten Mal ignoriert wurde, ist sie ein Kandidat für die Durchsetzung im Pfad. Die Inventur macht aus diesem Bauchgefühl eine Liste:

# rule inventory, one entry per rule
- rule: "Credit notes above 500 EUR require team lead approval"
  source: wiki, AGENTS.md
  violation_impact: money leaves the company
  violated_recently: twice in Q2
  decision: enforce   # goes into the path

- rule: "Use the customer number, not the invoice number, in replies"
  source: onboarding notes
  violation_impact: confusion, no damage
  violated_recently: unknown
  decision: prose     # stays a convention

Für die Einordnung halte ich drei Fragen für einen tragfähigen Startpunkt, und sie decken sich mit den Kriterien, die sich in dieser Serie nach und nach herausgeschält haben: Bewegt ein Verstoß Geld, personenbezogene Daten oder Wirkung nach außen? Muss hinterher jemand nachweisen können, wer was wann entschieden hat? Wurde die Regel trotz sauberer Dokumentation wiederholt gebrochen – von Menschen oder vom Modell? Ein Ja bei einer dieser Fragen ist für mich der Ausgangspunkt, die Regel in den Pfad zu nehmen: Prüfung, Freigabe, Nachweis. Eine Startheuristik bleibt das allerdings – wo der mögliche Schaden gering ist, ein Fehler sich leicht zurücknehmen lässt oder bestehende Kontrollen ihn ohnehin abfangen, kann eine Regel auch bei einem Ja Prosa bleiben. Dreimal Nein, und sie bleibt Prosa – als Konvention, die das Modell liest und meistens befolgt, und deren verbleibendes Risiko ausdrücklich akzeptiert wurde.

Die Inventur hat einen zweiten Ertrag, der leicht übersehen wird: Sie findet tote Regeln. Vorgaben, die seit Jahren niemand mehr braucht, deren Anlass längst verschwunden ist, die aber weiter in jedem Dokument mitgeschleppt werden. Die fliegen raus – nicht in den Pfad, sondern ganz. Ein Agent, der eine Fachdomäne vertritt, ist auch eine Gelegenheit, die Domäne selbst zu entrümpeln.

Methode: die erste Domäne klein schneiden

Die zweite Frage: Wie schneidet man die erste Domäne, ohne sich zu verheben? Die kurze Antwort: einen Vorgang, keine Abteilung. Eine Abteilung bündelt viele Zustände und Verantwortlichkeiten, die nie gleichzeitig fertig sind; ein Vorgang hat einen prüfbaren Anfang und ein prüfbares Ende. „Rechnungswesen“ ist deshalb kein Schnitt, sondern ein Organigramm-Kästchen. „Gutschriften und Mahnstopps“ ist einer – ein abgrenzbarer Vorgang mit Anfang, Ende und einer Handvoll Verben.

Woran man einen tauglichen ersten Kandidaten erkennt:

• Der Vorgang hat einen klaren Anfang und ein klares Ende – kein Dauerzustand, kein Sammelbegriff.
• Eine Handvoll Verben genügt: Spätestens wenn die Tool-Liste beim Modellieren zweistellig wird, würde ich den Schnitt erneut prüfen.
• Es gibt heute schon eine fachlich zuständige Person – die Rolle, die auch ohne KI freigibt und entscheidet.
• Der Schmerz ist dokumentiert: Verstöße sind in der Vergangenheit tatsächlich passiert und haben nachweislich geärgert.
• Das Schadenspotenzial rechtfertigt den Aufwand, bleibt aber überschaubar – Gutschriften ja, Zahlungsverkehr mit dem Ausland vielleicht erst im zweiten Jahr.

Der letzte Punkt verdient einen Moment. Der erste Domänen-Agent ist nicht nur ein Werkzeug, er ist auch das Stück, an dem ein Team die drei Fähigkeiten – Prüfung, Freigabe, Nachweis – zum ersten Mal baut und betreibt. Solche ersten Stücke wählt man so, dass Fehler lehrreich sind, nicht existenzbedrohend.

Zum kleinen Schnitt gehört auch ein kleiner Übergang. Niemand reißt die bestehende Arbeitsweise ab und ersetzt sie durch den Agenten; die Prosa-Variante bleibt der Prototyp, aus dem Regeln einzeln in den Pfad wandern, sobald ihre Verbindlichkeit sich erwiesen hat. Martin Fowler hat für dieses Muster – das Neue wächst am Alten entlang, bis das Alte entbehrlich ist – das Bild der Würgefeige geprägt, die einen Baum umwächst. Auf Regeln übertragen: Erst gilt die 500-Euro-Regel als Satz in der Instruktionsdatei, dann zusätzlich als Prüfung im Pfad, und irgendwann ist der Satz nur noch Dokumentation der Prüfung. Kein großer Umstellungstag, keine riskante Migration über ein Wochenende.

Der Rest der großen Skizze stirbt dabei nicht – er wird Backlog, sortiert nach genau den Kriterien oben. Das kann sich wie ein Rückzug anfühlen. Es ist das Gegenteil: der erste Schritt, der tatsächlich gegangen werden kann und ein überprüfbares Ergebnis liefert.

Prozesse: Besitzer, Änderungsweg, Rhythmus

Bleibt die dritte Sorte Hilfsmittel, und sie ist die am leichtesten unterschätzte. Konzepte kann man lernen, Methoden kann man anwenden – Prozesse muss man im Betrieb durchhalten. Drei halte ich für tragend.

Erstens: Jede Regel hat einen Besitzer, und der sitzt im Fachbereich. Die Entwicklung besitzt die Durchsetzung – den Code, der prüft, das Gatter, das wartet, das Protokoll, das schreibt. Aber ob 500 Euro die richtige Schwelle ist, ob „Kulanz“ und „Preisfehler“ verschiedene Wege gehen, entscheidet die Fachseite, die diese Verantwortung schon immer trug. Die Diskussion über das Vorschlagen, Prüfen und Freigeben von Regeln ist dabei kein Hindernis auf dem Weg zum Prozess. Sie ist der Prozess – wer sie überspringt, hat Regeln ohne Legitimation, und die erodieren beim ersten Konflikt.

Zweitens: Regeländerungen gehen denselben Weg wie Regeln. Vorschlag, Prüfung, Freigabe, Versionierung – dieselbe Sorgfalt, die für Code selbstverständlich ist. Dass der Nachweis die geltende Regelversion festhält, war in der letzten Folge ein Detail am Rand; im Betrieb wird es zur Voraussetzung dafür, dass man Regeln überhaupt anfassen kann, ohne die Vergangenheit umzudeuten. Wie das aussehen kann, zeigen zwei Bausteine, jeweils geprüft am 17. August 2026 in der README des genannten Repositorys: WikiKit (Revision bf19663) hält fachliche Leitlinien in einem versionierten, menschenverantworteten Charter und führt Änderungen am abgeleiteten Wissensbestand durch den Review-Prozess. SubKit (Revision c25ce81) beschreibt genehmigte Abläufe als wiederholbar ausgeführte Workflows und protokolliert jeden Lauf – nicht beschriebene und nicht genehmigte Arbeit wird nicht improvisiert. Beides sind Ausprägungen desselben Prinzips: Der Änderungsweg ist in das System eingebaut – WikiKit führt Änderungen durch Review, SubKit führt nur beschriebene und genehmigte Abläufe aus und hält jeden Lauf im Protokoll fest.

Drittens, und am wichtigsten: aus den Neins lernen, in festem Rhythmus. Der Agent erzeugt im Betrieb zwei Ströme – Ausführungen und Ablehnungen. Für zu enge oder fehlende Regeln sind die Ablehnungen oft der ergiebigere Ausgangspunkt; Stichproben erfolgreicher Läufe bleiben trotzdem nötig, weil auch eine durchgewunkene Ausführung eine falsche Entscheidung enthalten kann. Das Ablehnungsprotokoll gehört deshalb regelmäßig auf den Tisch – anfangs in einem festen Abstand von wenigen Wochen, später abhängig von Ablehnungsrate und Schadenspotenzial – mit drei Fragen: Welche Neins waren richtig und bleiben? Welche waren zu eng und brauchen eine angepasste Schwelle oder einen neuen Gutschriftsgrund? Und welche Sonderfälle tauchen so regelmäßig auf, dass sie ein eigenes Verb verdienen? Das ist derselbe Kreislauf, den die Folge über kuratiertes Wissen beschrieben hat, nur mit Regeln statt Erkenntnissen: Der Betrieb liefert Kandidaten, die Kuration macht Verbindliches daraus – die Organisation ändert dabei Regeln und Schnittstellen; das Modell bleibt unverändert.

flowchart LR
    I["Inventur<br/>Regeln sammeln und bewerten"] --> K["Einordnung<br/>Pfad oder Prosa"]
    K --> B["Bauen<br/>Verben · Prüfung · Freigabe"]
    B --> O["Betrieb<br/>Ausführungen und Ablehnungen"]
    O --> S["Sichtung im Rhythmus<br/>aus den Neins lernen"]
    S --> I

Zusammen ergeben die drei Prozesse das, was in der letzten Folge nur behauptet wurde: dass so ein Agent ein Produkt mit Lebenszyklus ist. Ein Produkt hat Besitzer, einen Änderungsweg und einen Takt, in dem es besser wird. Fehlt eines davon, verfällt es – bei Regeln schneller als bei Code, weil eine veraltete Schwelle keinen Build fehlschlagen lässt und deshalb gezielt durch Review oder Betriebsmetriken erkannt werden muss.

Moden, die man auslassen kann

Und die Gegenliste? Vier Muster halte ich für Aufmerksamkeitsfresser, die weder Prüfung noch Freigabe oder Nachweis verbessern – das ist ein Urteil, kein Messergebnis.

Das Multi-Agenten-Orchester ab Tag eins: viele Agenten, die einander Nachrichten schicken, bevor auch nur einer eine einzige verbindliche Regel durchsetzt – der Reißbrett-Entwurf in Software gegossen. Der häufige Framework-Wechsel, bei dem die Fachlogik jedes Mal ein Stück tiefer in Anbieter-Konventionen einsinkt; das Gegenmittel – Fachlogik in eigene Dienste, Tool-Schicht als dünner Adapter – stand schon in der Folge über Agent, Modell und Fachdomäne. Die Modell-Vergleichstabelle als Strategieersatz, gegen die diese Serie früh argumentiert hat: Ob mehrere Modelle die eigenen Aufgaben gut genug lösen, zeigt eine konkrete Prüfung gegen genau diese Aufgaben – und dort, wo das der Fall ist, gehört die Energie in den eigenen Anteil, nicht in die Tabelle. Und das endlose Feilen an Formulierungen: Wenn dieselbe Anweisung zum dritten Mal umformuliert wird, damit das Modell sie „endlich versteht“, ist das kein Schreibproblem. Es ist das Signal, dass die Regel in den Pfad gehört, nicht in schönere Worte.

Die Prüffrage ist immer dieselbe, und sie macht die Liste kurz: Hilft es, Prüfung, Freigabe oder Nachweis zu bauen – oder fühlt es sich nur nach Fortschritt an? Viele derzeit diskutierte Frameworks und Agentenmuster kann man in Ruhe reifen lassen. Sie laufen nicht weg, und was davon trägt, ist in einem Jahr noch da.

Zwischenstand

Damit sind die drei Fragen vom Ende der letzten Folge beantwortet, so gut ich es nach diesen Monaten kann: mit einer Inventur, die Befunde statt Meinungen liefert, einem Schnitt von der Größe eines Vorgangs und Prozessen, die Besitzer, Änderungsweg und Rhythmus festlegen. Beginnen würde ich deshalb mit einem belegten Regelverstoß in einem bereits klein geschnittenen Vorgang – dort ist der Schmerz dokumentiert, der Schnitt klein und das Ergebnis prüfbar. Die Konzepte dahinter sind alt, und das ist ihre wichtigste Eigenschaft: Sie haben schon einmal gehalten.

Vor gut acht Monaten begann diese Serie mit einer Session auf meinem Rechner und der Beobachtung, dass sich meine Arbeit verändert; jetzt endet der Weg vorläufig bei Organisationen, die Regeln, Wissen und Verantwortung in eigene Agenten legen. Die nächste Folge prüft die Erwartungen aus dem Auftakt: Was davon ist eingetreten, was nicht – und wohin führt das alles?

Weiterführende Quellen

• Domain-Driven Design Reference (Eric Evans) – ubiquitous language und Bounded Context als Entwurfsarbeit
• John Gall: Systemantics – warum funktionierende komplexe Systeme aus einfachen funktionierenden Systemen entstehen
• Martin Fowler: Strangler Fig Application – das Muster für Übergänge ohne großen Umstellungstag
• Building Effective AI Agents (Anthropic) – der Rat, mit dem einfachsten funktionierenden Aufbau zu beginnen

Wie fandest du diesen Beitrag?

Kommentare