MULTI-AGENTEN-ARCHITEKTUR

FIELD NOTE 14 / 15

Multi-Agenten-KI ist kein Bot-Team. Sie ist ein System von Verantwortlichkeiten.

Multi-Agenten-KI kann komplexe Arbeit auf spezialisierte Agenten verteilen. Sie kann auch Kosten, Verzögerungen und Fehler vervielfachen. Die Architektur verdient ihren Platz nur, wenn jeder Agent eine notwendige Grenze verantwortet.

2. September 20268 Min. LesezeitTeams, die entscheiden, ob ein KI-Agent genügt
DER ZENTRALE GEDANKE

Fügen Sie einen Agenten nur hinzu, wenn die Arbeit eine neue Grenze braucht – nicht, wenn der Prompt eine weitere Persönlichkeit braucht.

DIESE FIELD NOTE TEILEN

Geben Sie das nützliche Signal weiter.

BEITRAG ODER NACHRICHT
STORY ODER STATUS
Öffnet den Teilen-Dialog auf unterstützten Smartphones. Andernfalls wird die vertikale Karte heruntergeladen.

01Die nützliche Definition

Multi-Agenten-KI verteilt ein Ergebnis auf mehrere Denkrollen.

Ein Multi-Agenten-KI-System nutzt mehr als eine zielgerichtete KI-Komponente für eine größere Arbeit. Ein Agent entscheidet vielleicht, was nötig ist, andere untersuchen oder handeln in Fachbereichen, und eine Orchestrierungsschicht koordiniert Abfolge, Zustand und Endergebnis.

Die Agenten müssen nicht in einem Gruppenchat sitzen. Ein Manager kann Spezialagenten als Tools aufrufen. Agenten können Arbeit übergeben. Unabhängige Agenten können parallel laufen und Belege an einen Koordinator zurückgeben. Manche Schritte sind vielleicht gar keine Agenten: Eine Regel, Datenbankabfrage oder ein konventioneller Workflow ist oft die bessere Komponente.

Das ist weniger filmreif als das populäre Bild eines digitalen Teams am Diskussionstisch. Es ist auch nützlicher. Ein Produktivsystem wird durch den Fluss von Verantwortung, Kontext und Berechtigung definiert – nicht durch die Zahl benannter Persönlichkeiten im Diagramm.

Die Agentenzahl ist ein Implementierungsdetail. Die Verantwortungsverteilung ist die Architektur.

02Der Ausgangspunkt

Ein fähiger Agent sollte der Ausgangspunkt bleiben.

Ein einzelner Agent mit klaren Anweisungen und getrennten Tools kann bereits überraschend vielfältige Arbeit erledigen. Er ist leichter verständlich, schneller und günstiger zu evaluieren als ein Agentennetz. Bei Fehlern gibt es weniger Prompts, Übergaben und Zustandsänderungen zu untersuchen.

Ein zusätzlicher Agent ist ein weiterer probabilistischer Entscheider. Hinzu kommen Kommunikationsgrenze, Kontextfenster, Modellaufrufe und ein weiterer Ort für Stopps, Wiederholungen oder die selbstsichere Weitergabe schwacher Arbeit. Zwei Agenten können übereinstimmen und trotzdem falsch liegen. Ein Prüfagent kann denselben blinden Fleck wie der geprüfte Agent haben.

Beginnen Sie mit mehreren Agenten, weil die Arbeit Trennung verlangt, nicht weil die Architektur fortschrittlich aussieht. Machen klarere Tools, besserer Kontext und engere Spezifikation einen Agenten verlässlich, ist ein zweiter Aufwand statt Intelligenz.

03Mehr als Rollenspiel

Ein neuer Jobtitel ist noch keine neue Agentengrenze.

Rechercheur, Stratege, Autor und Kritiker passen leicht in vier Prompt-Felder. Vier Personas beweisen aber nicht den Bedarf an vier unabhängigen Agenten. Dasselbe Modell kann überlappenden Kontext erhalten, dieselben Tools nutzen und jede Phase nach derselben vagen Anweisung beurteilen. Das System vervielfacht Gespräche, ohne Verantwortung zu trennen.

Eine sinnvolle Agentengrenze verändert etwas Betriebliches. Der Agent braucht vielleicht Daten, die ein anderer nicht sehen darf. Er nutzt andere Tools, eine spezialisierte Wissensbasis, läuft parallel, folgt einem anderen Bewertungsstandard oder gehört zu einem anderen Unternehmensbereich.

