Multi-Agenten-Systeme ohne Theater
Mehrere KI-Agenten können Arbeit teilen. Sie teilen aber auch Fehler, Kosten und Missverständnisse. Der Nutzen beginnt erst bei sauberer Aufgabentrennung.
KI-Inhalte verändern sich schnell. Nächster planmäßiger Audit: 31.08.2026.
Ein Multi-Agenten-System lohnt sich, wenn unabhängige Rollen, getrennte Werkzeuge oder echte Parallelität einen messbaren Vorteil bringen. Für die meisten linearen Abläufe ist ein begrenzter Agent oder ein Workflow besser.
Agentennamen wie Planer, Forscher und Kritiker erzeugen noch keine Organisation. Ohne Vertrag für Eingaben, Ausgaben, Zuständigkeit, Abbruch und Konflikte reden mehrere Modelle nur aufwendiger aneinander vorbei.
Ein Team braucht Verträge, keine Charakterkarten
Rollenbeschreibungen wie Forscher oder Kritiker helfen beim Denken. Für ein System reichen sie nicht. Jede Übergabe braucht eine eindeutige Aufgaben-ID, erlaubte Daten, gewünschtes Format, Quellen, Frist, Fehlerstatus und Abnahmekriterium. Sonst wird aus Zusammenarbeit eine Kette freundlicher Missverständnisse.
Planner–Executor–Reviewer: sinnvoll, aber nicht magisch
Die Trennung kann Rechte sauber verteilen: Der Planer darf lesen und zerlegen, der Ausführer arbeitet in einer begrenzten Umgebung, der Prüfer sieht Diff, Tests und Ziel. Der Prüfer sollte nicht nur fragen, ob die Antwort gut klingt. Er braucht überprüfbare Kriterien und darf den Vorgang zurückweisen.
Debatte ist kein Faktencheck
Mehrere Modelle können Gegenargumente liefern und Unsicherheit sichtbar machen. Sie können aber dieselben Trainingsmuster, dieselbe falsche Quelle oder denselben blinden Fleck teilen. Zwei zustimmende Agenten sind keine zwei unabhängigen Belege. Wahrheit kommt aus Daten, Tests und Quellen außerhalb der Unterhaltung.
Gemeinsames Gedächtnis verbreitet auch Irrtümer
Wenn jeder Agent alle Zwischengedanken liest, wachsen Kontext, Kosten und Datenschutzrisiko. Besser sind knappe, strukturierte Übergaben und getrennte Arbeitsräume. Der Koordinator teilt nur, was die nächste Rolle wirklich braucht. Das ist Datenminimierung und zugleich ein Schutz gegen Fehlerfortpflanzung.
Fehler wachsen über Übergaben
Ein Agent missversteht die Anfrage, der zweite baut sauber darauf auf, der dritte formuliert überzeugend. Jeder Einzelschritt kann plausibel aussehen, während das Gesamtergebnis falsch ist. Deshalb braucht das System End-to-End-Tests, markierte Annahmen und einen Weg zurück zum letzten bestätigten Zustand.
Kosten und Latenz sind Architektur
Mehr Agenten bedeuten mehr Modellaufrufe, Kontextkopien, Werkzeugzugriffe und Wartezeit. Parallelität hilft nur bei unabhängigen Aufgaben. Bei sequenziellen Übergaben addiert sie Latenz. Ein Budget pro Auftrag, eine maximale Tiefe und ein Abbruch bei sinkendem Erkenntnisgewinn gehören in die technische Spezifikation.
Behauptung & Befund
Mehr Rollen können Arbeit teilen. Ohne echte Trennung erhöhen sie vor allem Koordination, Kosten und Fehlerpfade.
Er kann Fehler finden, aber auch zustimmen oder neue erfinden. Externe Quellen und Tests bleiben nötig.
Getrennte Zustände und minimale Übergaben reduzieren Datenabfluss, Kontextlast und Fehlerfortpflanzung.
A2A erleichtert die technische Kommunikation. Rollen, Regeln, Vertrauen und Verantwortung müssen weiterhin gestaltet werden.
Quellen
- Agent2Agent protocol Autor/Institution: Linux FoundationPublisher: Linux Foundation
- Announcing the Agent2Agent Protocol Autor/Institution: GooglePublisher: Google
- A2A wechselt unter neutrale Linux-Foundation-Governance Autor/Institution: Linux FoundationPublisher: Linux Foundation
- Model Context Protocol specification Autor/Institution: MCPPublisher: MCP
- MCP-Spezifikation 2026-07-28 und Änderungen Autor/Institution: Model Context ProtocolPublisher: Model Context Protocol
- Prompt Injection Autor/Institution: OWASPPublisher: OWASP
- Excessive Agency: zu viele Funktionen, Rechte oder Autonomie Autor/Institution: OWASP GenAI Security ProjectPublisher: OWASP GenAI Security Project
- Artificial Intelligence Risk Management Framework: Generative AI Profile Autor/Institution: NISTPublisher: NIST
- Human-in-the-loop für Werkzeugaufrufe Autor/Institution: n8nPublisher: n8n