Multi-Agent Orchestrierung, mehrere Server im Zusammenspiel

Ein Agent mit einem MCP-Server ist der einfache Fall. Ernsthafte Arbeit braucht aber meistens mehrere Rollen gleichzeitig. Ein Rechercheur sucht, ein Kritiker widerspricht, ein Analyst vergleicht mit Bestehendem. Ein Koordinator (oft "CEO Agent" genannt) synthetisiert. Diese Lektion zeigt wie das technisch zusammenläuft.

Die drei klassischen Worker, erneut

In Level 5 hattest Du die drei Worker kennengelernt: Research, Critic, Analyst. Die Rollen sind nicht meine Erfindung, sie ergeben sich von selbst wenn Du lange genug Multi-Agent-Systeme baust. Jetzt geht es darum wie Du sie implementierst, nicht was sie tun.

Das Grundmuster

Pro Worker baust Du ein eigenes Script / einen eigenen Server-Aufruf. Jeder hat:

• eine klare Rolle als System-Prompt
• Zugriff auf die gleichen Tools (MCP-Server) oder spezifische Untermengen
• einen definierten Input (die Frage / das Thema)
• einen definierten Output (eine Markdown-Datei, eine Datenbank-Zeile, ein Report)

Der CEO ruft die drei parallel auf, wartet bis alle drei Reports vorliegen, synthetisiert sie zu einer Empfehlung.

In Pseudocode:

async function runAgents(topic) {
  const [researchReport, criticReport, analystReport] = await Promise.all([
    runResearchAgent(topic),
    runCriticAgent(topic),
    runAnalystAgent(topic),
  ]);
  return synthesize(researchReport, criticReport, analystReport);
}

Das ist die Architektur. Einfach. Fast alles was Du bei Multi-Agent-Setups siehst, ist eine Variation davon.

Die sechs gaengigen Muster

Wenn Du anfaengst Multi-Agent-Code zu lesen, wirst Du immer wieder die gleichen sechs Muster sehen. Hier ist die Landkarte:

| Pattern | Agent-Anzahl | Kern-Mechanik | Wo es typisch lebt | |---------|:-:|---------------|--------------------| | Sequential Pipeline | 1-3 | Lineare Kette A → B → C, jeder abhängig vom vorherigen Output | Alle Frameworks nativ, einfachster Fall | | Flat Supervisor | 3-5 | Zentraler Orchestrator delegiert an Workers, synthetisiert Outputs | LangGraph supervisor node, CrewAI Process.hierarchical, AutoGen GroupChatManager | | Hierarchical | 10-20+ | Rekursiver Supervisor mit mehreren Ebenen, Context durch Schichten gemanagt | LangGraph nested subgraphs, AutoGen SocietyOfMind | | Parallel Fan-out | 4+ unabhängig | Mehrere Agents parallel an Subtasks, Aggregator merged | Manuelles Pattern, fast alle Frameworks | | Swarm | 5-15 | Dezentral, jeder Agent kann an jeden anderen handoff geben | OpenAI Swarm (deprecated), LangGraph handoffs | | Blackboard | Variabel | Shared State, Agenten lesen + schreiben typed Schema | Selten als Framework-Primitive, meistens manuell |

Die Schwelle nach der Praxis ist klar: 1-3 Agenten laufen als Sequential Pipeline am besten, kein Orchestrator-Overhead nötig. 3-5 wollen einen Supervisor, das ist der Sweet Spot. Ab 10 brauchst Du Hierarchical, sonst killt der Kontext des Orchestrators sich selbst weil seine eigene History durch alle Sub-Agent-Round-Trips dominiert wird.

Parallel vs. sequentiell

Parallel laufen die Agents wenn ihre Arbeit unabhängig ist. Research muss nicht wissen was Critic denkt, sie sehen dasselbe Thema von verschiedenen Seiten. Das ist schnell und ehrlich.

Sequentiell lohnt sich wenn Agent B echten Input von Agent A braucht. Zum Beispiel: Agent A schreibt einen Blog-Post, Agent B redigiert ihn. Da ist kein Parallelisieren möglich, B braucht A's Output als Eingabe.

Die meisten Analyse-Aufgaben sind parallel. Die meisten Produktions-Pipelines sind sequentiell. Kombinationen sind üblich: erst drei Agents parallel (Research), dann ein Agent der ihre Outputs synthetisiert (sequentiell).

Konkret in Sekunden gerechnet, damit Du ein Gefuehl für die Zahlen bekommst. Eine Sequential Chain mit fünf Agenten und drei Sekunden pro Agent dauert fuenfzehn Sekunden Minimum, weil jeder auf den vorigen wartet. Ein Hierarchical Setup mit drei Ebenen und zwei Sekunden Coordination-Call pro Ebene braucht sechs Sekunden bevor ueberhaupt ein Worker startet, vier Ebenen schon acht. Bei Parallel Fan-out mit vier unabhaengigen Agents ist die Gesamtzeit das Maximum eines Agents plus den Aggregator, nicht die Summe. Das ist der eigentliche Vorteil von Parallel: kein Summen-Effekt.

