Agent after Agent

Ich habe vor einer Weile bei der Stadt Köln eine Genehmigung für eine kleine Veranstaltung beantragt. Wochenlang keine Antwort. Dann habe ich stundenlang telefoniert, über fünfzehn Gespräche. Das Problem war, überhaupt mal den zuständigen Menschen zu finden. Jeder am anderen Ende wusste zuverlässig eine Sache: dass er selbst nicht zuständig ist. Ich dachte mir: ich brauch einen Agenten für Zuständigkeiten im Kölner Behördendschungel.

Dieselbe Art Arbeit steckt in jedem Back Office, das Reisekostenbelege sortiert und bei jedem Taxibeleg entscheidet, welcher Mehrwertsteuersatz gilt. Automatisierbar war das nie, weil am Anfang eine formlose Mail oder ein Foto steht und kein regelbasiertes System da durchkam. Genau darum geht es mir seit dem Frühjahr in der Serie zu AI Systems Architecture: Wie sieht die Architektur von Systemen aus, wenn KI nicht Textvorschläge liefert, sondern einen ganzen Vorgang abarbeitet?

Ich berate Unternehmen bei genau dieser Frage und baue an solchen Systemen mit. Die Antwort sieht anders aus als erwartet: Nichts daran ist groß. Solche Systeme sind klein geschnitten, und deshalb ist die interessante Architekturfrage nicht, welches Modell die Arbeit macht. Sie ist, wo die Schnitte liegen. Ich spiele das an meinem Beispiel mit der Stadt Köln mal durch, von der Mail bis zum Bescheid.

Monolithische Mega-Agenten

Wenn man also einen Agenten bauen will, der einen solchen Prozess abarbeiten soll, sieht der erste Entwurf fast immer gleich aus. Ein monolithischer Mega-Agent. Er nimmt die Mail entgegen, versteht das Anliegen, findet die zuständige Stelle, prüft die Unterlagen, holt Stellungnahmen ein, formuliert die Auflagen, berechnet die Gebühr und verschickt am Ende den Bescheid. Ein Prompt, alle Tools, alle Rechte.

Was gegen diesen Schnitt spricht, hat wenig mit dem Modell zu tun. In einem echten Fachprozess stecken irrsinnig viele Regeln, in einem Verwaltungsverfahren sowieso. Nehmen wir eine einzige Entscheidung heraus: Wohin gehört dieses Anliegen? Ans Ordnungsamt, und in welche Abteilung dort? An die Straßenverkehrsbehörde, weil eine Sperrung nötig wird? Oder ist es eine Versammlung, für die es gar keine Genehmigung gibt, sondern eine Anzeige bei der Polizei? Klingt nach einer Kleinigkeit und ist ein eigenes Regelwerk aus Ort, Anlass, Besucherzahl und Aufbauten, plus die Frage, ob zu dieser Mail nicht längst ein Vorgang läuft, weil jemand nur den Lageplan nachreicht. Wenn ein Agent diese Zuordnung solide hinbekommt, darf man sich freuen. Danach noch Auflagen und Gebühren in denselben Prompt zu backen, kippt das Ganze.

Dazu die Rechte. Ein Agent, der oben die Mail liest und unten den Bescheid verschickt, braucht unterwegs jede Berechtigung, die im Verfahren irgendwo vorkommt. Sein Blast Radius reicht vom Posteingang bis zum Verwaltungsakt, und ein Bescheid, der einmal draußen ist, lässt sich nicht löschen, nur zurücknehmen, mit eigenem Verfahren. Was daraus folgt, habe ich in Die Taube sieht besser sortiert: Ob ein Mensch prüfen muss, hängt an zwei Achsen, dem möglichen Schaden und der Zeit, die ein Mensch zum Beurteilen braucht. Bei diesem einen Agenten ist der Schaden maximal, und seinen Gesamtoutput kann niemand in vertretbarer Zeit beurteilen.

Die andere Richtung ist genauso falsch

Der Gegenreflex ist genauso verbreitet, und diesen Film habe ich bei Microservices schon einmal gesehen. Damals hieß die Losung: schneidet klein. Also wurde geschnitten, bis für jedes Substantiv im Domänenmodell ein eigener Service lief. Die Komplexität war nicht verschwunden, sie war aus dem Code in die Zwischenräume gewandert, und dort ließ sie sich schlechter debuggen als vorher. Bei Agenten kommt etwas dazu: Ein Agent braucht Kontext des Vorgangs, um sein Urteil zu fällen. Wer die Zuordnung in Mini-Agenten zerlegt, einen für den Ort, einen für die Besucherzahl, einen für den Anlass, gibt jedem ein Stück der Mail und keinem den Zusammenhang, aus dem die Zuordnung überhaupt folgt. Weder Monolith noch Microservice-Agenten.

