KI-Agenten orchestrieren: Wann du ein Team aus Agenten brauchst — und wann nicht

Jeder KI-Vortrag im Jahr 2026 zeigt das gleiche Diagramm: ein Supervisor-Agent in der Mitte, vier Worker-Agenten drumherum, Pfeile in alle Richtungen, und ein selbstsicherer Sprecher erklärt, dass das die Zukunft ist. Die Diagramme sind real. Manche der Deployments dahinter funktionieren großartig. Aber für die meisten Unternehmen, die uns bei psquared fragen, ob sie ein Multi-Agenten-System bauen sollten, lautet die ehrliche Antwort: wahrscheinlich noch nicht, und möglicherweise nie.

Multi-Agenten-Orchestrierung ist ein mächtiges Pattern — und gleichzeitig eines der am häufigsten überstrapazierten Patterns in der Unternehmens-KI. Teams, die 2024 mit einem einzelnen Chatbot angefangen haben, überspringen den natürlichen nächsten Schritt — diesem Agent bessere Tools zu geben — und springen direkt zu Architekturen, die am Whiteboard beeindruckend aussehen und in Produktion zur Debugging-Hölle werden. In diesem Beitrag geht es darum, wann Orchestrierung wirklich nötig ist und wann du dir nur ein wesentlich größeres Problem einkaufst.

Was "Orchestrierung" eigentlich bedeutet

Die Terminologie ist unscharf. "Multi-Agenten-System" wird auf Architekturen angewendet, die von "ein Agent, der ein paar Funktionen aufruft" bis zu "zwölf Spezial-Agenten, die über einen Forschungsbericht streiten" reichen. Bevor du entscheidest, ob du Orchestrierung brauchst, musst du drei Patterns unterscheiden, die häufig in einen Topf geworfen werden.

Einzelner Agent mit Tools. Ein LLM mit Zugriff auf Funktionen: Datenbank durchsuchen, E-Mail senden, Kundendaten abrufen. Der Agent erledigt das gesamte Reasoning; die Tools sind zustandslose Capabilities. So sieht der Großteil produktiver KI im Jahr 2026 aus — und dieses Pattern deckt ein deutlich breiteres Spektrum an Use Cases ab, als der Agent-Orchestrierungs-Hype suggeriert.

Sequenzielle Pipeline. Mehrere spezialisierte LLM-Schritte in einer festen Reihenfolge: extrahieren → klassifizieren → zusammenfassen → entwerfen. Jeder Schritt ist klein, fokussiert und für genau eine Aufgabe geprompted. Kein "Agent" entscheidet, was als Nächstes passiert — der Orchestrator ist dein Code. Verlässlich, vorhersehbar, einfach zu debuggen. Eigentlich kein Multi-Agenten-System, auch wenn es oft so genannt wird.

Echte Multi-Agenten-Orchestrierung. Mehrere Agenten, jeder mit eigenem Kontext, eigenen Zielen und eigenem Tool-Zugriff, die dynamisch entscheiden, wie sie zusammenarbeiten. Ein Supervisor delegiert; Worker liefern Ergebnisse zurück; der Supervisor entscheidet, ob die Antwort fertig ist oder ob nochmal iteriert wird. Der Kontrollfluss entsteht zur Laufzeit, ist nicht im Code festgelegt. Das ist, was Leute normalerweise meinen, wenn sie "agentic" sagen.

Der mit Abstand häufigste Fehler, den wir sehen: Teams greifen zum dritten Pattern, obwohl das erste oder zweite das Problem zuverlässiger und mit einem Bruchteil des Betriebsaufwands lösen würde.

Wann ein einzelner Agent ausreicht

Ein einzelnes LLM mit einem gut designten Tool-Set leistet mehr, als die meisten Architekten annehmen. Wenn du einen Chatbot gebaut hast, der auch einen CRM-Eintrag anlegen, einen Bestellstatus abfragen und eine E-Mail auslösen kann — das ist ein Agent. Er wird nicht mächtiger dadurch, dass du ihn in drei kleinere Agenten aufspaltest, die jeweils eines davon machen. Er wird nur schwerer zu debuggen.