Die Grenze sollte Kontrolle oder Verbesserung erleichtern. Kann niemand erklären, was durch Trennung sicherer, klarer, schneller oder genauer wird, lassen Sie die Rolle im bestehenden Agenten oder setzen sie als deterministischen Schritt um.

04Der Entscheidungstest

Geben Sie jedem vorgeschlagenen Agenten einen eigenständigen Existenzgrund.

Multi-Agenten-KI ist gerechtfertigt, wenn die Arbeit sichtbar bleibende Grenzen enthält. Diese Fragen prüfen, ob ein vorgeschlagener Agent eine solche verantwortet. Ein einziges starkes Ja kann bei wesentlichen Folgen genügen. Viele schwache Vielleichts bedeuten meist, dass die Architektur dem Trend statt der Aufgabe folgt.

  • Braucht dieser Arbeitsteil Kontext, der anderswo ablenken, überlasten oder widersprechen würde?
  • Braucht er Tools oder Berechtigungen, die vom Rest des Systems isoliert sein sollten?
  • Kann er unabhängig oder parallel laufen, ohne unfertige Arbeit eines anderen Agenten zu benötigen?
  • Braucht er ein eigenes Modell, eigene Anweisungen oder eine eigene Definition akzeptabler Qualität?
  • Muss eine separate zuständige Person diese Fähigkeit über die Zeit prüfen, freigeben oder verbessern?
  • Lassen sich Eingabe, Ausgabe und Stoppbedingung klar genug benennen, um die Übergabe zu testen?

Fügen Sie einen Agenten dort hinzu, wo Trennung das System verbessert – nicht dort, wo ein weiteres Etikett das Diagramm verbessert.

VERWANDTE FIELD NOTE

Eine nützliche Agentengrenze definiert Umfang, Berechtigung, Schwellen, Eskalation und Wiederherstellung – nicht bloß ein Spezialistenetikett.

Ihr KI-Agent braucht nicht mehr Autonomie. Er braucht bessere Grenzen.
05Die Kontrollschicht

Der Orchestrator trägt die Verantwortung, die die Agenten nicht tragen können.

Spezialagenten werden nicht allein durch Nachrichtenaustausch zum System. Etwas muss das ursprüngliche Ziel interpretieren, nötige Arbeit bestimmen, verteilen, relevanten Zustand bewahren, Abhängigkeiten behandeln und die Fertigstellung des Gesamtergebnisses bestimmen.

Dieser Koordinator kann ein KI-Manager, deterministische Workflow-Logik oder eine Mischung sein. Die Wahl sollte den Folgen entsprechen. Flexibles Denken hilft, wenn der Weg von Entdeckungen abhängt. Feste Zuordnung ist sicherer, wenn Richtlinien den nächsten Schritt bereits bestimmen.

Auch die Orchestrierungsschicht braucht Grenzen: maximale Agenten- und Schrittzahl, Zeit- und Kostenbudgets, Wiederholungsregeln, Freigabepunkte, Eskalationswege und eine Fertigdefinition. Ohne diese Kontrollen wird Zusammenarbeit zur offenen Schleife, finanziert mit Tokens und Optimismus.

06Wo Systeme scheitern

Eine Übergabe braucht einen Vertrag, kein Gespräch.

Viele Multi-Agenten-Fehler entstehen zwischen fähigen Agenten. Der erste liefert eine überzeugende Zusammenfassung, lässt aber nötige Belege weg. Zwei Agenten verstehen dieselbe Kundenphase unterschiedlich. Ein Aktionsagent erhält eine Empfehlung ohne Freigabestatus. Bei jeder Übergabe schrumpft Kontext, bis der letzte Agent auf einer selbstsicheren Abstraktion des ursprünglichen Problems handelt.

Definieren Sie Pflichtinhalte jeder Übergabe: Aufgabe, relevante Belege, Quellenverweise, Annahmen, Sicherheit, bereits getroffene Entscheidungen, erlaubte nächste Aktionen und Rückgabebedingung. Strukturierte Ausgaben helfen; das Schema zählt aber nur, wenn es die für den nächsten Agenten nötige geschäftliche Bedeutung abbildet.

Gemeinsames Gedächtnis sollte nicht bedeuten, jedem Agenten das ganze Protokoll zu geben. Es sollte verwalteten Zustand bedeuten: aktuelle Fakten, Entscheidungen, Zuständigkeit und Historie, die Agenten rollenabhängig lesen können. Mehr Kontext ist nicht gleich gemeinsames Verständnis.

