Multi-Agenten-Systeme im Marketing: Architektur und Governance

Multi-Agenten-Systeme im Marketing: Architektur, Governance und Evaluation

Ein Multi-Agenten-System im Marketing koordiniert zwei oder mehr klar abgegrenzte KI-Komponenten (Agenten), die in einem definierten Workflow jeweils eine eigene Rolle übernehmen. Sie arbeiten mit gemeinsamem Kontext, ausdrücklichen Übergaben, Berechtigungen und Evaluation, und die Entscheidungsrechte bleiben beim Menschen. Ein Multi-Agenten-System ist nicht zwangsläufig autonom, und es ist nicht immer besser als ein einziger kontrollierter Workflow. Welche Architektur passt, hängt davon ab, ob die zusätzliche Komplexität ihre Kosten tatsächlich wert ist.

Executive Summary

Immer häufiger wird jede Kette von Prompts als „Multi-Agenten-System“ bezeichnet, oder es werden Agenten in einen Workflow eingebaut, bevor geklärt ist, welchen gemeinsamen Zustand, welche Berechtigungen, welche Evaluation und welche menschliche Verantwortung sie brauchen. Die Komplexität wächst, der Nachweis eines Mehrwerts bleibt dünn. Eine Multi-Agenten-Architektur lohnt sich nur, wenn die Rollentrennung einen messbaren betrieblichen Nutzen bringt, der den zusätzlichen Aufwand für Koordination, Evaluation, Sicherheit und Wartung übersteigt. Dieser Leitfaden zeigt, wann mehrere Agenten gerechtfertigt sind und wann ein kontrollierter Workflow besser abschneidet, welche Architekturmuster es gibt, wie der Agent Contract jeden einzelnen Agenten steuert und wie Evaluation, Observability und menschliche Entscheidungspunkte mit der Komplexität des Systems mitwachsen müssen.

Das Wichtigste in Kürze:

• Nicht jede Kette KI-gestützter Schritte ist ein Multi-Agenten-System, und nicht jede Aufgabe profitiert davon, zu einem zu werden.
• Eine Multi-Agenten-Architektur ist nur gerechtfertigt, wenn die Spezialisierung einen messbaren Nutzen bringt, der die Kosten für Koordination und Wartung übersteigt.
• Jeder Agent in einem abgegrenzten System arbeitet unter einem Agent Contract. Es ist dasselbe Steuerungsinstrument, das kōdōkalabs für einzelne KI-gestützte Aufgaben im Agentic Drafting einsetzt, hier auf der Ebene der einzelnen Agenten-Komponente angewendet.
• Die Evaluation muss auf zwei Ebenen stattfinden: beim einzelnen Agenten und beim Gesamtsystem. Ein System kann scheitern, obwohl jede Komponente ihren eigenen Test besteht.
• Mehr Agenten und mehr Autonomie sind nicht von vornherein besser. Die richtige Architektur ist die, die zu den tatsächlichen Anforderungen der Aufgabe passt.

Was ist ein Multi-Agenten-System im Marketing?

Ein Multi-Agenten-System im Marketing ist ein definierter Workflow, in dem zwei oder mehr abgegrenzte KI-Komponenten mit jeweils eigener Rolle über gemeinsamen Kontext, ausdrückliche Übergaben und festgelegte Berechtigungen zusammenarbeiten, um ein Ergebnis zu erzeugen. Menschliche Entscheidungsrechte sind an den passenden Stellen fest eingebaut und werden nicht einfach vorausgesetzt. Das Wort „abgegrenzt“ ist entscheidend: Jeder Agent hat einen bestimmten, begrenzten Verantwortungsbereich mit eigenen Werkzeugen und eigener Befugnis, statt eines offenen Auftrags, alles zu tun, was gerade hilfreich erscheint.

Multi-Agenten-System, Workflow-Automatisierung und Einzel-Agent im Vergleich

Diese drei Ansätze werden oft in einen Topf geworfen, sind aber grundverschiedene Architekturen mit unterschiedlichen Zielkonflikten.

Ein System wird nicht schon dadurch „multi-agentisch“, dass es ein Modell mehrfach nacheinander aufruft. Das ist häufig nur ein mehrstufiger Workflow mit einem einzigen Agenten. Entscheidend ist, ob das System wirklich getrennte, abgegrenzte Rollen hat, jeweils mit eigenem Contract, eigenen Werkzeugen und eigener Evaluation, die untereinander koordiniert arbeiten.