Für Agenten gibt es dazu inzwischen Messwerte. Google Research, DeepMind und MIT haben in Towards a Science of Scaling Agent Systems Agentensysteme systematisch skaliert und fünf Architekturen gegeneinander laufen lassen.¹ Im Paper steht ein Ablauf, bei dem ein Agent ein Rezept nachschlägt, ein zweiter den Bestand prüft und erst ein dritter etwas tut. Die ersten beiden Schritte waren umsonst, weil die Information sowieso vorlag. Genau das sind Agenten, die auch eine if-Abfrage hätten sein können.

Das zweite Ergebnis hat meine Erwartung umgedreht. Ich hatte Koordination für den Feind gehalten, für das, was Tokens verbrennt und Fehler verschleppt. Das Paper sagt das Gegenteil. Am schlechtesten schneidet die Variante ab, in der mehrere Agenten parallel arbeiten und ihre Ergebnisse am Ende ungeprüft zusammengeworfen werden: 37 Prozent Erfolgsrate, ein einzelner Agent kommt auf 47. Zentral koordinierte Varianten liegen darüber, und das Paper begründet das mit Prüfengstellen, die Fehler abfangen, bevor sie zusammenlaufen. Auf Koordination zu schimpfen wäre also die falsche Lehre.

Arbeitsteilung ohne Prüfstelle ist schlechter als ein einziger Agent.

Zwei Einschränkungen nennen die Autoren selbst. Untersucht haben sie ausdrücklich die Kommunikationstopologie, und die fachliche Spezialisierung von Agenten zählen sie als eigene, unabhängige Entwurfsdimension. Und alle Varianten mussten sich dasselbe Rechenbudget teilen, weshalb ab drei bis vier Agenten die Denkkapazität pro Agent zu dünn wird. Eine Kette, in der jeder Schritt mit vollem Budget und geprüftem Zustand startet, ist damit nicht gemessen.

Passende Schnitte

Es gibt keine “richtige” Architektur, nur eine “passende”.

Bleibt die Frage, wo man schneidet. Mein Kriterium lautet: ein Agent, ein Urteil. Ein Urteil ist eine Entscheidung mit einem zusammenhängenden Regelwerk und einem Menschen, der sie beurteilen kann.

Die beiden Hälften haben unterschiedliche Aufgaben. Das Regelwerk entscheidet, wo geschnitten wird. Der Prüfer entscheidet, ob der Schnitt verantwortbar ist. Naheliegend wäre, daraus ein einziges Kriterium mit Und zu machen: gleiches Regelwerk und gleicher Prüfer, sonst Schnitt. Das stolpert beim Vier-Augen-Prinzip. Gleiches Regelwerk, absichtlich zwei Prüfer, und trotzdem wäre es Unsinn, dafür zwei Agenten mit identischem Prompt zu bauen. Der zweite Prüfer ist ein Gate hinter dem Agenten, kein zweiter Agent.

Die Prüfer-Hälfte ist der Teil, der in Architekturdiskussionen fehlt. Prüfbarkeit ist keine Eigenschaft des Outputs allein, sie hängt am Paar aus Output und Prüfer. Ein Ergebnis, für das kein kompetenter Prüfer existiert, ist unprüfbar, egal wie sauber das Schema aussieht. Daran wird die Fachlichkeit sichtbar: Lärmschutz ist etwas anderes als Verkehrsrecht, andere Regeln, andere Nachweise, andere Erfahrung. Wer seit fünfzehn Jahren Straßensperrungen anordnet, ist bei der Lärmprognose für eine Bühne genauso Laie wie ich. Ein Agent, der beides in einem Urteil formuliert, hat keinen Prüfer für das Ganze. Also zwei Agenten, auch wenn beide formal dasselbe tun: Auflagen formulieren.

Zählt man die Urteile in so einem Genehmigungsverfahren, kommt man auf eine erste Liste. Wohin gehört das Anliegen, und ist es neu oder die Ergänzung zu einem laufenden Antrag. Was fehlt an Unterlagen. Welche Stellen müssen beteiligt werden. Welche Auflagen gelten. Was kostet es. Und am Ende der Bescheid, der per Konstruktion bei einem Menschen bleibt.