Der Neutrality-Guard

Einer der wichtigsten Fehler im Multi-Agent-Setup: Der Critic sieht die bisherigen Erfolge und fängt an sie zu bestätigen statt zu kritisieren. Das killt den ganzen Wert des Critics.

Die Lösung heisst Neutrality Guard: Der Critic bekommt aus dem gemeinsamen Memory nur "Mistakes" und "Warnings", nie "Confirmations". Das ist technisch ein Filter im Memory-Tool-Aufruf. Der Agent selbst merkt es nicht, er sieht einfach keine positiven Bestätigungen in seiner Historie.

In der Praxis heisst das: wenn Du einen gemeinsamen Memory-Store hast, implementierst Du pro Agent eine Sicht, nicht den ganzen Store. Der Research sieht Research-Findings, der Critic sieht Kritik-Geschichte, der Analyst sieht Patterns. Keine Cross-Contamination.

Der CEO-Agent

Der Koordinator ist selbst auch nur ein Agent. Sein System-Prompt ist aber anders:

• Er hat die drei Reports als Input.
• Seine Aufgabe ist Synthese, nicht Duplikation.
• Er darf widersprechen wenn die drei Reports widersprüchlich sind.
• Er gibt eine Empfehlung mit Begründung, nicht nur eine Zusammenfassung.

Gute CEO-Prompts enthalten Sätze wie: "Wenn Research und Critic sich widersprechen, ist das Gold, mach den Widerspruch sichtbar und gewichte ihn."

Token-Budget pro Agent

Multi-Agent-Setups werden teuer wenn Du nicht aufpasst. Jeder Agent macht eigene Model-Calls, liest eigene Files, hat eigene Tool-Calls. Ein Setup mit vier Agents und 25 Turns pro Agent ist schnell bei 400.000 Tokens pro Lauf.

Gegenmassnahmen:

• Max-Turns pro Agent hart limitieren.
• Sonnet statt Opus für einfache Agents (Critic reicht fast immer mit Sonnet).
• Kontext-Budget, nicht der komplette Report-Verlauf wird in jeden Agent gepumpt.
• Tool-Selektion. Research bekommt Research-Tools, Critic bekommt Critic-Tools, nicht alle die gleichen.

Bei StudioMeyer kostet ein voller 3-Agent-Lauf auf Opus ungefähr 3-5 Dollar. Mit Sonnet und sauberem Budget eher 1 Dollar. Das ist überschaubar, aber nur wenn man es aktiv kalibriert.

Wann Multi-Agent die falsche Lösung ist

Wenn ein guter Single-Agent mit einem guten Prompt das gleiche Ergebnis liefert, bau keinen Multi-Agent. Komplexität kostet Zeit, Geld, Fehler-Suche. Multi-Agent lohnt sich wenn:

• Die Rollen wirklich unterschiedliche Denkweisen haben (Kritiker-Logik vs. Rechercheur-Logik).
• Parallele Arbeit den Durchsatz signifikant erhöht.
• Die Aufgabe zu groß für einen Kontext ist und Du sie sinnvoll aufteilen kannst.

Sonst reicht ein Single-Agent mit klaren System-Prompts und Chain-of-Thought.

Anthropic hat im Juni 2025 für ihr eigenes Research-System publiziert dass ein Setup aus Claude Opus 4 (Orchestrator) plus mehreren Claude Sonnet 4 (Sub-Agents) einen Single-Agent-Opus auf Research-Tasks um 90.2 Prozent geschlagen hat. Das ist kein Hype, sondern gemessen. Der Trick war aber nicht "mehr Agents = besser", sondern harte Runden-Limits, explizite Contribution-Regeln und Convergence-Kriterien. Ohne diese Begrenzungen spawnten frühe Varianten 50+ Sub-Agenten und verbrannten Token ohne Ergebnis.

Die Schwelle nach der Praxis: 1-3 Agenten laufen als Sequential Pipeline am besten (kein Orchestrator-Overhead nötig). 3-5 Agenten wollen einen Supervisor. Ab ~10 Agenten brauchst Du Hierarchical-Setups mit Sub-Supervisoren, sonst killt der Kontext des Orchestrators sich selbst.

Framework-Landschaft Stand 2026

Wenn Du anfaengst Frameworks zu vergleichen, wirst Du ueberrumpelt von Optionen die alle gleich klingen. Hier die ehrliche Einordnung Stand April 2026, weil sich der Markt seit Ende 2025 stark konsolidiert hat.

Die Production-Survivors sind LangGraph (Uber, LinkedIn, Klarna, Replit, Cisco und Elastic nutzen es produktiv), CrewAI (gut für rapid prototyping mit guten Defaults), Microsoft Agent Framework v1.0 vom 7. April 2026 (der Merge aus AutoGen und Semantic Kernel), OpenAI Agents SDK und Claude Agent SDK von Anthropic. Das sind die fünf die Du ernsthaft in Betracht ziehen kannst.

