Supervisor statt Swarm: Die Architekturfrage vor der Tool-Wahl

Wenn ich mit Marketing-Teams über ihren ersten produktiven Agenten-Workflow spreche, beginnt das Gespräch fast immer an der falschen Stelle: bei der Tool-Frage. CrewAI oder LangGraph? Lieber gleich die Claude API direkt ansteuern? Die Frage, die tatsächlich entscheidet, ob das System in einem Jahr noch zuverlässig läuft, wird dabei fast nie gestellt: Wer kann erklären, warum ein Agent eine bestimmte Entscheidung getroffen hat – und wer trägt die Verantwortung, wenn das niemand kann?

Zwei Architekturen, ein fundamentaler Unterschied

Multi-Agenten-Systeme lassen sich grob in zwei Koordinationsmuster einteilen. Bei einer Swarm-Architektur verhandeln Agenten ihre Aufgabenteilung untereinander, emergent, ohne feste Hierarchie. Das klingt elegant und ist es in Forschungsumgebungen auch. Bei einer Supervisor-Architektur gibt ein zentraler Agent Aufgaben an spezialisierte Sub-Agenten weiter, sammelt deren Ergebnisse ein und trifft die finale Entscheidung. Weniger emergent, dafür nachvollziehbar.

Für die überwiegende Mehrheit der Marketing-Workflows, die ich in DACH-Unternehmen begleite, ist die Supervisor-Architektur die richtige Wahl – und zwar nicht, weil Swarm-Modelle technisch unterlegen wären. Sondern weil eine ganz andere Frage im DACH-Kontext nicht verhandelbar ist: Wenn ein Betriebsprüfer, ein Kunde oder die Rechtsabteilung fragt, warum ein System eine bestimmte E-Mail verschickt oder ein Rabattangebot ausgespielt hat, brauchst du eine Antwort, die sich auf einen konkreten Entscheidungspunkt zurückführen lässt. Bei einer Supervisor-Architektur gibt es diesen Punkt. Bei emergenter Schwarm-Koordination oft nicht – die Entscheidung ist das Ergebnis eines Zusammenspiels, das sich im Nachhinein kaum sauber rekonstruieren lässt.

Ich habe das in einem Projekt hautnah erlebt, bei dem ein Reaktivierungs-System aus drei Agenten bestand, die sich gegenseitig Vorschläge zuspielten: einer für Segmentierung, einer für Content, einer für Timing. Als eine Kundin sich beschwerte, weil sie an einem Feiertag eine unpassende Rabattaktion erhalten hatte, brauchte das Team drei Tage, um zu rekonstruieren, welcher Agent die Entscheidung eigentlich getroffen hatte. Nicht weil die Logs fehlten – sondern weil keiner der drei Agenten allein „schuld” war. Die Entscheidung war ein Nebenprodukt der Interaktion. Danach wurde das System auf eine Supervisor-Struktur umgebaut, mit einem einzigen Entscheidungspunkt, der jede Ausspielung freigibt oder stoppt. Die Komplexität wurde dadurch nicht kleiner. Aber sie wurde erklärbar.

Warum das keine akademische Debatte ist

Der Reflex, das als reine Compliance-Frage abzutun, greift zu kurz. Nachvollziehbarkeit ist auch operativ wertvoll: Wenn ein Kampagnen-Agent plötzlich schlechtere Ergebnisse liefert, willst du in Minuten wissen, an welcher Stelle der Kette das passiert – nicht in Tagen. Eine Supervisor-Architektur macht das Debugging zu einer linearen Suche. Eine Swarm-Architektur macht es zu einer Verhaltensanalyse.

Das heißt nicht, dass Swarm-Modelle wertlos sind. Für explorative Aufgaben – etwa wenn mehrere Agenten unabhängig voneinander Kreativvarianten generieren und die beste Variante emergent gewinnt – können sie sinnvoll sein. Aber sobald ein Agent eine Aktion auslöst, die einen echten Kunden erreicht oder echtes Budget bewegt, würde ich in einem DACH-Marketing-Kontext praktisch immer zur Supervisor-Struktur raten.