Nicht jedes davon braucht ein Modell, und das ist mir wichtig: Nur weil Agenten inzwischen vieles können, heißt das nicht, dass sie alles tun sollten. Alles, was fest definiert und berechenbar ist, wird deterministisch programmiert und verdrahtet, so wie bisher. Die Gebühr ist Satzung mal Fläche mal Tage, das rechnet eine Funktion aus, sobald Fläche und Dauer feststehen, jeden Tag gleich und ohne Modell im Pfad. Agenten gehören dorthin, wo klassische Prozesse nie hingekommen sind, weil die Wirklichkeit am Anfang eines Vorgangs zu unordentlich ist, um sie ohne Menschen in Regeln zu fassen: die formlose Mail, das Foto, die halbe Angabe. Die Frage, ob ein Schritt überhaupt einen Agenten braucht, kommt also vor der Frage, wie groß er wird. Das Kriterium schneidet nur die Schritte, die ohne Modell nicht gehen.

Eine Gerade ist das nicht. Beteiligung und Auflagen hängen wechselseitig voneinander ab: Ob die Feuerwehr eine Stellungnahme abgibt, hängt an Besucherzahl und Aufbauten, und ihre Vorgaben zu Rettungswegen verändern die Fläche, die wieder in die Gebühr eingeht. Und “was fehlt an Unterlagen” ist ein Urteil, das mehrfach fällt, mit Frist, Erinnerung und Teilantwort. Eindeutig ist das Kriterium auch nicht: Auflagen sind mindestens zwei Regelwerke, Lärm und Verkehr. Ob Abfall und Jugendschutz eigene sind oder im allgemeinen Ordnungsrecht mitlaufen, lässt sich nicht aus dem Prozess ablesen. Der Prozess liefert die Kandidaten für Schnitte. Welche man wirklich macht, ist eine Abwägung, denn jeder Schnitt kostet einen Vertrag, ein Schema, einen Monitoring-Punkt und einen Owner. Komplexität muss verdient werden, auch hier.

An jedem Schnitt steht ein Vertrag

Die Agenten in so einer Kette reden nicht miteinander, sie kennen sich nicht einmal. Jeder liest seinen Input aus dem Vorgang, macht seine Arbeit und schreibt sein Ergebnis zurück. Den nächsten Schritt startet nicht der Agent, sondern ein Prozessmanager über der Kette, der selbst kein Modell ist: Er kennt die Reihenfolge, verwaltet Fristen und Wiederholungen und erklärt nachgelagerte Urteile für veraltet, wenn sich ein früheres ändert. Was das Paper über Prüfengstellen sagt, nehme ich für diese Bauform als Hinweis, nicht als Beleg. Gemessen wurde sie dort nicht. Aber wenn Prüfung zwischen den Agenten den Unterschied macht, dann gehört sie an jeden Schnitt, nicht nur einmal in die Mitte.

Was am Schnitt steht, ist ein Agent Contract: Output-Schema, Prompt, erlaubte Tools, Modellwahl und Eval-Set, versioniert als ein Paket. Für die Übergabe zählen daraus drei Dinge. Das Schema fängt Formfehler. Das Eval-Set liefert die Schwelle, ab der ein Ergebnis ohne Menschen weiterlaufen darf. Und Unsicherheit steht als Feld im Ergebnis: Konfidenz, offene Fragen, Belegstellen. Ohne dieses Feld wird aus einer wackligen Einschätzung beim Schnitt eine Tatsache.

Konkret: Der Zuordnungs-Agent schreibt in den Vorgang: Veranstaltung auf öffentlicher Fläche, zuständig das Ordnungsamt, kein Hinweis auf eine Versammlung, Konfidenz hoch. Dazu die Belegstellen, die drei Sätze aus der Mail, aus denen er das gelesen hat. Was er unterwegs erwogen hat und wie sein Prompt aussah, kommt beim nächsten Agenten nicht an. Seine Unsicherheit schon.

