/ Florian Stompe

Warum kein Tool dein Orchestrierungsproblem löst

Salesforce Agentforce, CrewAI, HubSpot Breeze: Jeder Agentic-Marketing-Anbieter verspricht Orchestrierung – und keiner kann sie strukturell liefern. Warum das so ist und was daraus für deine Stack-Entscheidung folgt.

tool-auswahl agentic-ai martech build-or-buy

Salesforce Agentforce, CrewAI, AutoGen, n8n, HubSpot Breeze: Fast jedes Marketing-Team, mit dem ich über Agentic AI spreche, hat binnen zwanzig Minuten eine Liste von fünf Tool-Kandidaten zusammen. Was meist fehlt, ist die Antwort auf die entscheidende Frage: Welches Problem soll welches Tool lösen? Diese Lücke ist das derzeit größte strukturelle Problem im Agentic-Marketing-Markt – und sie lässt sich leider nicht durch die Wahl des richtigen Anbieters schließen.

Die Liste wächst, die Klarheit nicht

Der Agentic-Marketing-Markt 2026 ist unübersichtlich, wächst schnell und ist tief fragmentiert. Jeder Anbieter verspricht, das Orchestrierungsproblem zu lösen. Viele liefern tatsächlich etwas in dieser Richtung – aber nur einen Ausschnitt, begrenzt auf das eigene Silo. Salesforce orchestriert hervorragend innerhalb von Salesforce. CrewAI orchestriert hervorragend innerhalb eines selbst gebauten Agenten-Stacks. Keines der beiden kennt das andere.

Genau hier verlaufen sich die meisten Evaluierungsprozesse. Sie vergleichen Features – Konversationsqualität, Anzahl vorgefertigter Workflows, Preismodell – und übersehen die eigentliche Frage: Wer im Stack hat am Ende den Überblick über alle Agenten und Tools?

Das Orchestrierungs-Silo-Problem

Stell dir einen typischen Mittelständler vor: Salesforce für CRM, Klaviyo für E-Mail, Zendesk für Kundenservice, Google und Meta für Paid. Jede Plattform baut eigene Agenten, die innerhalb ihrer Plattform gut funktionieren. Ein Kunde öffnet ein Support-Ticket, weil ein Produkt defekt ist. Gleichzeitig läuft in Klaviyo eine Upselling-Sequenz für genau dieses Produkt. Google Ads retargeted denselben Kunden mit einer Kaufanzeige. Agentforce empfiehlt dem Vertrieb parallel ein Upgrade-Gespräch. Vier Systeme, vier Aktionen, keines weiß von den anderen drei.

Der Grund dafür ist nicht mangelnde Kompetenz der einzelnen Anbieter. Er ist ökonomisch: Ein Vendor, der Lizenzen für seine eigene Plattform verkauft, kann kein unparteiischer Orchestrator für den Gesamtstack sein. Er wird immer zuerst die Fähigkeiten der eigenen Plattform ausbauen und optimieren – weil genau das sein Geschäftsmodell trägt. Das ist Geschäftslogik, und sie lässt sich nicht wegdiskutieren.

Die Konsequenz: Wer glaubt, mit dem Kauf einer ausreichend großen Enterprise-Suite das Orchestrierungsproblem zu lösen, wird in zwei Jahren an derselben Stelle stehen wie heute – nur mit höheren Lizenzkosten.

Im ersten Jahr sieht jede Suite vollständig aus, weil die Demo genau die Fälle zeigt, die innerhalb der eigenen Plattform liegen. Im dritten Jahr zeigen sich die Lücken an den Rändern – genau dort, wo mehrere Systeme gleichzeitig auf denselben Kunden wirken. Und genau dann ist der Wechsel am teuersten, weil inzwischen Prozesse, Schulungen und Datenflüsse an die Plattform gebunden sind.

Warum ein offener Standard allein auch nicht reicht

Das Model Context Protocol (MCP) und vergleichbare offene Integrationsstandards lösen einen Teil des Problems: Sie machen es technisch möglich, dass Agenten unterschiedlicher Anbieter Daten und Werkzeuge austauschen, ohne dass jede Verbindung einzeln programmiert werden muss. Das ist ein gewaltiger Fortschritt gegenüber proprietären APIs, die jede Integration zum eigenen Projekt machen.

