Mike Bild
page

Hilfsmittel, die tragen: Konzepte, Methoden, Prozesse

Hilfsmittel, die tragen: Konzepte, Methoden, Prozesse Einen Agenten für die eigene Fachdomäne kann man nicht installieren – den Weg dorthin aber sehr wohl lernen. Welche Konzepte…

Einen Agenten für die eigene Fachdomäne kann man nicht installieren – den Weg dorthin aber sehr wohl lernen. Welche Konzepte tragen, welche Methoden den Anfang klein halten und welche Prozesse verhindern, dass Regeln veralten.

Zwischen „wir haben verstanden, was so ein Agent ist" und „wir haben einen" liegt ein Schritt, den kein Plan beantwortet. Das Muster kehrt in fast jedem Gespräch wieder, das ich zu dem Thema führe: Jemand hat die ganze Organisation als künftige Agenten-Landschaft skizziert – ein Dutzend Domänen von „Rechnungswesen" bis „Support", dazwischen Pfeile, Warteschlangen, ein gemeinsamer Wissensspeicher. Eine durchdachte Skizze, echte Denkarbeit steckt darin. Und dann die eine Frage: Welche Domäne kommt zuerst? Der Plan beantwortet alles – außer den ersten Schritt.

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

Die letzte Folge hat beschrieben, was ein Agent können muss, der eine Fachdomäne verbindlich vertritt: 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 – und genau daran scheitert die schöne Skizze. Er führt über drei Sorten von Hilfsmitteln: Konzepte, die tragen. Methoden, die den Anfang klein halten. Und Prozesse, die das Ganze 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 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 behandelt – 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 „Agent-Mesh-Orchestrierungs-Framework", das es seit vier Monaten gibt – eher nicht. Das ist keine Abwertung des Neuen; irgendwo entsteht gerade tatsächlich das nächste tragende Konzept. Aber die Beweislast liegt beim Neuen, nicht beim Bewährten.

Für die Landschaft mit dem Dutzend Domänen gibt es auch ein altes Konzept, und es trifft härter als jede Technikfrage. John Gall hat es in den Siebzigern 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. Die Agenten-Landschaft war der Reißbrett-Entwurf. Der erste Kasten, der wirklich läuft, 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. Regeln stehen heute an vier Orten: im Wiki, in Instruktionsdateien wie CLAUDE.md oder AGENTS.md, in Code-Review-Kommentaren – und in Köpfen, als das Wissen der einen Kollegin, die man sicherheitshalber vor jeder Preisänderung fragt. Die Inventur holt sie an einen Ort und notiert zu jeder Regel 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 haben sich drei Fragen bewährt, und sie decken sich mit den Kriterien, die sich in dieser Serie 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, und die Regel gehört in den Pfad: Prüfung, Freigabe, Nachweis. Dreimal Nein, und sie bleibt Prosa – als Konvention, die das Modell liest und meistens befolgt, und bei der ein gelegentlicher Ausreißer niemandem wehtut.

Die Inventur hat einen zweiten Ertrag, mit dem ich nicht gerechnet hatte: 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. „Rechnungswesen" ist kein Schnitt, sondern ein Organigramm-Kästchen. „Gutschriften und Mahnstopps" ist ein Schnitt – 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: Wenn die Tool-Liste beim Modellieren zweistellig wird, ist der Schnitt zu groß.
  • 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 Übungsstück, an dem man die drei Fähigkeiten – Prüfung, Freigabe, Nachweis – zum ersten Mal baut und betreibt. Übungsstü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.

Aus dem Dutzend Domänen wird so eine, und selbst die wird kleiner: nicht „Rechnungswesen", sondern Kulanzgutschriften. Der Rest der Skizze stirbt nicht – er wird Backlog, sortiert nach genau den Kriterien oben. Das klingt zunächst nach Rückzug. Es ist das Gegenteil: der erste Schritt, der tatsächlich gegangen werden kann.

Prozesse: Besitzer, Freigaben, 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 durchhalten. Drei haben sich als tragend erwiesen.

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 letzte Folge endete mit der Beobachtung, dass die halbe Stunde für die Summenprüfung der einfache Teil war und die Diskussion über das Vorschlagen, Prüfen und Freigeben von Regeln der lange. Diese Diskussion ist 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.

Drittens, und am wichtigsten: aus den Neins lernen, in festem Rhythmus. Der Agent erzeugt im Betrieb zwei Ströme – Ausführungen und Ablehnungen. Die Ablehnungen sind das wertvollere Material. Alle paar Wochen gehört das Ablehnungsprotokoll auf den Tisch, 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 – und die Organisation wird schlauer, nicht das Modell.

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 niemand einen Build-Fehler bekommt, wenn eine Schwelle nicht mehr zur Wirklichkeit passt.

Eine Mode, die man auslassen kann

Und die Gegenliste? Was kostet Aufmerksamkeit, ohne eine der drei Fähigkeiten voranzubringen?

Das Multi-Agenten-Orchester ab Tag eins – die Landschaft vom Anfang in Software gegossen, ein Dutzend Agenten, die einander Nachrichten schicken, bevor auch nur einer eine einzige verbindliche Regel durchsetzt. Der wöchentliche 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: Wer seine Aufgaben konkret prüft, stellt meist fest, dass mehrere Modelle sie gut genug lösen – und dass die Energie in den eigenen Anteil gehört. 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? Vieles von dem, was gerade laut ist, kann man in Ruhe reifen lassen. Es läuft 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. Welche Regeln in den Pfad gehören, entscheidet eine Inventur mit Befunden statt Meinungen. Die erste Domäne schneidet man als einen Vorgang mit einer Handvoll Verben, an dem Fehler lehrreich bleiben. Und was das Ganze am Leben erhält, sind unspektakuläre Prozesse: Besitzer, ein Änderungsweg, ein Rhythmus für die Neins. Die Konzepte dahinter sind alt, und das ist ihre wichtigste Eigenschaft – sie haben schon einmal gehalten.

Die Serie hat damit einen Punkt erreicht, an dem sich der Bogen schließen lässt. Vor gut acht Monaten begann sie 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. Zeit, ehrlich Bilanz zu ziehen: Was von den Erwartungen des Auftakts ist eingetreten, was nicht – und wohin führt das alles? Davon handelt die nächste Folge.

Weiterführende Quellen