Orchestration Layer: Wie Marketing-Agenten koordiniert werden

Marketing-Orchestrierung mit KI wird meistens als Integrationsthema diskutiert: Systeme verbinden, Daten synchronisieren, Schnittstellen bauen. Der eigentliche Engpass liegt woanders. Sobald mehrere Agenten auf denselben Kunden zugreifen, entsteht eine spannende Frage: Wer hat Vorrang?

Diese Frage lässt sich technisch vorbereiten aber nur fachlich entscheiden. Orchestrierungsvorhaben scheitern also oft an einer Stelle, an der niemand ein Problem vermutet hat.

Der Fall, an dem es sichtbar wird

Ein Kunde zeigt Abwanderungssignale. Das Churn-Modell im Data-Team empfiehlt eine Reaktivierung mit Rabatt. Parallel läuft für dasselbe Konto eine Upselling-Kampagne, die das größere Paket bewirbt. Und im Service liegt seit gestern eine offene Beschwerde über eine fehlerhafte Lieferung. In größeren Unternehmen mit verteilten Verantwortlichkeiten ist solch ein Fall nicht erst seit dem KI-Zeitalter eine Herausforderung.

Drei Systeme, drei korrekte Entscheidungen im jeweils eigenen Rahmen. Für den Kunden ergibt das eine Woche, in der er ein Rabattangebot, eine Preiserhöhung und keine Antwort auf seine Beschwerde bekommt.

Nun könnte man einwenden: Dafür haben wir doch eine Journey-Engine. Nur koordinieren CRM-native Orchestratoren innerhalb ihres eigenen Systems. Das Churn-Modell läuft im Data-Warehouse, der Servicefall im Ticketing, die Kampagne in der Ad-Plattform. Was dort passiert, taucht in der Journey-Engine nicht auf. Koordiniert wird, was zufällig im selben Tool liegt — und das ist mit wachsender Zahl an Agenten ein immer kleinerer Anteil.

Was ein Orchestrierungs-Layer tatsächlich leisten muss

Die übergreifende Meta-Schicht, die hier fehlt, hat vier Aufgaben. Sie lassen sich unabhängig voneinander bewerten, und die meisten Stacks erfüllen genau eine davon.

Zustandsübersicht. Der Layer muss wissen, welche Aktivitäten an einem Kunden gerade laufen — über Systemgrenzen hinweg. Das schließt Dinge ein, die klassisch nicht als Marketing gelten: offene Servicefälle, laufende Reklamationen, ein Mahnlauf in der Buchhaltung. Ohne diesen gemeinsamen Zustand entscheidet jeder Agent im Blindflug.

Zielhierarchie. Der Layer braucht eine Rangfolge der Unternehmensziele, gegen die er Konflikte auflösen kann. Ist Kundenbindung wichtiger als Zusatzumsatz? Gilt das immer oder nur oberhalb eines bestimmten Kundenwerts? Darf ein offener Servicefall jede werbliche Ansprache blockieren oder nur wenn es sich um eine Beschwerde handelt?

Priorisierungsentscheidung. Erst mit Zustand und Hierarchie kann der Layer entscheiden, welche Aktion ausgeführt wird, welche wartet und welche entfällt. Wichtig ist der Unterschied zwischen Warten und Entfallen: Eine pausierte Upselling-Ansprache soll nach Abschluss des Servicefalls wieder aufgenommen werden, nicht verloren gehen.

Protokoll. Jede dieser Entscheidungen muss nachvollziehbar sein — welche Aktion wurde wann zugunsten welcher anderen zurückgestellt und auf welcher Regel beruhte das. Ja, das ist ein Stück weit Compliance-Formalität, aber nicht nur. Ohne dieses Protokoll lässt sich nach drei Monaten nämlich nicht mehr feststellen, warum eine Kampagne unterdurchschnittlich lief — der Lerneffekt bleibt aus.

Warum MCP die Integrationsfrage entschärft

