Die Frage, die nach der Entscheidung einer Organisation für den Aufbau von Multi-Agent-Systemen mit einem Pro-Code-Ansatz immer kommt, ist dieselbe: Welches Framework sollen wir verwenden? AutoGen, LangGraph, CrewAI, das Claude Agent SDK — die Landschaft hat vier ernstzunehmende Kandidaten, jeder mit unterschiedlicher Designphilosophie, unterschiedlichen Stärken und überzeugten Befürwortern, die darauf bestehen, dass ihre Wahl die richtige ist. Die Framework-Vergleichsartikel sind zahlreich. Die meisten liegen falsch — nicht bei den Frameworks, sondern bei dem, was tatsächlich zählt.
Die Framework-Wahl ist eine Entscheidung zweiter Ordnung. Sie bestimmt das Programmiermodell und die Abstraktionen, mit denen Sie arbeiten. Sie bestimmt nicht, ob Ihr Multi-Agent-System Unternehmenswert erzeugt. Fünf architektonische Entscheidungen bestimmen das: wie Ihre Agents kommunizieren und koordinieren (Orchestrierungsdesign), wie sie Wissen aufbauen und teilen (Memory-Architektur), wie sie gesteuert und eingeschränkt werden (Governance-Schicht), wie sie Modelle auswählen und routen (Model-Routing), und wie Sie sie in Produktion überwachen und debuggen (Observability). Treffen Sie diese fünf richtig, und jedes seriöse Framework wird liefern. Treffen Sie sie falsch, und kein Framework wird Sie retten.
Das ist keine Behauptung, dass Frameworks austauschbar wären. Das sind sie nicht — und dieser Artikel behandelt die relevanten Unterschiede. Aber die Architektur steht über dem Framework, und die Architektur ist der Ort, an dem Multi-Agent-Systeme auf Enterprise-Ebene gelingen oder scheitern.
Orchestrierungsdesign: Wie Agents koordinieren
Orchestrierungsdesign ist die Entscheidung darüber, wie Agents kommunizieren, State teilen und Konflikte lösen. Drei Muster dominieren Enterprise-Multi-Agent-Systeme, und die richtige Wahl hängt vom zu automatisierenden Workflow ab, nicht von Framework-Präferenzen.
Hub-and-Spoke-Orchestrierung platziert einen zentralen Orchestrator-Agent, der alle Anfragen empfängt, Intent interpretiert und an spezialisierte Sub-Agents weiterleitet. Der Orchestrator pflegt den Master-Kontext, und Sub-Agents melden ihre Ergebnisse zurück. Dies ist das Muster, das Copilot Studio nativ implementiert, und es ist das richtige Muster für Customer-Service-Routing (ein Orchestrator, fünf bis zehn spezialisierte Agents), Document-Processing-Pipelines (ein Router, spezialisierte Extraktoren) und jeden Workflow, bei dem die Koordinationslogik relativ einfach ist und die Spezialisierung in der Ausführung liegt, nicht in der Koordination.
Die Einschränkung von Hub-and-Spoke ist, dass der Orchestrator zum Engpass wird — jede Interaktion läuft durch ihn, er muss die Fähigkeiten jedes Sub-Agents verstehen, und sein Context Window muss die gesamte Gesprächshistorie aufnehmen. Wenn die Zahl der Sub-Agents über fünfzehn bis zwanzig hinauswächst, verschlechtert sich die Routing-Genauigkeit des Orchestrators. Noch wichtiger: Sub-Agents können nicht direkt miteinander kommunizieren, was die kollaborativen Muster verhindert, die den höchsten Wert erzeugen.
Peer-to-Peer-Orchestrierung erlaubt Agents, direkt miteinander zu kommunizieren, ohne zentralen Koordinator. Jeder Agent weiß, an welche anderen Agents er delegieren oder die er konsultieren kann, und der Kommunikationsgraph kann dynamisch sein — Agents können andere Agents basierend auf den Aufgabenanforderungen entdecken und aufrufen. Dieses Muster ermöglicht die iterativen Reasoning-Loops — Research-Validierung-Verfeinerung-Zyklen, Multi-Agent-Debatte, Konsensbildung — die fortgeschrittene Multi-Agent-Systeme definieren.
Peer-to-Peer ist das richtige Muster, wenn Agents die Outputs der anderen hinterfragen, verfeinern und aufeinander aufbauen müssen. Ein Due-Diligence-System, bei dem ein Research-Agent, ein Financial-Analysis-Agent und ein Legal-Review-Agent jeweils Ergebnisse beisteuern und gegenseitig validieren, ist von Natur aus Peer-to-Peer — kein einzelner Orchestrator kann den multidirektionalen Informationsfluss und die iterative Verfeinerung managen, die zuverlässige Ergebnisse produzieren.
Die Herausforderung der Peer-to-Peer-Orchestrierung ist Governance. Ohne zentralen Koordinator erfordert die Nachvollziehbarkeit, wer was entschieden hat — und warum — explizites Logging und Audit-Trails an jedem Agent-zu-Agent-Kommunikationspunkt. Dies ist der Hauptgrund, warum die meisten Enterprise-Implementierungen mit Hub-and-Spoke beginnen und sich in Richtung Peer-to-Peer weiterentwickeln, wenn ihre Governance-Infrastruktur reift.
Hierarchische Orchestrierung kombiniert Elemente beider Ansätze. Ein Top-Level-Orchestrator delegiert an Team-Leads, von denen jeder eine Gruppe spezialisierter Agents koordiniert. Das Financial-Analysis-Team hat einen Team-Lead, der Analyst-, Researcher- und Risk-Assessment-Agents koordiniert. Das Legal-Review-Team hat einen Team-Lead, der Contract-Review-, Regulatory-Compliance- und IP-Assessment-Agents koordiniert. Der Top-Level-Orchestrator koordiniert zwischen Teams, nicht zwischen einzelnen Agents.
Dieses Muster skaliert besser als flaches Hub-and-Spoke, weil jeder Team-Lead nur seine eigenen Agents verstehen muss und der Top-Level-Orchestrator nur Teams verstehen muss, nicht individuelle Fähigkeiten. Es ist das Muster, das am ehesten widerspiegelt, wie große Organisationen tatsächlich Arbeit koordinieren — Abteilungen mit Managern, die Spezialisten koordinieren, die an Führungskräfte berichten, die Abteilungen koordinieren.
Memory-Architektur: Wie Agents lernen
Memory-Architektur ist die Entscheidung, die am direktesten bestimmt, ob ein Multi-Agent-System linearen oder kumulierenden Wert erzeugt. Es ist auch die Entscheidung, in die die meisten Organisationen zu wenig investieren, weil sie keine unmittelbar sichtbare Auswirkung hat — ein System ohne Shared Memory funktioniert bei den ersten hundert Interaktionen einwandfrei. Es schafft es nicht, über die ersten tausend hinweg Wert zu kumulieren.
Isoliertes Memory bedeutet, dass jeder Agent seinen eigenen Kontext und seine eigene Historie pflegt. Wenn der Sales-Agent erfährt, dass ein Kunde einen bestimmten Pain Point hat, bleibt dieses Wissen beim Sales-Agent. Der Support-Agent, der die nächste Interaktion desselben Kunden bearbeitet, startet ohne diesen Kontext. Isoliertes Memory ist einfach zu implementieren, hat keinen Koordinations-Overhead und ist der Standard in den meisten Frameworks. Es ist auch die Architektur, die den Level-1-Tool-Level-Wert erzeugt, den McKinsey, BCG und Bain durchgängig als unzureichend für bedeutsame EBIT-Wirkung identifizieren.
Shared Memory bedeutet, dass Agents aus einer gemeinsamen Wissensbasis lesen und in sie schreiben. Die Entdeckung des Sales-Agents über den Pain Point des Kunden wird in das Shared Memory geschrieben. Wenn der Support-Agent die nächste Interaktion bearbeitet, liest er diesen Kontext und reagiert entsprechend. Wenn der Agent des Produktteams Feature-Requests analysiert, kann er das Shared Memory nach Mustern über alle Kundeninteraktionen abfragen, nicht nur über die, an denen er teilgenommen hat.
Shared Memory ist der Ort, an dem Wissen kumuliert. Aber es führt schwierige Designprobleme ein: Concurrency (was passiert, wenn zwei Agents gleichzeitig widersprüchliche Informationen schreiben), Relevanz (wie ruft ein Agent nur das Memory ab, das für seine aktuelle Aufgabe relevant ist, nicht die gesamte Historie), Decay (wie geht das System mit veraltetem Wissen um), und Privacy (welche Agents sollen Zugriff auf welche Memories haben, insbesondere wenn das Wissen Kundendaten enthält, die den Datenschutzanforderungen unterliegen).
Persistenzstrategie bestimmt, ob Memory über eine einzelne Session hinaus erhalten bleibt. Session-basiertes Memory (der Standard in den meisten Frameworks) bedeutet, dass der gesamte Kontext verloren geht, wenn die Konversation endet. Persistentes Memory bedeutet, dass während einer Interaktion aufgebautes Wissen in der nächsten verfügbar ist, über Tage, Wochen und Monate hinweg. Das im Architektur-Entscheidungsartikel beschriebene Financial-Multi-Agent-System — bei dem Agents ein Kanban-Board mit laufenden Findings, Vorschlägen und getrackten Issues pflegen — benötigt persistentes Shared Memory. Ohne dieses kann das System kein Wissen über die Zeit kumulieren, und das zentrale Wertversprechen bricht zusammen.
Das praktische Implementierungsmuster, das auf Enterprise-Ebene funktioniert, ist ein gestufter Ansatz: Kurzzeit-Memory (der aktuelle Konversationskontext), Mittelzeit-Memory (die aktuelle Session oder Aufgabe) und Langzeit-Memory (die persistente Wissensbasis, die über alle Interaktionen hinweg bestehen bleibt). Jede Stufe hat unterschiedliche Retrieval-Strategien, unterschiedliche Speicheranforderungen und unterschiedliche Governance-Regeln.
Governance-Schicht: Wer entscheidet was
Die KI-Entscheidungsarchitektur, die für einzelne KI-Systeme gilt, wird in Multi-Agent-Umgebungen exponentiell komplexer, weil Entscheidungen aus Interaktionen zwischen Agents entstehen statt aus einem einzelnen System. Ein gut gesteuertes Multi-Agent-System erfordert drei Arten von Regeln, implementiert als Systemeinschränkungen statt als Policy-Dokumente.
Delegationsregeln definieren, was jeder Agent eigenständig entscheiden kann, was die Bestätigung eines anderen Agents erfordert und was menschliche Freigabe benötigt. Ein Procurement-Agent kann Einkäufe unter 5.000 € ohne menschliche Beteiligung genehmigen. Zwischen 5.000 € und 50.000 € muss der Compliance-Agent bestätigen, dass der Einkauf den Policy-Anforderungen entspricht. Über 50.000 € muss ein menschlicher Entscheider freigeben. Diese Schwellenwerte sind keine Empfehlungen — sie sind harte Einschränkungen, die im Code erzwungen werden.
Eskalationsregeln definieren, was passiert, wenn Agents auf Situationen außerhalb ihrer operativen Grenzen stoßen. Ein autonomer Monitoring-Agent, der eine Anomalie erkennt, für die er nicht konzipiert wurde, muss eskalieren — nicht versuchen, sie zu lösen. Der Eskalationspfad muss explizit sein: welcher Agent die Eskalation empfängt, welche Informationen übergeben werden und was passiert, wenn die Eskalation nicht innerhalb eines definierten Zeitfensters bestätigt wird. Implizite Eskalation — bei der Agents versuchen, Situationen jenseits ihrer Fähigkeiten zu handhaben, weil keine explizite Grenze gesetzt wurde — ist der häufigste Fehlermodus in Multi-Agent-Systemen und der teuerste in der Behebung.
Grenzregeln definieren, was Agents ausdrücklich verboten ist. Ein kundenorientierter Agent kann keine Preiszusagen machen, die die Pricing-Engine überschreiben. Ein Supply-Chain-Agent kann keine Liefertermine zusagen, die das Logistiksystem nicht erfüllen kann. Ein Compliance-Agent kann Risiken markieren, aber seine eigenen Risikobewertungen nicht genehmigen — ein anderer Agent oder ein Mensch muss bestätigen. Grenzregeln verhindern den Fehlermodus, bei dem lokal optimale Agent-Entscheidungen global schädliche Ergebnisse produzieren.
Die Governance-Frameworks für mittelständische Unternehmen gelten direkt für Multi-Agent-Systeme, aber mit einer zusätzlichen Komplexitätsebene: Governance muss nicht nur individuelle Agent-Entscheidungen abdecken, sondern das emergente Verhalten des Gesamtsystems. Ein Multi-Agent-System, bei dem jeder einzelne Agent innerhalb seiner Governance-Grenzen operiert, kann trotzdem ungesteuerte Ergebnisse produzieren, wenn die Interaktion zwischen Agents nicht explizit gesteuert wird. Dies ist die Governance-Lücke, die McKinsey als primäre Barriere für die Skalierung von Agentic AI identifiziert — fast zwei Drittel der Organisationen haben keine Governance-Frameworks für autonome Agent-Systeme.
Model-Routing: Fähigkeit und Kosten abgleichen
Model-Routing ist die Entscheidung darüber, welches KI-Modell welche Aufgabe innerhalb des Multi-Agent-Systems übernimmt. Es ist eine ökonomische Entscheidung ebenso wie eine technische, und die richtige Umsetzung kann Inferenzkosten um 60 bis 80 Prozent senken, bei gleichbleibender oder verbesserter Outputqualität.
Das Prinzip ist einfach: Nutzen Sie das günstigste Modell, das die Qualitätsanforderung für jede spezifische Aufgabe erfüllt. Ein Triage-Agent, der eingehende Anfragen in fünf Kategorien einteilt, braucht kein Frontier-Modell — ein kleines, schnelles Modell wie Claude Haiku oder GPT-4o mini bewältigt die Klassifikation zu einem Bruchteil der Kosten bei vergleichbarer Genauigkeit. Ein Reasoning-Agent, der komplexe Finanzszenarien analysiert und Empfehlungen generiert, braucht ein Frontier-Modell — Claude Opus oder GPT-4 — weil die Reasoning-Qualität direkt den Outputwert bestimmt. Ein Code-Generation-Agent profitiert von einem speziell für Code trainierten Modell.
In der Praxis führt Model-Routing drei Komplexitätsquellen ein. Die Latenz variiert zwischen Modellen, und der Wechsel von Modellen innerhalb einer Aufgabe führt zu variablen Antwortzeiten, die die Nutzererfahrung und das Koordinationstiming zwischen Agents beeinflussen. Prompt-Formate und System-Prompts müssen möglicherweise angepasst werden, wenn zwischen Modellfamilien gewechselt wird — ein für Claude optimierter Prompt kann bei GPT schlechter abschneiden und umgekehrt. Und Fallback-Logik ist notwendig — wenn eine Model-API nicht verfügbar oder ratenlimitiert ist, muss das System elegant auf eine Alternative routen, ohne Kontext zu verlieren oder inkonsistente Ergebnisse zu produzieren.
Der ökonomische Case für Model-Routing ist überzeugend. Ein Enterprise-Multi-Agent-System, das zehntausend Interaktionen pro Tag verarbeitet, bei dem jeder Agent ein Frontier-Modell nutzt, gibt fünf- bis zehnmal mehr für Inferenz aus als ein identisches System, bei dem Triage ein kleines Modell nutzt, Routineaufgaben ein Mid-Tier-Modell und nur komplexe Reasoning-Aufgaben ein Frontier-Modell. Die Inferenzkosten-Analyse behandelt die Ökonomie im Detail. In Multi-Agent-Systemen multiplizieren sich die Einsparungen, weil die Zahl der LLM-Aufrufe pro Nutzerinteraktion höher ist — jeder Agent in der Kette macht eigene Aufrufe, und eine Pipeline mit fünf Agents bedeutet fünfmal die Gelegenheit zur Kostenoptimierung durch Model-Routing.
Observability: Überwachen, was man nicht sieht
KI in Produktion zu überwachen ist bei Single-Model-Systemen herausfordernd. Bei Multi-Agent-Systemen ist es eine Größenordnung komplexer, weil Fehler an jedem Punkt der Agent-Kette auftreten können und die Ursache eines schlechten Ergebnisses mehrere Agents vom Symptom entfernt liegen kann.
Decision Tracing bedeutet, nicht nur den finalen Output aufzuzeichnen, sondern die Reasoning-Kette, die ihn produziert hat. Wenn der Procurement-Agent eine Bestellung genehmigt, die sich später als Policy-Verstoß herausstellt, müssen Sie zurückverfolgen: welcher Agent die Bestellung als konform markiert hat, auf welchen Daten diese Bewertung basierte, welche anderen Agents konsultiert wurden und wo in der Kette der Fehler aufgetreten ist. Ohne Decision Tracing ist das Debugging von Multi-Agent-Systemen im Grunde Ratespiel.
Confidence Monitoring bedeutet, die Konfidenzwerte der Outputs jedes Agents zu tracken und zu alarmieren, wenn die Konfidenz unter definierte Schwellenwerte fällt. Ein Agent, der plötzlich Outputs mit niedriger Konfidenz produziert, kann auf Modelldegradation, Datenqualitätsprobleme oder Veränderungen in der Input-Verteilung hindeuten, für die der Agent nicht konzipiert war. In einem Multi-Agent-System propagiert ein Output mit niedriger Konfidenz eines Agents durch die Kette — die nachgelagerten Agents treffen Entscheidungen auf Basis unsicherer Inputs, und die Unsicherheit kumuliert.
Performance Monitoring bedeutet, Latenz, Durchsatz und Fehlerraten pro Agent und pro Agent-Kette zu tracken. Eine Multi-Agent-Pipeline, die eine Kundenanfrage durch fünf Agents verarbeitet, kann je nachdem, welche Agents aufgerufen werden, welche Modelle sie nutzen und ob externe API-Aufrufe beteiligt sind, zwischen zwei Sekunden und dreißig Sekunden dauern. Zu verstehen, wo Zeit verbracht wird — und wo Spitzen auftreten — ist entscheidend für die Aufrechterhaltung akzeptabler Antwortzeiten bei der Skalierung des Systems.
Cost Monitoring bedeutet, Inferenzkosten pro Agent, pro Kette und pro Use Case zu tracken. Ohne Cost Monitoring wachsen Inferenzkosten unsichtbar, bis sie als Posten in der vierteljährlichen Cloud-Rechnung erscheinen. Model-Routing optimiert Kosten zur Designzeit. Cost Monitoring stellt sicher, dass diese Optimierungen halten, während sich Nutzungsmuster entwickeln.
Die Framework-Landschaft — richtig eingeordnet
Mit den fünf architektonischen Entscheidungen definiert, wird die Framework-Wahl zur praktischen Frage: Welches Framework bietet die besten Abstraktionen für Ihr spezifisches Orchestrierungsmuster, Ihre Memory-Architektur, Governance-Anforderungen, Model-Routing-Strategie und Observability-Bedürfnisse? Die vier führenden Frameworks haben jeweils echte Stärken und echte Einschränkungen.
AutoGen (Microsoft Research) zeichnet sich bei Tool Use, Code Execution und strukturierter Multi-Agent-Koordination aus. Das v1.0-Release in 2026 führte eine eventbasierte Architektur ein, die die Produktionszuverlässigkeit verbessert. Enterprise-Teams arbeiten typischerweise auf drei Ebenen: AgentChat für High-Level-Konversationsmuster und schnelles Prototyping, Core für Low-Level-Primitives, wenn AgentChat-Abstraktionen nicht ausreichen, und Studio für visuelle Interfaces und Stakeholder-Demos. AutoGen ist die natürliche Wahl für Microsoft-nahe Unternehmen, die ein Pro-Code-Framework wollen und dabei im Microsoft-Ökosystem bleiben möchten. Die Einschränkung ist, dass das konversationsbasierte Modell das Debugging erschweren kann — Agents treffen dynamisch Entscheidungen, und die Reproduktion von Fehlern erfordert die Rekonstruktion des exakten Konversationszustands, der zum Fehler geführt hat.
LangGraph (LangChain) modelliert Agents als Knoten in einem gerichteten Graph mit bedingten Kanten und Shared State. Es zeichnet sich bei zustandsbehafteten Workflows, zyklischen Prozessen und langlebigen Operationen aus. Das Checkpointing-System ermöglicht Human-in-the-Loop-Unterbrechungen und automatische Retries ohne Fortschrittsverlust, was das Produktions-Deployment vorhersehbarer macht. LangGraph ist die stärkste Wahl für komplexe Workflows mit Verzweigungslogik, bedingten Pfaden und State-Persistenz-Anforderungen. Die Einschränkung ist Komplexität — das graphbasierte Modell ist leistungsfähig, hat aber eine steilere Lernkurve als konversationsbasierte Frameworks, und einfache Use Cases wirken überengineered.
CrewAI nutzt rollenbasierte Agent-Teams, bei denen jeder Agent eine definierte Rolle, ein Ziel und einen Hintergrund hat. Aufgaben werden Agents basierend auf ihren Rollen zugewiesen, und das Framework übernimmt Delegation und Koordination. CrewAI ist der schnellste Weg vom Konzept zum funktionierenden Multi-Agent-System für Business-Process-Automation — definieren Sie die Rollen, definieren Sie die Aufgaben, und das Framework orchestriert. Die Einschränkung ist architektonische Tiefe — das rollenbasierte Modell ist intuitiv, bietet aber weniger feingranulare Kontrolle über Orchestrierungsmuster, Memory-Management und Model-Routing als LangGraph oder AutoGen.
Claude Agent SDK (Anthropic) bietet native Tool Use, Extended Thinking für komplexes Reasoning und Computer Use Capabilities. Es hat in Enterprise-Deployments erheblich an Bedeutung gewonnen, insbesondere für Use Cases, bei denen Reasoning-Tiefe die Outputqualität bestimmt. Die Stärke liegt bei Deep-Reasoning-Aufgaben und autonomen Workflows, bei denen die Qualität jedes Agent-Outputs kritisch ist — die Extended-Thinking-Fähigkeit erlaubt Agents, komplexe Probleme durchzudenken, bevor sie Outputs produzieren. Die Einschränkung ist das Ökosystem — es ist für Claude-Modelle optimiert und bietet nicht die Multi-Model-Routing-Flexibilität, die AutoGen und LangGraph nativ bieten.
Die ehrliche Einschätzung: Kein Framework ist für alles das beste. AutoGen passt zu Microsoft-zentrierten Unternehmen, die moderat komplexe Agent-Systeme bauen. LangGraph passt zu Engineering-Teams, die komplexe, zustandsbehaftete Workflows mit Produktions-Grade-Persistenz und Human-in-the-Loop bauen. CrewAI passt zu Teams, die rollenbasierte Agent-Systeme schnell prototypen und shippen müssen. Claude Agent SDK passt zu Teams, die Reasoning-Qualität und autonome Fähigkeiten über Multi-Model-Flexibilität priorisieren. Die meisten Enterprise-Multi-Agent-Architekturen werden langfristig mehr als ein Framework nutzen — verschiedene Frameworks für verschiedene Subsysteme, verbunden über wohldefinierte APIs.
Was über Erfolg entscheidet
Die Organisationen, die Bain mit 10 bis 25 Prozent EBITDA-Verbesserung durch Workflow-Level-Agent-Deployment identifiziert, haben diese Ergebnisse nicht durch die Wahl des richtigen Frameworks erzielt. Sie haben sie erzielt, indem sie die architektonischen Entscheidungen richtig getroffen haben: Orchestrierungsmuster, die zum tatsächlichen Workflow passen, Memory-Systeme, die Wissen kumulieren, Governance-Schichten, die Autonomie innerhalb von Grenzen ermöglichen, Model-Routing, das Kosten und Qualität in Balance hält, und Observability, die das System debuggbar und auditierbar macht.
Das Framework ist das Werkzeug. Die Architektur ist der Hebel. Das Workflow-Redesign ist die Wertschöpfung.
Ein Fit Call bewertet Ihre Multi-Agent-Architektur-Anforderungen — Orchestrierungsmuster, Memory-Bedürfnisse, Governance-Grenzen und Model-Routing-Strategie — und ordnet sie dem Framework und Deployment-Ansatz zu, der zu den Workflows, der Datenlandschaft und dem strategischen Anspruch Ihrer Organisation passt.
Referenzen: AutoGen v1.0 GA Dokumentation, Microsoft Research, 2026; LangGraph v0.4 Dokumentation, LangChain, 2026; CrewAI Dokumentation, 2026; Claude Agent SDK Dokumentation, Anthropic, 2026; Bain & Company, „Technology Report 2025", 2025; McKinsey & Company, „The State of AI: How Organizations Are Rewiring to Capture Value", 2025; BCG, „AI Radar 2025: From Potential to Profit", 2025.