Das Signal, dass ein einzelner Agent reicht: die Aufgabe lässt sich als ein kohärentes Ziel mit klaren Teilschritten beschreiben, zwischen denen der Agent zur Laufzeit entscheidet. "Hilf diesem Kunden" ist ein Ziel. "Kategorisiere diese E-Mail und antworte passend" ist ein Ziel. "Schreibe einen Projekt-Status, indem du aus Linear, GitHub und Slack ziehst" ist ein Ziel, auch wenn drei Tools berührt werden.

Wo einzelne Agenten an ihre Grenzen kommen: bei paralleler Arbeit und bei Reasoning-Tiefe über verschiedene Domänen. Ein einzelner Agent hat einen Context Window, eine Gedankenkette, eine Historie. Wenn deine Aufgabe wirklich drei unabhängige Arbeitsstränge erfordert, die später zusammenfließen — drei Wettbewerber parallel recherchieren, drei Ansätze gleichzeitig bewerten, drei Varianten generieren und die beste auswählen — wird ein einzelner Agent das langsam und oft schlecht machen. Das ist das erste echte Signal, dass Orchestrierung ihre Komplexität rechtfertigen könnte.

Wann Orchestrierung wirklich hilft

Es gibt konkrete Situationen, in denen mehrere Agenten einen einzelnen gut ausgerüsteten Agent deutlich übertreffen. Das Pattern ist konsistent: Aufgaben, die von Parallelität, Expertise-Trennung oder echter adversarialer Prüfung profitieren.

Parallele Recherche und Synthese. Wenn die Aufgabe "untersuche N unabhängige Stränge und kombiniere die Ergebnisse" lautet, glänzen Multi-Agenten-Systeme. Ein Supervisor zerlegt die Frage in Teilfragen, schickt Worker parallel los und synthetisiert die Ergebnisse beim Zurückkommen. Das komprimiert eine ansonsten sequenzielle 5-Minuten-Reasoning-Kette auf eine 90-Sekunden-Parallel-Variante. Anthropic hat in eigener Forschung gezeigt, dass Multi-Agenten-Suche etwa 90 % Performance-Lift gegenüber Einzel-Agenten auf solchen Aufgaben bringt — und der Speedup ist mindestens so wichtig wie der Qualitätsgewinn.

Echte Domänen-Trennung. Wenn deine Aufgabe Expertise erfordert, die sich gegenseitig widerspricht — ein Schreiber-Agent und ein Kritiker-Agent, ein Planer und ein Coder, ein Kreativer und ein Lektor — liefert das Aufteilen in separate Agenten mit unterschiedlichen System-Prompts oft bessere Ergebnisse, als einen einzelnen Agent zu bitten, alle Rollen gleichzeitig zu spielen. Der Grund ist banal: Prompts, die einen Einzelagent auffordern, "kreativ UND gleichzeitig streng selbstkritisch" zu sein, kollabieren in beiden Richtungen zu Mittelmäßigkeit. Aufgeteilt kann jeder Agent voll in seine Rolle gehen.

Lange Aufgaben, bei denen der State den Kontext sprengen würde. Ein einzelner Agent, der eine 4-Stunden-Recherche durchführt, füllt sein Context Window mit Zwischennotizen und verliert dabei zunehmend die Kohärenz. Ein Supervisor-Worker-Pattern lässt jeden Worker mit sauberem Kontext für seine Teilaufgabe laufen und nur eine strukturierte Zusammenfassung zurückgeben — der Kontext des Supervisors bleibt schlank. Das ist strukturell, nicht stilistisch — der Unterschied zwischen einem System, das funktioniert, und einem, das still vor sich hin degradiert.