Ein Standard ersetzt aber keine Entscheidungslogik. MCP sorgt dafür, dass ein Decisioning-Agent auf die Daten einer CDP zugreifen kann. Es entscheidet nicht, wessen Empfehlung Vorrang hat, wenn CRM-Agent und E-Mail-Agent gleichzeitig mit demselben Kunden interagieren wollen. Diese Entscheidung braucht eine Instanz, die über den einzelnen Plattformen steht – einen Orchestrierungs-Layer, der Zielkonflikte zwischen Agenten auflöst, bevor sie beim Kunden wirksam werden. Kein Tool-Anbieter wird diese Instanz freiwillig außerhalb der eigenen Plattform ansiedeln.

Build-versus-Buy, schichtweise statt pauschal

Die Frage ist deshalb nicht binär zwischen alles selbst bauen und alles kaufen. Für die meisten mittelgroßen DACH-Unternehmen funktioniert ein hybrider Ansatz – und zwar Schicht für Schicht entschieden, nicht für den gesamten Stack auf einmal.

Enterprise-Suiten wie Salesforce Agentforce oder HubSpot Breeze sind oft die richtige Wahl für die Schichten, in denen sie bereits der operative Datenhalter sind – CRM-Interaktionen, E-Mail-Ausführung. Developer-Frameworks wie CrewAI oder LangGraph eignen sich für die Schicht, die den Gesamtüberblick behalten soll: den Orchestrierungs-Layer, der plattformübergreifend Prioritäten setzt. No-Code-Plattformen wie n8n sind ein pragmatischer Einstieg für einzelne, klar begrenzte Workflows, ohne dass gleich ein Entwicklerteam involviert sein muss.

Eine Anforderung gilt dabei unabhängig von der Schicht: offene APIs. Jede Komponente im Stack ohne vollständige, dokumentierte API ist ein blinder Fleck in der Agenten-Architektur – ein Ort, an den kein Agent ohne Umweg über eine Exceltabelle gelangt.

Was das konkret heißt

Kaufe 2026 keine Orchestrierung, baue sie. Ein Enterprise-Vendor kann einzelne Schichten hervorragend abdecken. Die Entscheidungsinstanz, die Konflikte zwischen Plattformen auflöst, muss unabhängig von jeder einzelnen Plattform liegen – sonst optimiert sie strukturell für den Anbieter, nicht für den Kunden.

Prüfe jede Tool-Entscheidung gegen die API. Eine beeindruckende Produktdemo sagt wenig darüber aus, ob ein System sich in einen bestehenden Stack einbinden lässt. Die entscheidende Frage ist, ob jede relevante Funktion über eine offene, dokumentierte API erreichbar ist – nicht nur über die eigene Oberfläche.

Entscheide schichtweise, nicht pauschal. Lege für jede der sechs Marketing-OS-Schichten – Data, Decisioning, Design, Distribution, Orchestrierung, Measurement – einzeln fest, ob Kaufen oder Bauen die richtige Antwort ist. Eine pauschale Plattform-Entscheidung für den gesamten Stack ignoriert, dass die Anforderungen pro Schicht fundamental unterschiedlich sind.

Miss den Fortschritt an der Integrationstiefe, nicht an der Tool-Anzahl. Fünf gut integrierte Agenten, die sich gegenseitig Daten liefern, schlagen fünfzehn Einzel-Tools, die nebeneinander laufen. Die Zahl der Lizenzen ist kein Fortschrittsindikator.

Verhandle den Ausstieg mit, bevor du unterschreibst. Datenexport-Rechte, Kündigungsfristen und die Frage, wem die über Monate trainierten Agenten-Konfigurationen am Ende gehören, sind vor der Unterschrift Verhandlungsmasse. Nach der Unterschrift sind sie ein Abhängigkeitsverhältnis.


Kapitel 10 des Buchs behandelt die Tool- und Plattformlandschaft für Agentic Marketing im Detail: welche Kategorien den Markt 2026 prägen, wo die Grenzen der Enterprise-Lösungen liegen – und wie die Build-versus-Buy-Matrix für jede der sechs Marketing-OS-Schichten konkret aussieht.

→ Zum Buch

Newsletter

Agentic Marketing Weekly

Eine These zu Agentic Marketing, ein konkretes DACH-Szenario, und was du konkret damit anfangen kannst. In 5 Minuten gelesen.

Jetzt abonnieren

← Alle Artikel