07Ein geschäftliches Beispiel

Machen Sie aus dem Organigramm keine Agentenarchitektur.

Stellen Sie sich ein System vor, das auf ein relevantes Kundensignal reagiert. Eine Komponente erfasst das Ereignis und validiert den Kunden. Ein Rechercheagent untersucht Unternehmen und Kaufkontext. Ein Entscheidungsagent vergleicht Belege mit Qualifizierungsregeln. Ein Kanalspezialist bereitet die passende Reaktion vor. Ein Mensch genehmigt eine folgenreiche Aktion, bevor CRM und Ansprachetools aktualisiert werden.

Das kann mehrere Agenten rechtfertigen, weil Recherche, Geschäftsentscheidung und externe Aktion unterschiedliche Kontexte, Tools, Berechtigungen und Evaluierungen brauchen. Es verlangt nicht allein wegen bestehender Abteilungen separate Marketing-, Vertriebs- und Kundenserviceagenten. Nachgebaute Abteilungsgrenzen können genau die Fragmentierung reproduzieren, die das System beseitigen soll.

Die Agenten sollten gemeinsamen Kunden- und Geschäftskontext nutzen und zugleich eng begrenzte Befugnisse haben. Marketingbelege können Vertriebsentscheidungen verbessern. Servicehistorie kann unpassende Akquisenachrichten stoppen. Orchestrierung sollte die Customer Journey verbinden, nicht jedes Silo effizienter automatisieren.

08Nach der Demo

Evaluieren Sie die Spezialisten und ihr gemeinsames System.

Ein gutes Ergebnis zeigt nicht, welchem Teil eines Multi-Agenten-Systems das Verdienst gehört. Ein schlechtes zeigt nicht den Fehlerbeginn. Der Betrieb braucht Ablaufspuren mit Delegation, Belegen, Tool-Aufrufen, Zustandsänderungen, Übergaben, Wiederholungen und Endaktion.

Evaluieren Sie jeden Agenten nach seiner Verantwortung, dann vollständige Durchläufe mit realistischen Fällen. Messen Sie Doppelarbeit, Widersprüche, Belegverlust, Budgetüberschreitungen oder Verzögerungen, die Parallelitätsvorteile aufheben. Testen Sie Teilversagen: Zeitüberschreitung eines Agenten, fehlende Quelle, entzogene Berechtigung oder widersprüchliche Ergebnisse.

Benennen Sie eine Gesamtverantwortung. Spezialzuständigkeit ist nützlich, aber Kunden und Revenue-Teams erleben das gemeinsame Ergebnis. Jemand muss entscheiden, ob die Architektur noch jeden Agenten braucht – und einen entfernen, wenn ein einfacheres System die Arbeit inzwischen besser erledigt.

Multi-Agenten-KI verdient Vertrauen, wenn Verantwortung sichtbarer wird, nicht verteilter.

Belege und weiterführende Lektüre.

01OpenAI: Ein praktischer Leitfaden zur Entwicklung von Agenten

Praktische Hinweise zum Start mit einem Agenten, zu mehreren Agenten bei schwieriger Logik oder Tool-Auswahl und zur Wahl von Manager- oder Übergabemustern.

02Anthropic: Wie wir unser Multi-Agenten-Recherchesystem gebaut haben

Ein Praxisbericht zu Orchestrator-Worker-Architektur, paralleler Recherche, Delegationsfehlern, Token-Kosten, Beobachtbarkeit und Evaluierung.

03Microsoft: Zwischen Einzelagenten- und Multi-Agenten-System wählen

Entscheidungshilfe zu Verantwortlichkeitstrennung, Sicherheits- und Compliance-Grenzen, mehreren Teams, Skalierbarkeit und zusätzlicher Koordinationslast.

04AWS: Multi-Agenten-Orchestrierung

Well-Architected-Hinweise zu Agentenkoordination, Orchestrierungsmustern, gemeinsamem Kontext, Fehlerbehandlung, Beobachtbarkeit und Governance.

DER WÖCHENTLICHE BEGLEITER

Frisches KI-Signal, geschäftlich eingeordnet.

AI Laundry beobachtet die Woche. Field Notes macht die dauerhaften Ideen nutzbar.

Kein tägliches Rauschen. Kein wiederaufgewärmter Hype. Jederzeit abbestellbar. Lesen Sie unsere Datenschutzerklärung.