Adversariale Review. Wenn du wirklich eine Prüfung des Primär-Outputs brauchst — eine Security-Review von generiertem Code, eine Compliance-Prüfung einer Kunden-Nachricht, ein Fact-Check einer Synthese — liefert ein separater Reviewer-Agent mit eigenem Prompt und möglicherweise eigenem Modell deutlich bessere Treffer als der Versuch, den ursprünglichen Agent zur Selbst-Review zu zwingen. Self-Review erzeugt nachweislich falsches Vertrauen; Cross-Agent-Review durchbricht das.

Die operativen Kosten, die fast alle Architekten unterschätzen

Die Diagramme lassen Multi-Agenten-Systeme wie eine Architektur-Entscheidung aussehen. In Produktion sind sie ein operatives Commitment. Drei Dinge ändern sich beim Übergang von Einzel- zu Multi-Agent, die zur Design-Zeit nicht sichtbar sind.

Die Kosten steigen, oft um Faktor 5–15. Anthropics eigenes Engineering-Team berichtet, dass Multi-Agenten-Systeme rund 15× die Tokens einer einzelnen Chat-Interaktion verbrauchen, weil jeder Sub-Agent ein eigenes Context Window, eigenen Prompt-Overhead und eigenes Zwischen-Reasoning hat. Eine einzelne Konversation, die als Ein-Agent-System €0,05 Token kostet, kann als Vier-Agenten-System leicht €0,50 kosten. Bei High-Volume-Workloads entscheidet das über tragfähig versus nicht.

Debugging wird zum Distributed-Systems-Problem. Wenn bei einem einzelnen Agent etwas schiefläuft, schaust du dir den Trace an, findest den schlechten Reasoning-Schritt und korrigierst den Prompt oder das Tool. Wenn bei einem Fünf-Agenten-System etwas schiefläuft, hast du fünf Traces, musst herausfinden, welcher Agent die schlechte Entscheidung getroffen hat und warum — und die Antwort ist oft: "Agent A hat zu wenig Kontext an Agent B übergeben, der dann auf Basis unvollständiger Information eine eigentlich vernünftige Entscheidung getroffen hat." Die Debugging-Komplexität wächst überproportional mit der Anzahl der Agenten.

Evals werden schwieriger. Einen einzelnen Agent auf einem Benchmark zu evaluieren ist relativ machbar. Ein Multi-Agenten-System zu evaluieren erfordert Tests für jeden Agent isoliert, Tests für die Orchestrierungs-Logik und End-to-End-Tests für das Gesamtsystem. Teams, die das nicht einbudgetieren, deployen Multi-Agenten-Systeme ohne echte Test-Abdeckung und werden in Produktion regelmäßig überrascht.

Für ein erfahrenes Engineering-Team mit Kapazität ist das machbar. Für ein kleines Team mit einem ML-Engineer und einer Deadline ist es oft der Unterschied zwischen Shippen und Nicht-Shippen. Die ehrliche Frage vor der Orchestrierungs-Entscheidung: haben wir die operative Reife, das in drei Monaten zu debuggen?

Ein praktisches Entscheidungs-Framework

Wenn ein Kunde mit einem Use Case zu uns bei psquared kommt, gehen wir eine kurze Reihe von Fragen durch, bevor wir eine Architektur empfehlen. Sie sind nicht exotisch — es sind die Fragen, die sich jedes Team selbst stellen sollte.

Erstens: lässt sich die Aufgabe von einem einzelnen Agent mit den richtigen Tools lösen? Die meisten lassen sich so lösen. Wenn du die Aufgabe als "der Agent ruft Tool X auf, dann je nach Antwort Tool Y, dann eventuell Tool Z" beschreiben kannst, ist das ein Einzel-Agent-Workload. Greife nicht zur Orchestrierung, nur weil sie gerade modern ist.

Zweitens: enthält die Aufgabe echte parallele Arbeit? Nicht "könnte parallel gemacht werden" — "profitiert substanziell davon, parallel gemacht zu werden." Wenn die Sub-Tasks unabhängig sind und der Nutzer auf das Ergebnis wartet, ist Parallelität die operativen Kosten wert. Wenn die Sub-Tasks sequenziell sind oder die Zeitersparnis marginal ist, meistens nicht.