Nehmen wir den Fall, dass die Mail offenlässt, ob eine Straßensperrung nötig wird. Der Agent ordnet zu, trägt die Sperrung aber als offene Frage ein, das Schema sieht dieses Feld ausdrücklich vor. Der Vollständigkeits-Agent liest den Datensatz und die Anhänge, und eine offene Frage ist für ihn nichts anderes als ein fehlendes Dokument: Er formuliert die Rückfrage an den Antragsteller. Wäre dagegen die Zuordnung selbst unsicher, etwa weil die Mail nach Versammlung klingt, liegt die Konfidenz unter der Schwelle aus dem Eval-Set, und der Vorgang landet in der Schrittansicht eines Sachbearbeiters, bevor irgendetwas weiterläuft. Zwei Arten von Unsicherheit, zwei Reaktionen, beide im Vertrag festgelegt. Vertrag statt Gespräch.

Zwei Dinge gehören an so einen Schnitt, die man leicht übersieht. Beide hängen an der Übergabe, nicht am einzelnen Agenten.

Idempotenz. Ein Wiederanlauf ist bei einem Sprachmodell ein neues Urteil. Bricht die Kette nach der Zuordnung technisch ab und startet neu, kann derselbe Antrag beim zweiten Mal in einer anderen Abteilung landen, und der Antragsteller bekommt dieselbe Nachforderung zweimal. Dann greift er zum Telefon, und wir sind wieder in Köln. Deshalb trägt jedes Ergebnis einen Schlüssel aus Vorgang und Eingabestand: Ein technischer Wiederholungsversuch findet das alte Ergebnis und nutzt es. Kommt dagegen ein neuer Lageplan nach, ändert sich der Eingabestand, und ein neues Urteil ist genau richtig.

Kompensation. Manche Schritte wirken nach außen: Die Feuerwehr wurde um Stellungnahme gebeten, der Antragsteller angeschrieben. Stellt sich danach heraus, dass die Zuordnung falsch war, lässt sich das nicht zurückrollen wie eine Datenbanktransaktion. Es braucht einen Kompensationspfad, die Bitte zurückziehen, den Antragsteller korrigieren. Solche Schritte gehören in ihren eigenen Agenten mit eigenem Gate, damit die Korrektur selten nötig wird.

Eine Verwechslung noch: Ein Schnitt ist ein Vertrag und kein Genehmigungsschritt. Sonst kommt der Einwand, sechs Agenten bedeuteten sechs Freigaben und die Kette sei damit langsamer als der Sachbearbeiter vorher. Die meisten Übergaben prüft die Maschine. Menschliche Freigaben sitzen nur dort, wo die beiden Achsen aus dem Artikel Die Taube sieht besser sie hinstellen: hoher Schaden, schnell zu beurteilen. Viele Schnitte, wenige Gates.

Und die Prüfansichten

In Agent-First Design habe ich beschrieben, wie ein Interface aussieht, das beim Beurteilen hilft statt beim Erfassen. Auf eine Kette übertragen: pro Urteil eine Schrittansicht, zugeschnitten auf Regelwerk und Prüfer, plus eine Vorgangssicht für den, der den Bescheid am Ende unterschreibt.

Das ist der teure Teil eines Schnitts: Jede Ansicht ist eine Maske in einem Fachverfahren, mit Rollen, Abnahme und Schulung. Eine eigene Ansicht bekommt deshalb nur das Urteil, das Menschen regelmäßig korrigieren müssen. In meinem Kölner Fall wäre das die Zuordnung. Der Rest läuft durch, solange die Konfidenz über der Schwelle aus dem Eval-Set liegt, mit Stichproben.

Erst die Schnitte, dann die Plattform

Die Schnitte sind die Entwurfseinheit, nicht die Plattform. Wer die Plattform vor dem ersten vollständig geschnittenen Prozess entwirft, entwirft für Schnitte, die er noch nicht kennt. Mein Weg: einen Prozess ganz durch, von der Mail bis zum Bescheid, mit allen Urteilen und allen Verträgen, eingebettet in das Fachverfahren, das es schon gibt, mit dessen Rechtemodell. Was die Verträge gemeinsam brauchen, an Register, Eval-Infrastruktur und Protokoll, liest man danach an ihnen ab. Wie man mit Agenten umgeht, die ohne diese Ordnung gewachsen sind, habe ich in AI Systems Architecture: Governance beschrieben.

Die Frage, die ich stellen würde, bevor der erste Agent gebaut wird, ist deshalb nicht, welches Modell und welches Framework. Sie lautet: Welche Urteile enthält dieser Prozess, und wer kann jedes einzelne davon beurteilen?