TL;DR
- 80 % der Mittelstands-Use-Cases sind Single-Agent + Tools. Multi-Agent ist 2026 Mode, nicht Notwendigkeit.
- Drei harte Trigger rechtfertigen Multi-Agent: Modell-Tier-Diversität, parallele Subtasks, adversariale Quality-Gates.
- Default-Pattern 2026: Single-Agent mit 5–8 sauber typisierten Tools. Multi-Agent erst nach messbarem Quality-Hebel aus einem Quartal-Pilot.
Warum diese Frage jeden CIO trifft
Jedes zweite Vendor-Deck verkauft 2026 „Multi-Agent-Systeme". Der Eindruck: Wer nur einen Agent baut, baut von gestern. In 47 Mittelstands-Mandaten der letzten zwölf Monate war Single-Agent mit Tool-Use die produktive Architektur in 38 Fällen. Sechs Projekte rechtfertigten Multi-Agent. Drei waren ehrliche Fehl-Bauten — Multi-Agent verkauft, Single-Agent wäre besser gewesen.
Drei Trigger für Multi-Agent
Nur wenn mindestens einer der drei Trigger zutrifft, rechtfertigt sich der ~2,5–3× höhere Cost-Footprint. Alle anderen Use-Cases laufen besser auf Single-Agent + Tools.
- Modell-Tier-Diversität — Junior-Researcher (Haiku) sammelt breit, Senior-Analyst (Opus) synthetisiert tief, Reviewer (Sonnet) prüft gegen Quality-Gate. Jede Tier liefert, wofür sie optimiert ist, zu passenden Kosten. Faustregel: rechtfertigt sich, sobald >60 % der Arbeit auf einem günstigeren Modell laufen könnte, während die Synthese explizit Opus-Qualität braucht.
- Parallele Subtasks — fünf Lieferanten-Quotes oder zehn Klauseln gleichzeitig. Parallele Sub-Agenten reduzieren die Wand-Zeit nahezu linear. Voraussetzung: die Subtasks sind wirklich unabhängig — kein gemeinsamer State, keine Reihenfolge-Abhängigkeit.
- Adversariale Quality-Gates — Generator-Agent produziert Output, Critic-Agent prüft mit anderem System-Prompt und ggf. anderem Modell. Funktioniert nachweislich besser als „bitte selbst prüfen" im selben Prompt — bei regulatorischen Texten, Schadens-Diagnosen und Vertrags-Klauseln messbar.
Drei Orchestration-Pattern
Die Wahl hängt am Use-Case, nicht am Framework.
| Pattern | Beschreibung | Best-For | Framework |
|---|---|---|---|
| Supervisor-Worker | Hub-and-Spoke: Supervisor delegiert, sammelt, entscheidet next-step | Research, Multi-Source-Synthese | LangGraph (Default), CrewAI |
| Sequential-Pipeline | Step-A → B → C, kein zentraler Hub, je fokussierter Prompt | Dokumenten-Pipelines, Extraktion → Validierung | LangGraph, Plain Code, n8n |
| Swarm / Handoff | Agents übergeben Kontrolle aktiv weiter, Routing in Agent-Logik | Customer-Support mit Domain-Routing, Triage | OpenAI Swarm, LangGraph Subgraphs |
Supervisor-Worker ist robust und gut debuggbar, aber latenz-lastig. Sequential-Pipeline ist die unterschätzte Pattern: einfach, schnell, billig. Swarm/Handoff ist mächtig, aber schwer zu testen.
Cost vs Quality: wann lohnt Multi-Agent
Die Frage ist nicht „ob teurer", sondern „ob der Quality-Hebel die Cost-Multiplikation rechtfertigt".
| Setup | Cost-Multiplier | Quality-Hebel | Wann sinnvoll |
|---|---|---|---|
| Single-Agent + 5–8 Tools | 1,0× | Basislinie | 80 % der Use-Cases |
| 2-Agent (Generator + Critic) | ~1,8× | +15–25 pp Faithfulness | Regulatorik, Schadens-Diagnose |
| 3-Agent (Supervisor + 2 Worker) | ~2,5–3× | +20–40 pp bei Multi-Source | Research, Lieferanten-Vergleich |
| 5+-Agent Swarm | ~4–6× | +5–15 pp ggü. 3-Agent | Support mit >10 Domains |
Faustregel: Multi-Agent rechtfertigt sich erst ab >30 % messbarem Quality-Hebel in einem dokumentierten Quartal-Pilot. Darunter: Single-Agent + besseres Prompt-Engineering. Wichtig: Latency wächst überproportional — ein 3-Agent-Setup hat typisch 2,2–3,5× höhere P95-Latency, auch mit paralleler Worker-Ausführung.
Pilot: Schadens-Diagnose Multi-Agent
Ein deutscher Sach-Versicherer im Mittelstand betrieb in der Schadens-Triage zunächst einen Single-Agent (Claude Sonnet) mit RAG auf Police, Schadensmeldung und Foto-Befund. Faithfulness-Score 78 %, drei Eskalationen pro Woche an Senior-Schadensregulierer.
Das Multi-Agent-Setup verteilte: Junior-Researcher (Haiku) extrahiert Police-Klauseln, Schadens-History und Foto-Metadata (Breite +40 % vs Sonnet-Solo); Senior-Analyst (Opus) liefert Deckungsanalyse und Kausalkette; Reviewer (Sonnet mit Critic-Prompt) prüft Konsistenz und blockt automatisch bei <80 % Citation-Coverage.
Ergebnis nach 90 Tagen: Faithfulness 78 % → 94 %, Eskalationen pro Woche 3 → 0,5, Cost pro Schaden Faktor 2,8. Quality-Hebel klar im rechtfertigenden Bereich, Cost-Multiplier vom CFO akzeptiert, weil Senior-Schadensregulierer-Stunden um 64 % sanken.
Anti-Patterns
- Multi-Agent für Speed — Multi-Agent ist nicht schneller, sondern langsamer: Hub-Round-Trips, Handoff-Overhead und Synthese fressen die parallelen Gewinne meist auf. Wer Speed will, optimiert Prompt-Caching und Tool-Granularität.
- Multi-Agent bei <3M Tokens/Tag — wirtschaftlich nicht messbar verteidigbar. Die Zusatz-Cost wird vom Volumen nicht amortisiert. Default: Single-Agent + 5–8 Tools, bis das Volumen wächst.
- Multi-Agent ohne Quality-Gate-Messung — wer kein Golden-Set, keine LLM-as-Judge-Bewertung, keine Citation-Coverage etabliert, kann den Hebel nicht beweisen. Resultat: Cost ohne dokumentierten Gewinn.
Default-Empfehlung 2026
- Single-Agent zuerst. Claude Sonnet oder GPT-5 mit 5–8 typisierten Tools. 80 % der Use-Cases sind hier produktiv.
- Quality-Gate vor Multi-Agent. Golden-Set (200–500 Beispiele), LLM-as-Judge, Citation-Coverage. Ohne Messung kein Hebel-Beweis.
- Multi-Agent als gezielter Upgrade. Nur wenn ein Trigger zutrifft und der ROI-Beweis aus dem Pilot vorliegt.
Multi-Agent ist 2026 ein scharfes Werkzeug — aber kein Default. Wer es als Default verkauft, verkauft Architektur, nicht Wirkung.
Architektur-Review anfragen → /anfrage · Pilot-Quartal als Festpreis kalkulieren → /anfrage
Nächster Schritt
Passt das auf Ihren Fall?
30-Min-Erstgespräch, kostenfrei und unverbindlich. Wir gehen Ihren konkreten Fall durch — und sagen ehrlich, wenn nichts passt.