Deprecated und nicht mehr empfohlen: OpenAI Swarm ist offiziell tot. Im README des Repos steht woertlich dass es durch das OpenAI Agents SDK ersetzt wurde. AutoGen läuft nur noch auf Bug-Fix-Maintenance nachdem es in Microsoft Agent Framework aufgegangen ist. Wenn Du irgendwo eine Anleitung findest die diese beiden empfiehlt, ist sie alt.

Bemerkenswert ist auch die Empfehlung von LangChain selbst: LangChain 1.0 empfiehlt LangGraph für alle Agent-Workflows und hat initialize_agent und AgentExecutor deprecated. Seit September 2025 laufen LangChain-Agents intern auf LangGraph.

Das unabhaengige aimultiple-Benchmark mit 2000 Runs über 5 Tasks gab folgende Reihenfolge: LangChain ist am tokeneffizientesten, AutoGen hat die niedrigste Latenz, LangGraph liegt eng hinter LangChain bei Token und Latency, und CrewAI ist das schwerste Profil mit etwa dreifachem Token- und Latenz-Verbrauch verglichen mit LangChain bei Single-Tool-Calls. Der Overhead von CrewAI kommt aus der "managerial deliberation" die der Agent etwa fünf Sekunden vor jeder Aktion macht. Das hilft bei komplexen Multi-Step-Tasks, ist aber pure Overhead bei einfachen Calls.

Eine ehrliche Warnung zu Marketing-Claims: das CrewAI-README behauptet "5.76x faster than LangGraph" und das ist self-reported. Das aimultiple-Benchmark fand LangGraph 2.2x schneller. Beide haben recht in unterschiedlichen Dimensionen. CrewAIs 5.76x bezieht sich auf Development-Speed (wie schnell baust Du den Prototypen), nicht auf Execution-Speed (wie schnell läuft er dann). Wenn jemand "X-fach schneller" wirft, frag was genau gemessen wurde: Setup, Token, Runtime oder Skalierung.

Real-Life-Beispiel aus StudioMeyer

Nex HQ (das eigene Orchestrierungs-Repo) hat 9 Agents + einen Conductor. Der Conductor ist kein klassischer CEO-Agent, sondern ein Cron-Scheduler der Agents zu festen Zeiten feuert (Guardian alle 30 Minuten, Daily-Research einmal pro Tag, etc.). Research/Critic/Analyst werden on-demand parallel aufgerufen wenn Matthias "/agent-research X" sagt.

Die Reports landen in research/YYYY-MM-DD-{agent}-{topic}.md. Menschen reviewen, Findings fliessen in das Memory-System ein. Beim nächsten Lauf sehen die Agents den historischen Kontext (mit Neutrality-Guard wo relevant).

Das ist ein produktives Multi-Agent-System seit Februar 2026, ohne Downtime, mit überschaubaren Kosten. Wenn Du Deines bauen willst, orientier Dich daran. Der Code ist nicht öffentlich, aber die Muster sind in dieser Lektion dokumentiert und in Level 5 angesprochen.

Die ersten drei Schritte für Deinen eigenen Multi-Agent-Stack

1. Starte mit zwei Agents, nicht drei. Research + Critic reichen für den Anfang. Analyst kommt dazu wenn Du historischen Kontext brauchst.

2. Nimm den gleichen MCP-Stack für alle. Nicht per Agent eigene Server konfigurieren. Gleiche Memory, gleiche Web-Search, gleiche Code-Intelligence wenn relevant.

3. Die Reports landen als Markdown-Dateien. Nicht direkt in eine Datenbank, nicht direkt in ein JSON-API. Markdown ist das richtige Format weil Menschen es lesen können und weil Agents im nächsten Lauf es als Kontext lesen können.

Quellen zum Weitergraben

Wenn Du tiefer einsteigen willst, hier die primaeren Quellen aus denen die Zahlen in dieser Lektion stammen:

• Anthropic Engineering Blog: anthropic.com/engineering/built-multi-agent-research-system (Juni 2025, das 90.2 Prozent Paper)
• LangChain Blog: blog.langchain.com/building-langgraph (Architektur-Doku)
• Microsoft DevBlogs: devblogs.microsoft.com/semantic-kernel (Agent Framework v1.0 Announcement, April 2026)
• AIMultiple Benchmark: aimultiple.com/agentic-frameworks (2000 Runs, 5 Tasks, unabhängig)
• Augment Code Pattern-Guide: augmentcode.com/guides/swarm-vs-supervisor (Pattern-Schwellen)

Weiter

Level 6 Lesson 4 Deployment zeigt wie Du diese Agent-Architektur tatsächlich als Service ausrollst. Und das Playbook „Memory portabel nutzen" ist die Basis dafür dass Deine Agents überhaupt gemeinsames Gedächtnis haben können.