Wann mehrere Agenten gerechtfertigt sind

Der Agent Architecture Decision Test von kōdōkalabs prüft anhand von acht Faktoren, ob ein Multi-Agenten-Ansatz für eine bestimmte Aufgabe tatsächlich gerechtfertigt ist.

Eine Aufgabe, die bei den meisten dieser Faktoren gut abschneidet, ist ein vernünftiger Kandidat für mehrere Agenten. Eine Aufgabe, die bei den meisten schlecht abschneidet (etwa weil sie sich nicht natürlich aufteilen lässt, nicht von Spezialisierung profitiert und keine Parallelität braucht), ist mit hoher Wahrscheinlichkeit mit einem gut entworfenen Workflow besser bedient.

Es lohnt sich, diesen Test ausdrücklich anzuwenden und sich nicht auf das Bauchgefühl zu verlassen, denn das Bauchgefühl zeigt oft in die falsche Richtung. Eine Aufgabe, die so komplex wirkt, dass sie „mehrere Agenten braucht“, entpuppt sich bei näherem Hinsehen häufig als eine einzige komplexe Aufgabe, die ein gut spezifizierter Workflow Schritt für Schritt bewältigen kann. Komplexität in der Aufgabe selbst bedeutet nicht automatisch, dass die Aufteilung auf mehrere abgegrenzte Agenten die richtige Antwort darauf ist. Der Test trennt genau zwei Dinge: „Diese Aufgabe ist schwierig“ und „Diese Aufgabe hat wirklich trennbare Rollen, die von Spezialisierung profitieren“. Das sind verschiedene Eigenschaften, die überraschend oft verwechselt werden.

Wann ein kontrollierter Workflow besser ist

Der häufigste Architekturfehler bei Multi-Agenten-Systemen im Marketing: Agenten werden einer Aufgabe hinzugefügt, die mit einem einzigen, gut spezifizierten Workflow mit klaren Stufen besser bedient wäre. Multi-Agenten-Systeme verursachen echten Koordinationsaufwand. Der gemeinsame Zustand muss verwaltet, Übergaben müssen entworfen und getestet, Berechtigungen pro Agent eingegrenzt und die Evaluation auf mehreren Ebenen durchgeführt werden. Bei einer Aufgabe, die gut standardisiert ist, keine wirklich getrennten Spezialrollen braucht und nicht parallel laufen muss, ist dieser Aufwand reine Kostensache ohne Gegenwert. Ein einzelner kontrollierter Workflow, gegebenenfalls weiterhin KI-gestützt, ist einfacher zu bauen, leichter zu warten und besser nachzuvollziehen, wenn etwas schiefgeht.

Es gibt außerdem einen weniger offensichtlichen Kostenfaktor, der genannt werden sollte: die organisatorische Komplexität. Ein Multi-Agenten-System braucht auf Dauer meist mehr Menschen, die es verstehen und pflegen: Jemand muss den Contract jedes Agenten verantworten, jemand muss die agentenübergreifenden Evaluationsergebnisse deuten, und jemand muss einschätzen können, wie sich eine Änderung an einem Agenten auf die anderen auswirkt. Ein einzelner Workflow lässt sich dagegen oft von einer fähigen verantwortlichen Person verstehen, pflegen und verbessern. Teams, die prüfen, ob sie ein Multi-Agenten-System bauen sollen, sollten deshalb nicht nur den technischen Koordinationsaufwand aus dem Decision Test abwägen, sondern auch diesen organisatorischen Preis: Sie haben etwas gebaut, das mehr spezialisiertes Wissen im Haus verlangt, damit es gut weiterläuft.

Gängige Architekturmuster für Multi-Agenten-Systeme

Wenige wiederkehrende Muster decken die meisten sinnvollen Multi-Agenten-Anwendungen im Marketing ab.

Die Wahl des Musters sollte sich unmittelbar aus den Ergebnissen des Agent Architecture Decision Test ergeben. Eine Aufgabe mit hohem Parallelisierungspotenzial passt zum Muster der parallelen Spezialisten, eine Aufgabe, die schrittweise verfeinert werden muss, zur Evaluator-Schleife.

Der Agent Contract

