Warum funktioniert Multi-Agent-Orchestrierung oft nicht gut?

Kürzlich sorgte das Projekt „Paperclip“ für Aufsehen, das es ermöglichen soll, ein „Zero Human Company“ mit AI zu betreiben. Dabei werden Agenten wie in einem Organigramm eines Unternehmens strukturiert, erhalten Rollen wie CEO, Teamleiter und Mitarbeitende, und sobald Mission des Unternehmens sowie detaillierte Projekte definiert sind, beginnen sie selbstständig zu arbeiten. Innerhalb eines Monats überschritt das Projekt 40.000 GitHub-Stars.

Schon davor gab es mit Gastown einen ähnlichen Ansatz, der Agenten als „Stadt“ metaphorisch darstellt, außerdem Anthropics Claude Code Agent Teams und die Cloud-Agenten von Cursor – branchenweit ist der Trend klar erkennbar: „Lasst uns mehrere Agenten wie eine Organisation betreiben.“

Auch ich konnte meiner Neugier auf diesen Trend nicht widerstehen und habe Gastown und Paperclip ausprobiert. Rechnet man die Kosten für API-Tokens zusammen, habe ich etwa 5.000 $ ausgegeben. 🫠
Um das Fazit vorwegzunehmen: Es gab durchaus einzelne Bereiche, in denen der Ansatz wirksam war, aber die Grenzen waren deutlich ausgeprägter.

Die Token-Kosten liegen beim 5- bis 10-Fachen eines einzelnen Agenten, ohne dass die Produktivität proportional steigt. Stattdessen traten immer wieder Probleme auf: Agenten verloren den Kontext, Übergaben brachen mittendrin ab, oder falsche Ergebnisse wurden von ihnen selbst als „abgeschlossen“ markiert. Deshalb habe ich die Probleme, die ich erlebt habe, und die daraus gewonnenen Erkenntnisse zusammengefasst:

→ Drei strukturelle Engpässe der Multi-Agent-Orchestrierung
→ Warum die Metaphern „Stadt“ und „Unternehmen“ oft nicht funktionieren
→ Welche Struktur sich in der Praxis als robust erweist
→ Fünf Kriterien und ein Scoring, um in der eigenen Arbeit zu beurteilen, welche Bereiche sich für die Delegation an Agenten eignen

Ich hoffe, das hilft allen, die sich im Zeitalter der Agenten fragen: „Was sollte man delegieren – und was lieber nicht?“