Als ich mit dem Bau von VollgeistCoach begann, hatte ich einen klaren Plan: ein 5-Agenten-System mit Orchestrator, Zahlen-Agent, Kommunikations-Agent, Burnout-Agent und Guard. Sechs Monate später läuft das System in Produktion — und ich kann sagen, welche Entscheidungen sich gelohnt haben und welche ich anders treffen würde.
Die ehrliche Antwort auf „Multi-Agent oder Single-Prompt?" ist: meistens Single-Prompt. Aber die Ausnahmen sind es, die echte Produktivitätssysteme von Demos trennen.
Was Multi-Agent-Systeme tatsächlich können
Der Mehrwert von mehreren Agenten entsteht in drei Szenarien:
1. Parallelisierung von Teilaufgaben. Wenn dein System gleichzeitig Kundendaten analysieren, externe APIs abfragen und einen Report generieren soll — das geht mit einem Single-Prompt nicht. Hier sparst du echte Zeit durch parallele Ausführung.
2. Spezialisierung durch Kontexttrennung. Jeder Agent bekommt nur den Kontext den er braucht. Der Zahlen-Agent von VollgeistCoach kennt nur Finanzzahlen und Branchenbenchmarks. Er wird nicht durch Gesprächsgeschichte, Persönlichkeitsprofile oder Workflow-Management abgelenkt. Das verbessert die Genauigkeit messbar.
3. Skalierbare Komplexität. Ein Single-Prompt der 20 Aufgaben in einem Call erledigt wird irgendwann unzuverlässig. Mit Agenten kannst du jeden Teilschritt einzeln testen, einzeln verbessern, einzeln ersetzen — ohne das gesamte System anzufassen.
Warum die meisten Multi-Agent-Systeme scheitern
In der Praxis beobachte ich fast immer dasselbe Muster: Jemand baut eine Multi-Agent-Architektur, weil sie beeindruckend klingt — nicht weil das Problem es erfordert.
Die konkreten Probleme:
- Latenz summiert sich. 5 serielle API-Calls × 2–3 Sekunden = 10–15 Sekunden Wartezeit. Für einfache Tasks ist das inakzeptabel.
- Fehler propagieren. Wenn Agent 2 einen Fehler macht, bauen Agent 3, 4 und 5 auf falschen Daten auf. Error-Handling in Multi-Agent-Systemen ist exponentiell komplexer.
- Koordinations-Overhead. Der Orchestrator-Prompt wird zum kritischsten und fraggilsten Teil des Systems. Jede Änderung an einem Agenten kann den Orchestrator-Kontext brechen.
Die Entscheidungsmatrix
Diese Fragen stelle ich vor jeder Architektur-Entscheidung:
Kann das Problem in einem Prompt gelöst werden? Wenn ja — Single-Prompt. Immer. Weniger Komplexität, weniger Fehlerquellen, schnellere Iteration.
Braucht das Problem parallele Ausführung? Wenn mehrere unabhängige Teilaufgaben gleichzeitig erledigt werden müssen — Multi-Agent ist der richtige Weg.
Gibt es kritisch verschiedene Spezialisierungen? Wenn ein Teil des Systems finanzielle Präzision braucht und ein anderer empathische Sprache — zwei getrennte Agenten mit unterschiedlichen System-Prompts liefern bessere Ergebnisse als ein Kompromiss-Prompt.
Wird das System über Zeit wachsen? Wenn neue Funktionen in isolierten Agenten entwickelt werden sollen ohne bestehende Funktionen zu brechen — Multi-Agent als Architektur-Investition.
Was ich bei VollgeistCoach anders machen würde
Den Guard-Agent würde ich als ersten entwickeln, nicht als letzten. Er validiert alle Ausgaben bevor sie den Nutzer erreichen — das hätte früh viele Debugging-Stunden gespart.
Den Orchestrator würde ich minimal halten: Routing und Kontext-Management, keine Business-Logik. Business-Logik gehört in die spezialisierten Agenten.
Und ich würde früher entscheiden welche Agenten wirklich parallel laufen können und welche sequentiell sein müssen. Diese Entscheidung beeinflusst die gesamte Architektur — und eine spätere Änderung ist schmerzhaft.
Das Fazit
Multi-Agent-Systeme sind keine KI-Weiterentwicklung von Single-Prompts — sie sind eine andere Kategorie mit anderen Trade-offs. Nutze sie wenn du Parallelisierung, echte Spezialisierung oder modulare Erweiterbarkeit brauchst. Für alles andere ist ein gut strukturierter Single-Prompt schneller, zuverlässiger und einfacher zu debuggen.