Jeder Agent in einem abgegrenzten Multi-Agenten-System arbeitet unter einem Agent Contract. Es ist dasselbe Steuerungsinstrument, das kōdōkalabs auf der Seite zur Methodik Agentic Drafting verbindlich definiert, hier angewendet auf einen einzelnen Agenten innerhalb einer größeren Architektur statt auf eine einzelne Entwurfsaufgabe. Statt ein eigenes, konkurrierendes Konzept zu definieren, nutzt dieser Beitrag dieselben Felder: Zweck, erlaubte und verbotene Eingaben, Werkzeuge und Berechtigungen, erforderliche Quellen, Ausgabeschema, Validierungsregeln, Kennzeichnung von Sicherheit und Unsicherheit, Verhalten bei Fehlern und Eskalation (einschließlich Wiederholungslimits und Abbruchbedingungen), Übergaberegeln an den nächsten Agenten in der Abfolge, eine benannte menschliche verantwortliche Person, Version und Protokollierungsanforderungen.

Ein einheitlicher Agent Contract für KI-gestützte Einzelaufgaben und für Multi-Agenten-Architekturen hat über die Konsistenz hinaus einen praktischen Vorteil: Die Governance-Disziplin, die ein Team in einem Zusammenhang aufbaut, lässt sich direkt auf den anderen übertragen. Zwei parallele Regelwerke, die man lernen und pflegen müsste, entfallen.

Gemeinsames Wissen, Zustand und Gedächtnis

Multi-Agenten-Systeme brauchen einen definierten Umgang damit, welcher Kontext von allen Agenten geteilt wird und welcher nur einem einzelnen zugeordnet ist. Ein Agent mit uneingeschränktem Zugriff auf alles, was jeder andere Agent erzeugt hat, verliert die Vorteile der Isolation, derentwegen man die Rollen überhaupt getrennt hat. Ein Agent mit zu wenig gemeinsamem Kontext dagegen doppelt womöglich Arbeit oder widerspricht einer Entscheidung, die ein anderer Agent bereits getroffen hat. Der gemeinsame Zustand sollte aus der gesteuerten AI Marketing Knowledge Base der Organisation gespeist werden und nicht aus einem Ad-hoc-Mechanismus, der nur für das Multi-Agenten-System gebaut wurde. So gelten dieselben Regeln für Autorität und Aktualität durchgängig.

Werkzeugzugriff und Berechtigungsgrenzen

Jeder Agent sollte nur auf die Werkzeuge zugreifen können, die seine Rolle verlangt. Ein Recherche-Agent braucht kein Veröffentlichungsrecht, ein Entwurfs-Agent muss Produktivsysteme nicht verändern können. Wer Berechtigungen pro Agent eng fasst, statt aus Bequemlichkeit allen Agenten ein breites Paket zu geben, begrenzt den Schaden, den die Fehlfunktion oder Manipulation eines einzelnen Agenten anrichten kann, und macht das Verhalten des Systems in Reviews leichter nachvollziehbar.

Übergaben, Ausgabeschemata und Abbruchbedingungen

Eine Übergabe zwischen Agenten braucht ein definiertes Ausgabeschema: was genau der empfangende Agent erwartet. So gehen Informationen auf dem Weg zwischen den Komponenten nicht verloren oder werden missverstanden. Abbruchbedingungen legen fest, wann das System anhalten soll: bei erfolgreichem Abschluss, in einem definierten Fehlerzustand oder wenn ein Wiederholungslimit erreicht wurde, ohne dass es geklappt hat. Ein Multi-Agenten-System ohne klare Abbruchbedingungen läuft Gefahr, endlos zu kreisen oder ein unvollständiges Ergebnis so weiterzureichen, als wäre es fertig.

Menschliche Entscheidungspunkte

Multi-Agenten-Systeme machen die menschlichen Entscheidungspunkte, die wir im Beitrag zum Human-in-the-Loop beschreiben, nicht überflüssig. Im Gegenteil: Durch die zusätzliche Komplexität wird es wichtiger, diese Punkte bewusst zu platzieren. Eine Freigabe nach dem letzten Syntheseschritt, bevor ein folgenreiches Ergebnis weiterläuft, bleibt unverzichtbar, egal wie viele spezialisierte Agenten dazu beigetragen haben.

Evaluation auf Agenten- und Systemebene

