Die These in einem Satz: ein Multiagentensystem im Unternehmen zu bauen ist in Mode, und es ist fast immer die falsche Antwort. Auf LinkedIn liebt man den Schwarm: fünf, zehn, zwanzig Agenten, die sich die Arbeit aufteilen und Aufgaben herumreichen wie ein menschliches Team. Klingt nach Zukunft. In der Praxis schlägt ein einziger, gut gebauter Agent —mit guten Werkzeugen und durchgehendem Kontext— fast immer eine Armee von Agenten, die sich den schwarzen Peter zuschieben. Mehrere zu orchestrieren hat seinen Moment, aber das ist die Ausnahme, nicht der Ausgangspunkt.
Das Multiagentensystem im Unternehmen: warum es in Mode ist (und warum es fast immer zu viel ist)
Multiagent verkauft sich, weil es eine schöne Geschichte erzählt: wenn ein Agent klug ist, werden viele koordinierte Agenten ein unschlagbares Team. Es ist derselbe Reflex, der uns Organigramme zeichnen lässt —teile und herrsche—. Das Problem: KI-Agenten sind keine Menschen, und was in einem menschlichen Team Delegieren ist, ist zwischen Agenten das Zerschneiden des Kontexts. Jeder Agent, den du hinzufügst, ist eine Kopie, die nur ihren Teil des Problems sieht und den Rest errät. Du vervielfachst die Köpfe und du vervielfachst die Missverständnisse.
Das ist keine Gegenhaltung aus Sport. Cognition —die Leute hinter Devin— hat es in ihrer Technik ohne Umschweife betitelt: baut keine Multiagenten. Ihr Argument: die Architektur paralleler Sub-Agenten ist von Natur aus fragil: indem der Kontext zwischen Agenten isoliert wird, treffen sie Entscheidungen, die sich widersprechen, und das Ergebnis passt nicht zusammen («Don’t Build Multi-Agents», Cognition). Anthropic kommt von anderer Seite zur selben Vorsicht: empfiehlt, mit dem Einfachsten zu beginnen, das funktioniert, und Agenten nur hinzuzufügen, wenn sie messbaren Wert bringen, und warnt, dass ihr eigenes Multiagentensystem rund 15× mehr Tokens verbrauchte als ein normaler Chat, um dasselbe Problem zu lösen («Building Effective Agents», Anthropic).
Warum ein gut gebauter Agent fast immer gewinnt
Die langweilige —und fast immer bessere— Alternative ist ein einziger Agent mit durchgehendem Kontext und guten Werkzeugen. Statt die Arbeit auf fünf Köpfe zu verteilen, die nicht miteinander reden, gibst du einem den ganzen Kontext und die Werkzeuge, um die Arbeit von Anfang bis Ende zu machen. Der Schlüssel ist nicht, wie viele Agenten du hast, sondern was der eine, den du hast, anfassen kann. Ein Agent mit geordnetem Zugang zu deinen Systemen —deinem CRM, deiner E-Mail, deinen Daten— löst mehr als ein blinder Schwarm. Wie man diesen Agenten baut, damit er echter Arbeit standhält, zeigen wir in einen KI-Agenten für Unternehmen bauen, und wovon seine Treffsicherheit abhängt —der Zugang zu deiner Information— in ihn mit deiner eigenen Information trainieren.
Der Qualitätssprung kommt selten davon, Agenten hinzuzufügen; er kommt davon, dem, den du schon hast, gut gestaltete Werkzeuge zu geben. Ein Agent, der deine Datenbank abfragen, ein Ticket öffnen oder eine E-Mail mit klaren, gut typisierten Werkzeugen senden kann, leistet mehr als zehn Agenten, die nur miteinander reden können. Genau das ist der Wandel, den der Standard zur Anbindung von Werkzeugen an Agenten gebracht hat, und warum das zählt, erzählen wir in was MCP ist und warum es Unternehmensagenten verändert. Gute Werkzeuge, ein Agent. Nicht zwanzig einarmige Agenten.
Wann es sich wirklich lohnt, mehrere Agenten zu orchestrieren
Das ist kein striktes Nein zu Multiagent. Es gibt Fälle, in denen die Arbeit zwischen Agenten aufzuteilen die richtige Wahl ist, keine Angeberei. Die Regel ist einfach: du orchestrierst mehrere, wenn sich die Arbeit wirklich in unabhängige Stücke teilen lässt, die nicht bei jedem Schritt miteinander reden müssen.
- Wirklich parallele Aufgaben. Wenn du zwanzig unabhängige Suchen gleichzeitig laufen lassen und dann die Ergebnisse zusammenführen musst, spart das Verteilen auf Agenten Zeit. Die Arbeit teilt sich sauber und setzt sich am Ende wieder zusammen; niemand hängt auf halbem Weg vom Nachbarn ab.
- Spezialitäten, die keinen Kontext teilen. Ein Agent, der schreibt, und ein anderer, der mit anderen Kriterien prüft, können koexistieren, wenn die Grenze zwischen ihnen scharf ist und die Information, die sie sich übergeben, klein und klar ist.
- Isolieren, um Risiko einzudämmen. Manchmal trennst du einen Agenten mit gefährlichen Rechten —Produktion anfassen, Geld bewegen— vom Rest, gerade damit kein anderes Teil auslösen kann, was nur er unter Kontrolle tun soll.
| Situation | Ein gut gebauter Agent | Multiagentensystem |
|---|---|---|
| Sequenzielle Arbeit mit geteiltem Kontext | Gewinnt: durchgehender Kontext, ohne Verluste | Fragil: die Agenten widersprechen sich |
| Unabhängige parallele Aufgaben | Kommt bei der Skalierung ins Stocken | Gewinnt: teilt und setzt wieder zusammen |
| Kosten und Latenz | Niedrig, ein einziger Faden | Hoch: bis zu ~15× mehr Tokens |
| Debugging bei Fehlern | Nachvollziehbar, ein einziger Faden | Undurchsichtig: welcher Agent war’s? |
Die Frage, die die Architektur entscheidet (nicht die LinkedIn-Mode)
Die Entscheidung ist nicht «Multiagent ja oder nein» als Fahne. Sie ist «was ist die einfachste Form, die diese Arbeit löst». Fang mit einem Agenten und guten Werkzeugen an. Wenn er bei echter Skalierung ins Stocken kommt —nicht bei eingebildeter—, dann, und nur dann, orchestrierst du. Die meisten Büroarbeiten —sortieren, schreiben, abgleichen, antworten— erledigt ein gut gebauter Agent locker, wie der administrative KI-Agent, der das Postfach leert, ohne ein Komitee von Bots dahinter. Und wenn die Arbeit mehrere Systeme kreuzt, entscheidet nicht die Zahl der Agenten: es entscheidet, dass jemand den Prozess baut und ihn trägt —genau das leistet die Betriebsautomatisierung.