Wir bauen weniger Agenten, die miteinander sprechen
Das Architekturdiagramm hatte einen Planer, einen Rechercheur, einen Schreiber, einen Kritiker und einen Aufseher. Es funktionierte in dem Sinne, dass hinten etwas herauskam — und wenn die Ausgabe falsch war, konnte niemand sagen, welcher Agent dafür verantwortlich war.
Der Entwurf, der richtig aussah
Fünf Agenten, jeder mit einer Rolle, die sich wie eine Stellenbeschreibung liest, die einander Arbeit weiterreichen. Es ist die Architektur, die alle zuerst zeichnen — teils weil sie darauf abbildet, wie ein Team von Menschen die Aufgabe teilen würde, teils weil sie sich hervorragend vorführen lässt.
Unsere erstellte aus internen Dokumenten einen Bericht über einen Lieferanten. Die Berichte waren flüssig, die Pläne sinnvoll, und etwa jeder sechste enthielt eine Behauptung, die kein Dokument stützte. Diese Behauptung durch fünf gesprächsartige Übergaben zurückzuverfolgen kostete jedes Mal einen Nachmittag.
Wo die Fehler tatsächlich lagen
Cemri und Kollegen veröffentlichten 2025 eine Untersuchung dazu, warum auf Sprachmodellen aufgebaute Multi-Agenten-Systeme scheitern, und ordnen die Fehler in eine Taxonomie über Spezifikation, Fehlausrichtung zwischen Agenten und Verifikation.
Ihre Kategorien gegen unsere eigenen Vorfälle zu lesen war unangenehm, denn fast keiner unserer Fehler bestand darin, dass ein Agent etwas nicht konnte. Es war ein Agent, der eine Zusammenfassung einer Zusammenfassung erhielt, ein Schritt, der eine zwei Übergaben früher genannte Einschränkung voraussetzte, und nichts, was am Ende das Ergebnis prüfte.
Was wir durch Code ersetzt haben
Aus dem Planer wurde eine feste Folge, denn die Aufgabe hat vier Schritte in bekannter Reihenfolge, und ein Modell, das diese Reihenfolge jedes Mal neu entscheidet, ist Streuung ohne Nutzen. Aus dem Aufseher wurde eine Schleife mit Versuchsgrenze. Aus dem Kritiker wurde ein Validator mit Regeln.
Übrig blieben ein Agent für den Abruf und einer für das Schreiben, mit gewöhnlichem Kontrollfluss dazwischen. Die Umstellung dauerte etwa eine Woche, die Quote ungedeckter Behauptungen fiel von einem Sechstel auf unter ein Dreißigstel, und ein Fehler zeigt heute auf einen Schritt statt auf ein Gespräch.
| Komponente | Was daraus wurde |
|---|---|
| Planer | Eine feste Folge im Code |
| Aufseher | Eine Schleife mit Versuchsgrenze |
| Kritiker | Ein Validator mit ausdrücklichen Regeln |
| Rechercheur und Schreiber | Behalten. Zwei Agenten, klare Grenze |
Warum Zusammenfassungen zwischen Agenten das Problem sind
Jede Übergabe verdichtet. Ein Agent, der Arbeit weiterreicht, schickt eine Zusammenfassung dessen, was er getan hat — denn alles zu schicken hebt den Zweck der Trennung auf — und jede Verdichtung verwirft das Detail, das der nächste Schritt gebraucht hätte, ohne zu wissen, dass er es braucht.
Der Fehler ist nicht, dass die Verdichtung schlecht wäre. Er ist, dass der verdichtende Agent nicht wissen kann, was der empfangende benötigt — und in einer fünfstufigen Kette summiert sich der Informationsverlust, bis der letzte Schritt aus einer Beschreibung einer Beschreibung arbeitet.
Wo ein zweiter Agent seinen Platz behält
In zwei Fällen. Wenn der zweite wirklich andere Werkzeuge und einen anderen Rechteumfang hat, etwa ein nur lesender Rechercheagent und ein getrennter Agent, der in ein System schreiben darf — dort ist die Trennung eine Rechtegrenze und keine Arbeitsteilung.
Und wenn die Arbeit von Natur aus parallel und unabhängig ist: fünf Dokumente gleichzeitig von fünf Instanzen zusammengefasst ist in keinem interessanten Sinne ein Multi-Agenten-System — und genau dort ist das Muster schlicht richtig.
Warum das Diagramm so überzeugt
Weil es auf menschliche Organisation abbildet, und menschliche Organisation löst Koordinationsprobleme, die diese Systeme nicht haben. Ein Team von fünf hat gemeinsamen Kontext, informelle Rückfragen und jemanden, der merkt, wenn der Auftrag abgedriftet ist — nichts davon überlebt die Übersetzung in eine Pipeline aus Nachrichten.
Das Diagramm lässt das System außerdem leistungsfähiger aussehen als eine Folge von Schritten, was eher ein Darstellungs- als ein Technikproblem ist. Wir zeichnen im ersten Treffen heute die ehrliche Fassung — weniger beeindruckend, und sie hat uns noch nie einen Auftrag gekostet.
Was wir fragen, bevor wir einen ergänzen
Was kann dieser Agent, was der vorherige nicht kann — an Werkzeugen oder Rechten? Lautet die Antwort nur, dass er eine andere Anweisung hat, ist es ein Schritt in einer Pipeline und sollte als solcher geschrieben werden.
Und was passiert, wenn er sich irrt? Ein Schritt, dessen Ausgabe eine Regel prüft, ist unbedenklich zu ergänzen. Ein Schritt, dessen Ausgabe ein anderes Modell prüft, ist ein zweites Ding, das sich auf korrelierte Weise irren kann — und das ist nicht dasselbe wie Verifikation.
Was wir nicht behaupten
Wir behaupten nicht, Multi-Agenten-Architekturen funktionierten nicht. Für manche Aufgaben tun sie es erkennbar, besonders für offene ohne feste Reihenfolge, und unser Schluss gilt begrenzten Geschäftsabläufen, deren Reihenfolge vorab bekannt ist.
Wir behaupten auch nicht, unsere Quote von einem Dreißigstel sei allein der Architektur zuzuschreiben. Wir haben gleichzeitig den Validator geändert, und diese beiden Wirkungen ehrlich zu trennen hätte ein langsameres Experiment verlangt, als das Projekt sich leisten konnte.