Drittens: erfordert die Aufgabe Domänen-Trennung, die ein einzelner Prompt nicht vernünftig abbilden kann? "Schreibe Code, dann prüfe ihn kritisch auf Security-Issues" ist ein echter Kandidat für Orchestrierung, weil die beiden Rollen im Konflikt stehen. "Schreibe Code, der User-Input verarbeitet" ist es nicht — das ist eine einzelne Rolle mit Teilschritten.

Viertens: ist das Team operativ bereit dafür? Hier braucht es eine ehrliche Antwort. Wenn dein Team noch herausfindet, wie man einen einzelnen LLM-Call in Produktion monitort, ist Orchestrierung nicht der richtige nächste Schritt. Erst operative Reife auf einfacheren Architekturen aufbauen.

Fünftens: was ist die Kostenobergrenze? Multi-Agenten-Systeme können 90 % Performance-Lift bei Research-Aufgaben liefern. Sie kosten 15× die Tokens dafür. Das ist ein hervorragender Trade-off bei wertvollen Recherche-Workloads, bei denen jeder Output €50+ an menschlicher Zeit wert ist. Es ist ein schlechter Trade-off bei einem Kundensupport-Bot, bei dem jede Konversation €2 wert ist und du die Unit-Economics knapp halten musst.

Was wir tatsächlich empfehlen

Für die meisten Unternehmen, mit denen wir arbeiten — KMU und Mittelstand im DACH-Raum — empfehlen wir, mit einem einzelnen gut ausgerüsteten Agent für die ersten 6–12 Monate jedes KI-Deployments zu starten. Die Tools richtig hinbekommen. Die Eval-Pipeline richtig aufsetzen. Das Monitoring richtig aufbauen. Die meisten Produktionsprobleme mit KI im Jahr 2026 sind nicht architektonisch — es geht darum, zu verstehen, was der Agent auf echtem Traffic tatsächlich tut.

Wenn wir Orchestrierung empfehlen, geht es meistens um eine von drei konkreten Situationen: ein research-lastiges internes Tool, bei dem parallele Untersuchung wirklich Zeit spart; ein Content-Workflow, bei dem redaktionelle Review die Qualität messbar verbessert; oder ein mehrstufiger Geschäftsprozess (Intake → Anreicherung → Routing → Antwort), bei dem jede Stufe von einem fokussierten, separat tunbaren Agent profitiert. In jedem dieser Fälle rechtfertigt die Orchestrierung ihre Komplexität, weil sie ein Problem löst, das ein einzelner Agent nachweislich nicht konnte.

Die Zukunft der Unternehmens-KI ist tatsächlich agentic — aber in dem gleichen Sinn, in dem die Zukunft des Cloud Computing Kubernetes war. Kubernetes hat sich durchgesetzt, aber die meisten Workloads laufen weiterhin problemlos auf einer Managed Postgres und einem containerisierten Web-Service. Wähle die einfachere Architektur, bis der Use Case wirklich die komplexere verlangt. Dein Debugging-Ich in sechs Monaten wird es dir danken.

Das Fazit

Agenten-Orchestrierung ist real, und sie löst echte Probleme. Sie wird auch auf Probleme angewendet, die sie nicht brauchen, von Teams, die nicht bereit dafür sind, zu Kosten, die nicht aufgehen. Die richtige Frage lautet nie "sollten wir ein Multi-Agenten-System bauen?" — sondern "was ist die einfachste Architektur, die dieses Problem löst, und was müsste sich ändern, damit wir die komplexere Variante wirklich wollen?"

In den meisten Fällen lautet die Antwort: ein einzelner Agent mit guten Tools, ordentlich monitoriert, mit einer soliden Eval-Pipeline. Bring das zuerst zum Laufen. Der Rest wird offensichtlich, wenn das Problem ihn wirklich verlangt.