Die Tool-Frage kommt danach – und ist trotzdem keine Nebensache

Erst wenn die Architekturfrage geklärt ist, wird die Tool-Wahl relevant. Auch hier lohnt sich eine nüchterne Faustregel statt eines wochenlangen Evaluierungsprojekts.

CrewAI ist für die meisten Marketing-Teams der richtige erste Schritt. Die Rollen- und Task-Definitionen sind so lesbar, dass ein Marketing Lead ohne Entwicklerhintergrund die Konfiguration noch versteht und mitreden kann – ein nicht zu unterschätzender Vorteil, wenn das Team selbst pflegen soll, was es baut. LangGraph spielt seine Stärke aus, sobald ein Agent über Tage oder Wochen Zustand halten muss – etwa bei einer Customer Journey, die sich über mehrere Touchpoints erstreckt und sich an frühere Interaktionen erinnern soll. Wer maximale Kontrolle über die Entscheidungslogik braucht und mit hohem Volumen arbeitet, kommt an der direkten Anbindung über die Claude API nicht vorbei – nicht zuletzt, weil Prompt Caching bei tausenden täglichen Workflow-Durchläufen über die Wirtschaftlichkeit entscheidet, nicht über technische Finessen.

Was in dieser Abwägung häufiger unterschätzt wird als das Framework selbst: die Schnittstellen zwischen den Agenten. Ein durchschnittlicher Agent mit einem sauberen, klar definierten Input- und Output-Schema schlägt in der Praxis fast immer einen brillanten Agenten mit unklaren Übergaben. Das ist auch der Grund, warum viele Piloten in der Demo überzeugen und im Produktivbetrieb hängen bleiben: Die einzelnen Agenten funktionieren, aber die Übergabe zwischen ihnen wurde nie explizit spezifiziert. Genau das sollte in der Konzeptphase feststehen, bevor die erste Zeile Framework-Code geschrieben wird.

Was das konkret heißt

Kläre die Governance-Frage vor der Tool-Frage. Wer verantwortet die finale Aktion, wenn ein Agent eine Entscheidung trifft, die einen Kunden erreicht? Ohne klare Antwort ist jede Architekturentscheidung Zufall.

Starte mit Supervisor als Standard, nicht als Ausnahme. Weiche nur davon ab, wenn du einen dokumentierten Grund hast – etwa eine rein explorative, kundenferne Aufgabe. Für alles, was Budget bewegt oder Kunden erreicht, ist der zentrale Entscheidungspunkt die sicherere Wahl.

Wähle das Framework nach Team-Realität, nicht nach Hype. CrewAI, wenn Marketing selbst pflegen soll. LangGraph, wenn Zustand über Zeit zählt. Die Claude API direkt, wenn Skalierung und Kostenkontrolle im Vordergrund stehen.

Definiere Schnittstellen, bevor du Agenten baust. Ein Schema für jede Übergabe zwischen Agenten ist keine Formalie, sondern die Stelle, an der die meisten Produktivsysteme später scheitern.

Plane vier bis sechs Wochen bis zur Produktionsreife, nicht drei Tage. Der Prototyp steht schnell. Die Absicherung – Fehlerbehandlung, Monitoring, Eskalationspfade – braucht Zeit, und diese Zeit einzuplanen ist günstiger, als sie sich im Livebetrieb zu nehmen.

---

Kapitel 9 des Buchs behandelt den Sprung von der Referenzarchitektur zum ersten produktiven Multi-Agenten-Workflow im Detail: Framework-Auswahl zwischen CrewAI, LangGraph, Google ADK und der Claude API, die Supervisor-versus-Swarm-Entscheidung und die Praxis der ersten Wochen im Produktivbetrieb.

→ Zum Buch