Bleibt das technische Problem: Ein Orchestrierungs-Layer muss mit vielen Systemen sprechen. Bei einem Stack mit 20 relevanten Systemen entstehen bei paarweiser Anbindung theoretisch bis zu 380 Integrationen — jede mit eigenem Wartungsaufwand und eigenem Ausfallrisiko. Das ist der Grund, warum Orchestrierungsprojekte historisch an der Integrationslast gestorben sind.

Das Model Context Protocol (MCP) adressiert genau das: ein standardisiertes Protokoll, über das Systeme ihre Fähigkeiten und Daten bereitstellen. Aus n×n Punkt-zu-Punkt-Verbindungen werden n Anbindungen an einen Standard. Salesforce, HubSpot, Atlassian und Slack haben mittlerweile, mit unterschiedlichem Reifegrad, MCP-Unterstützung implementiert.

Für Stack-Entscheidungen, die gerade getroffen werden, ist das ein handfestes Auswahlkriterium. Ein Tool ohne offenen Integrationsstandard bedeutet, dass jede Anbindung an die Orchestrierungsschicht ein eigenes Projekt wird.

Die Vorarbeit, die niemand delegieren kann

Der anstrengende Teil ist die Zielhierarchie. Sie ist keine technische Konfiguration, sondern eine Führungsentscheidung — und sie wird in den meisten Organisationen zum ersten Mal explizit, wenn ein Orchestrierungsprojekt danach fragt.

Der Grund dafür ist banal: Solange Menschen die Ausführung übernehmen, lösen sie Zielkonflikte im Einzelfall auf, ohne dass jemand eine Regel formulieren müsste. Die Kollegin im Kundenservice stoppt die Rabattmail, weil sie den offenen Fall kennt. Der Kampagnenmanager verschiebt den Versand, weil er von der Reklamation gehört hat. Diese tägliche stille Koordination ist der eigentliche Grund, warum der Widerspruch bisher selten sichtbar wurde.

Solange die Hierarchie fehlt, hilft auch die beste Schicht nicht. Sie hat dann nichts, woran sie sich halten könnte, und fällt auf das zurück, was ohnehin passiert: Wer zuerst auslöst, gewinnt.

Wie du vorgehst

Eine Reihenfolge, die in der Praxis trägt:

1. Zielkonflikte inventarisieren. Nimm die fünf Kundensituationen, in denen bei euch heute schon widersprüchliche Kommunikation entsteht. Diese Liste ist erfahrungsgemäß schnell zusammen und überzeugt Entscheider mehr als eine Architekturskizze.
2. Rangfolge festlegen und aufschreiben. Für jede dieser Situationen: Was hat Vorrang, ab welchem Schwellenwert, mit welcher Ausnahme? Das ist eine fachliche Runde mit Marketing, Vertrieb und Service.
3. Sperrregeln definieren. Welche Zustände blockieren jede werbliche Ansprache vollständig? Offene Beschwerde, laufender Rechtsstreit, Mahnstufe zwei. Diese Regeln sind einfach, wirken sofort und lassen sich auch ohne vollständige Orchestrierungsschicht umsetzen.
4. Integrationsstandard zum Auswahlkriterium machen. Bei jeder anstehenden Tool-Entscheidung: Gibt es MCP-Unterstützung oder zumindest eine vollwertige schreibende API? Hier hakt es manchmal im Detail.
5. Mit einem Konfliktpaar starten. Nicht die vollständige Schicht bauen, sondern zwei konkurrierende Agenten koordinieren und das Protokoll dafür sauber aufsetzen. Alles Weitere ist dann die Wiederholung desselben Musters.

Der Aufwand liegt zu etwa gleichen Teilen in Technik und in Abstimmung. Unterschätzt wird regelmäßig der zweite Teil — weil er sich schlechter budgetieren lässt.

---

Kapitel 8 des Buchs beschreibt den Orchestrierungs-Layer im Detail: Zielhierarchien, Konfliktauflösung, MCP als Integrationsstandard und die Kopplung an den Measurement Layer, mit dem das System aus seinen Entscheidungen lernt.

→ Zum Buch