Wer nur das Endergebnis eines Multi-Agenten-Systems prüft, übersieht Fehler, die mitten in der Pipeline entstehen. Ein Agent, der gelegentlich ein subtil fehlerhaftes Ergebnis liefert, kann diesen Fehler durch mehrere nachgelagerte Agenten tragen, bevor er in einer Form auftaucht, die die Endprüfung erkennt. Dann ist es viel schwerer, die eigentliche Ursache zu finden. Wirksame Evaluation findet auf beiden Ebenen statt: Jeder Agent wird an den Validierungsregeln seines eigenen Agent Contract gemessen, das Gesamtsystem an den Erfolgskriterien der Aufgabe von Anfang bis Ende. Ein System, das die Endprüfung besteht, obwohl ein Agent unbemerkt unterdurchschnittlich arbeitet, ist fragil. Es wird beim nächsten Mal, wenn sich die Bedingungen leicht verschieben, wahrscheinlich sichtbarer scheitern.

Observability, Logs und Untersuchung von Vorfällen

Multi-Agenten-Systeme brauchen eine Protokollierung, die detailliert genug ist, um zu rekonstruieren, was jeder Agent in welcher Reihenfolge mit welchen Ein- und Ausgaben getan hat. Geht etwas schief, lässt sich so der konkrete Agent und der konkrete Schritt identifizieren, der das Problem verursacht hat, und man weiß nicht nur, dass das Endergebnis fehlerhaft war. Diese Anforderung an die Observability wächst mit der Zahl der Agenten: Ein System mit fünf Agenten und ohne Protokollierung pro Agent lässt sich erheblich schwerer debuggen als ein Einzel-Agent-Workflow mit derselben Lücke, einfach weil es mehr Stellen gibt, an denen das Problem entstanden sein kann.

Kosten, Latenz, Zuverlässigkeit und Wartung im Abwägen

Multi-Agenten-Architekturen kosten im Betrieb in der Regel mehr als ein einzelner gut entworfener Workflow: mehr Modellaufrufe, mehr Koordinationsaufwand und oft höhere Latenz, weil die Agenten nacheinander übergeben und nicht ein einziger Durchlauf die Aufgabe erledigt. Die Zuverlässigkeit kann durch Fehlerisolation steigen (der Ausfall eines Agenten reißt nicht zwingend das ganze System mit) oder durch die zusätzliche Komplexität sinken (mehr Komponenten bedeuten mehr mögliche Fehlerquellen). Der Wartungsaufwand steigt mit der Zahl der Agenten, denn jeder braucht einen eigenen Contract, eigene Tests und regelmäßige Neuvalidierung. Diese Zielkonflikte sollten ausdrücklich gegen die Einschätzung des Nutzens der Spezialisierung im Agent Architecture Decision Test abgewogen werden: Der Mehraufwand lohnt sich nur, wenn der Nutzen real und messbar ist.

Beispiele für Anwendungsfälle im Marketing

Recherche und Briefing

Ein Recherche-Agent sammelt und validiert Quellenmaterial, ein Briefing-Agent verdichtet es zu einem strukturierten Briefing für die menschliche Prüfung. Die Rollen sind trennbar und haben unterschiedliche Werkzeugbedürfnisse (Suche und Abruf gegenüber strukturiertem Schreiben).

Content-Produktion

Ein Planungs-Agent strukturiert einen Inhalt, ein Entwurfs-Agent erstellt den Text, ein Faktencheck-Agent gleicht Aussagen mit dem Claim Register ab, das im Agentic Drafting beschrieben ist. Es sind klar getrennte Spezialrollen mit unabhängigen Evaluationskriterien.

Search Intelligence

Ein Entitäten-Recherche-Agent sammelt strukturierte Daten zu einem Thema, ein Analyse-Agent erkennt Muster oder Lücken gegenüber Wettbewerbern. Diese Rollen profitieren davon, dass sie für viele Themen gleichzeitig parallel laufen können.

Kampagnenbetrieb

Ein Planungs-Agent für Termine übernimmt Logistik und Timing, ein Compliance-Agent prüft Ergebnisse gegen freigegebene Vorgaben, bevor sie veröffentlicht werden. Beide lassen sich sowohl nach Werkzeugzugriff als auch nach dem Risikoprofil dessen trennen, was sie jeweils abfangen sollen.

Reporting und Analyse

