In der Prüfung wirst du häufig nicht gefragt, was „cooler“ ist, sondern was in einem konkreten Szenario die bessere Architekturentscheidung ist. Genau hier liegt der Kern von Single-Agent vs. Multi-Agent. Ein Single-Agent-System hat einen zentralen Agenten, der plant, Tools nutzt und Ergebnisse liefert. Ein Multi-Agent-System verteilt Rollen auf mehrere spezialisierte Agenten (z. B. Research, Validation, Reporting), die koordiniert zusammenarbeiten.
Der erste Prüfungshebel ist Komplexität vs. Kontrolle. Single-Agent ist meist einfacher zu bauen, zu betreiben und zu debuggen. Du hast eine klarere Ausführungskette, weniger Übergaben und oft geringere Infrastrukturkosten. Multi-Agent wird interessant, wenn Aufgaben stark heterogen sind: unterschiedliche Domänenlogik, verschiedene Tool-Berechtigungen oder parallele Teilaufgaben. Der Gewinn ist Spezialisierung und potenziell bessere Qualität in komplexen Workflows. Der Preis ist Koordinationsaufwand.
Zweiter Hebel: Latenz. Viele Teams unterschätzen das. Jeder zusätzliche Agent-Schritt bedeutet mindestens eine weitere Modellinferenz plus Kontextübergabe. Wenn Agent A ein Ergebnis produziert, Agent B es bewertet und Agent C zusammenfasst, addierst du Laufzeit. In interaktiven Anwendungen (Support, Incident-Triage, Chat mit Live-Nutzer) kann das UX-kritisch sein. Multi-Agent kann Latenz teilweise kompensieren, wenn du echte Parallelisierung erreichst (z. B. gleichzeitige Recherche in mehreren Quellen). Ohne Parallelisierung wird es oft langsamer als ein gut designter Single-Agent.
Dritter Hebel: Kosten. Mehr Agenten bedeuten oft mehr Tokens, weil jeder Agent Kontext erhält, Zwischenergebnisse produziert und häufig redundant erklärt, was bereits bekannt ist. Kosten steigen nicht linear, sondern durch wiederholte Kontextpakete oft überproportional. Gute Architektur reduziert diesen Effekt über kompakte Übergabeformate (Schema statt Fließtext), harte Kontextgrenzen und nur notwendige Übergaben. In der Prüfung ist „Multi-Agent = besser“ fast nie die richtige Default-Antwort. Besser ist: „So wenig Agenten wie möglich, so viele wie nötig.“
Vierter Hebel: Failure Surface (Fehleroberfläche). Jeder zusätzliche Agent und jede Übergabe ist ein möglicher Fehlerpunkt: falsches Routing, unklare Verantwortlichkeit, widersprüchliche Ergebnisse, Race Conditions bei Parallelität, Berechtigungsfehler bei Tools. Single-Agent hat weniger dieser systemischen Fehlerarten. Multi-Agent braucht daher stärkere Orchestrierung: klare Rollen, definierte Inputs/Outputs, Timeout- und Retry-Policy, Konfliktlösung (z. B. Validator sticht Research), sowie Human-Handoff bei Unsicherheit.
Exam-orientierte Faustregel: Starte bei Single-Agent, solange Qualität, Laufzeit und Sicherheit passen. Gehe zu Multi-Agent nur dann, wenn du einen klaren architektonischen Nutzen benennen kannst: Spezialisierung, Isolation von Rechten, Parallelisierung oder Governance-Gründe. Und wenn du Multi-Agent wählst, musst du im Antwortstil immer die Gegenmaßnahmen nennen: orchestration contract, validation layer, observability.
1. Single-Agent ist der Default für Einfachheit, niedrigere Betriebskomplexität und kleinere Fehleroberfläche.
2. Multi-Agent lohnt sich nur mit klarem Mehrwert (Spezialisierung, Parallelisierung, Security-Isolation, Governance).
3. Failure Surface aktiv managen: feste Rollen, strukturierte Übergaben, Validierung, Timeouts, Retries, Human-Handoff.
Du entwirfst ein System für regulatorische Berichtserstellung: Datenrecherche, Compliance-Prüfung und Executive-Zusammenfassung. Das Team will sofort auf Multi-Agent gehen. Wie begründest du eine prüfungstaugliche Architekturentscheidung inklusive Trade-offs?
Ich würde zunächst prüfen, ob ein Single-Agent mit klaren Workflow-Phasen die Qualitätsziele erfüllt, weil er günstiger und einfacher zu betreiben ist. Für regulatorische Szenarien kann Multi-Agent dennoch sinnvoll sein, z. B. getrennte Compliance-Validierung mit eigener Tool-Berechtigung und Audit-Trail. Die Entscheidung ist dann gerechtfertigt, wenn der Nutzen (Risikoreduktion, Governance, Qualität) die Mehrkosten in Latenz, Tokens und Orchestrierungsaufwand klar übersteigt.