Multi-Agent-Workflows sind 2026 zum Default-Buzzword geworden. Die ehrliche Wahrheit: Multi-Agent ist nicht die Antwort auf jedes Problem. Wenn die Workflow-Schritte unterschiedliche Rollen, Zustände und Tools brauchen, gewinnt das gesplittete System. Wenn nicht, ist ein einzelner Agent mit klarer Anweisung schneller, billiger und debugbar.

Wann man teilen sollte.

  • Die Rollen sind wirklich unterschiedlich. Ein Planner, der entscheidet, eine Executorin, die ausführt, eine Reviewerin, die prüft. Drei Prompts, drei Tools, drei Eval- Rubriken.
  • Die Zustände kollidieren. Wenn ein einzelner Agent zwischen entgegengesetzten Modi (kreativ vs. konservativ, offen vs. strikt) wechseln muss, bekommen Sie schizophrene Outputs. Zwei Agenten lösen das.
  • Die Tools sind nicht-kompatibel. Ein Agent mit Code-Execution sollte nicht denselben Kontext teilen wie einer mit E-Mail-Versand.
«Multi-Agent ist Arbeitsteilung, nicht Komplexitätsbeweis.»

Wann nicht.

Wenn der Workflow eine lineare Pipeline ist, in der jeder Schritt dieselbe Rolle hat (Daten holen, Daten transformieren, Daten ausgeben), bauen Sie einen einzelnen Agenten mit deterministischen Funktionsaufrufen. Ein Multi-Agent-System dort fügt Latenz, Kosten und drei Stellen für Fehler hinzu, ohne irgendetwas zu lösen.

Drei Muster, die funktionieren.

  1. Planner / Executor / Reviewer. Ein Agent plant (zerlegt), ein zweiter führt jeden Plan-Schritt aus, ein dritter prüft das Ergebnis gegen die ursprüngliche Spezifikation und kann das Ganze zurückkicken. Funktioniert für Code-Generierung, Berichts-Erstellung, Recherche-Pipelines.
  2. Kritiker-Paar. Ein Agent produziert, ein zweiter kritisiert nach einer expliziten Rubrik, der erste überarbeitet. Maximal zwei Runden, sonst Kosten-Eskalation. Funktioniert für Drafting-Tasks (E-Mails, Proposals).
  3. Spezialisten-Router. Ein leichter Router-Agent erkennt die Anfrage-Klasse und routet sie an einen spezialisierten Agenten (legal, technical, sales). Jeder Spezialist hat seine eigene Eval-Harness.

Der Handoff-Kontrakt.

Der häufigste Multi-Agent-Bug ist der unklare Handoff. Agent A übergibt an Agent B und B versteht die Übergabe nur halb. Definieren Sie das Handoff-Schema als typisiertes Objekt: Eingabe, erwartete Ausgabe, Erfolgskriterium. Schreiben Sie es als TypeScript-Interface, nicht als Prosa-Anweisung.

Observability oder Sie verlieren.

Multi-Agent-Systeme produzieren exponentiell mehr Traces als Einzel-Agenten. Ohne Observability (LangSmith, Phoenix, OpenTelemetry) ist jeder Fehler eine zwanzigminütige Detektivarbeit. Mit Observability sind die meisten Fehler in fünf Sekunden klar.

Vollständige englische Fassung: Multi-agent workflows in production · when to split, when not to.

Diese deutschsprachige Fassung ist eine eigenständige Übersetzung der englischen Ausgabe. Read the English original ›