Ein Datenabruf-Agent holt Leistungskennzahlen aus den führenden Systemen, ein Berichts-Agent macht aus geprüften Zahlen eine schriftliche Zusammenfassung. Das ist eine naheliegende Trennung zwischen strukturierter Datenverarbeitung und Textgenerierung.

Nicht jeder dieser Anwendungsfälle braucht in jeder Organisation eine Multi-Agenten-Architektur. Dieselben Aufgaben lassen sich oft mit einem einzelnen gut entworfenen Workflow gut lösen, besonders bei geringerem Volumen oder geringerer Komplexität. Die Beispiele zeigen, wo Rollentrennung tendenziell echten Mehrwert schafft. Sie sind keine Vorgabe, dass jedes Marketingteam für jeden dieser Fälle ein Multi-Agenten-System bräuchte.

Pilot und Produktionsreife

Bevor ein Multi-Agenten-System in Richtung Produktivbetrieb geht, sollte es einen Pilot Review durchlaufen, mit Testfällen, die gezielt auf multi-agentenspezifische Fehlerbilder zielen: Was passiert, wenn ein Agent ein fehlerhaft aufgebautes Ergebnis liefert, auf das sich ein anderer Agent stützt? Was passiert, wenn eine Übergabe mittendrin scheitert? Und reicht die Observability des Systems aus, um einen Fehler im Nachhinein zu diagnostizieren? Ein Multi-Agenten-System, das in einer sauberen Demonstration gut funktioniert, aber unter diesen Bedingungen nie getestet wurde, ist nicht sinnvoll für den Produktivbetrieb validiert.

Typische Fehlerbilder

• Komplexität ohne Rechtfertigung: ein Multi-Agenten-System für eine Aufgabe, die ein einzelner kontrollierter Workflow genauso gut und günstiger erledigen würde.
• Unbegrenzter Agenten-Auftrag: ein Agent mit offenem Mandat statt eines definierten Contracts, der Zweck und Werkzeuge begrenzt.
• Zu viel gemeinsamer Kontext: Jeder Agent kann auf alles zugreifen, sodass die Isolationsvorteile der Rollentrennung entfallen.
• Keine Abbruchbedingungen: ein System, das kreisen oder ein unvollständiges Ergebnis weiterreichen kann, ohne definierten Haltepunkt.
• Evaluation nur am Ergebnis: Es wird nur das Endergebnis geprüft, und Fehler mitten in der Pipeline tauchen später unvorhersehbar auf.
• Zu wenig Observability: Die Protokollierung ist zu grob, um zu erkennen, welcher Agent oder Schritt ein Problem verursacht hat.
• Die Annahme, mehr Agenten bedeuten mehr Zuverlässigkeit: Zusätzliche Spezialisierung gilt als von vornherein sicherer, ohne Beleg, dass sie die Fehlerraten für die konkrete Aufgabe tatsächlich senkt.

Checkliste zur Architektur

Bevor Sie ein Multi-Agenten-System im Marketing bauen, bestätigen Sie: Der Agent Architecture Decision Test stützt einen Multi-Agenten-Ansatz tatsächlich gegenüber einem einzelnen Workflow. Jeder Agent hat einen vollständigen Agent Contract. Gemeinsames Wissen und gemeinsamer Zustand stammen aus der gesteuerten Wissensdatenbank. Der Werkzeugzugriff ist pro Agent eng gefasst. Übergaben haben definierte Ausgabeschemata. Abbruchbedingungen sind ausdrücklich festgelegt. Menschliche Entscheidungspunkte sind passend platziert. Die Evaluation findet auf Agenten- und Systemebene statt. Die Observability trägt die Untersuchung von Vorfällen. Und das System hat einen Pilot Review gegen multi-agentenspezifische Fehlerbedingungen bestanden.

Häufig gestellte Fragen

Fazit

Eine Multi-Agenten-Architektur ist ein mächtiges Werkzeug für wirklich trennbare, spezialisierte Marketingaufgaben und eine teure Komplikation für Aufgaben, die sie nicht brauchen. Die in diesem Leitfaden beschriebene Disziplin, vom Agent Architecture Decision Test bis zum gemeinsamen Agent Contract, trennt ein Multi-Agenten-System, das seine Komplexität verdient, von einem, das sie nur hinzufügt.

Sind Sie bereit, Ihr KI-Marketing-System zu entwerfen?

Executive Readiness Review anfragen