Der neue Marketing-Stack: Warum deine Architektur keine Agenten trägt

Der klassische Marketing-Stack ist ein Artefakt seiner Zeit. Er wurde in einer Ära gebaut, in der am Ende jeder Toolkette ein Mensch stand — um Daten zu interpretieren, Kampagnen freizugeben, Budgets zu verschieben.

Agenten brechen diese Annahme. Nicht weil sie besser sind, sondern weil sie anders arbeiten.

Die Grundlogik des klassischen Stacks

Schau dir einen typischen DACH-Mittelstands-Stack an: CRM, CDP oder Daten-Hub, Marketing Automation, Ads-Management, Analytics, Content-Produktion. Diese Tools sind miteinander verbunden, aber die Integrationslogik ist immer dieselbe: Daten fließen in Dashboards, Dashboards werden gelesen, Entscheidungen werden getroffen, die nächsten Tools werden bedient.

Daran ist nichts falsch — es ist nur nicht agentenfähig.

Was Agenten strukturell fordern

Ein Agent ist ein Programm, das Entscheidungen trifft und Aktionen auslöst. Damit er das kann, muss dein Stack drei Eigenschaften haben, die im klassischen Setup oft fehlen.

API-first statt UI-first Ein Agent bedient Tools nicht über die Benutzeroberfläche, sondern über APIs. Das klingt trivial, ist in der Praxis aber die häufigste Bruchstelle. Viele Marketing-Tools haben APIs, aber mit Lücken: Daten lassen sich ziehen, aber nicht alles schreiben. Oder schreiben geht, aber mit Rate-Limits, die jeden produktiven Betrieb ausschließen. Die Frage „Hat das Tool eine API?” ist die falsche. Die richtige ist: „Kann ein Agent damit produktiv arbeiten?”

Bidirektionale Integrationen Klassische Integrationen gehen häufig nur in eine Richtung — Daten rein, Reports raus. Ein Agent braucht beide Richtungen, und er braucht sie zeitnah. Er entscheidet nicht nur auf Basis von Daten, er löst Aktionen aus, die wieder Daten erzeugen, die seine nächste Entscheidung beeinflussen. Das ist kein ETL-Job, das ist ein Kreislauf.

Orchestration Layer Das ist die neue Schicht, die im klassischen Stack fehlt. Ein Agent koordiniert mehrere Tools in einer Aufgabe: Er liest aus dem Data Layer, generiert ein Creative, spielt es aus, misst, passt an. Diese Koordination ist nicht Aufgabe eines einzelnen Tools — sie liegt oberhalb der Tools. Frameworks wie LangGraph oder CrewAI sind Versuche, diese Schicht bereitzustellen, und die großen Plattformanbieter bauen sie in ihre Suites ein.

Wo dein Stack typischerweise bricht

In der Praxis sind es drei Stellen, an denen der klassische Stack agentische Workloads nicht trägt.

Identity Dein CRM kennt den Kunden als Datensatz. Dein Ads-System kennt ihn als Hash. Dein Web-Analytics kennt ihn als Device-ID. Solange ein Mensch am Ende einen Report liest, funktioniert das — die Zusammenhänge werden im Kopf hergestellt. Ein Agent, der in Echtzeit entscheidet, ob eine Nachricht ausgespielt wird, braucht Identity-Resolution auf Daten-Ebene. Nicht im Dashboard, sondern in der Pipeline.

Latenz Stündlich aktualisierte Daten sind okay, wenn ein Mensch sie liest. Für einen Agenten, der entscheidet, ob er eine Cart-Abandonment-Nachricht in den nächsten zehn Minuten abschickt, reicht das nicht. Wenn dein Stack auf nächtlichen ETL-Jobs basiert, fehlt dir die Basis für agentische Entscheidungen — nicht wegen schlechter Tools, sondern wegen der Kadenz.

Governance In einem Stack, der von Menschen bedient wird, ist Governance über Tool-Rechte geregelt: Wer darf was klicken. In einem Stack mit Agenten reicht das nicht. Du brauchst eine eigene Schicht, die definiert, was der Agent selbstständig darf, was er zur Freigabe vorlegen muss und was er protokollieren muss. Das ist keine Compliance-Formalität, das ist Betriebsinfrastruktur.

Wie du vorgehst

Die ehrliche Frage ist nicht „Welches Tool kaufe ich jetzt noch?”, sondern „Welche Schichten fehlen strukturell?”

Eine Reihenfolge, die in der Praxis trägt:

1. Data Foundation stabilisieren. Ohne konsistente, schnell zugreifbare Daten gibt es keinen sinnvollen Agenten. Das ist nicht der spannendste Schritt, aber der erste.
2. API-Qualität prüfen. Welche Tools in deinem Bestand lassen sich real von einem Agenten bedienen, welche nicht? Das ist oft eine ernüchternde Inventur.
3. Orchestration-Layer pilotieren. Starte mit einem umgrenzten Use Case — nicht „der Agent übernimmt alles”, sondern „der Agent betreut diese eine Kampagne”.
4. Governance von Anfang an einbauen. Audit-Trail, Eingriffspunkte, Freigabe-Logik. Nicht nachgelagert.

Das ist weniger Tool-Shopping und mehr Architektur-Arbeit. Und genau deshalb wird es oft unterschätzt: Weil ein neuer MarTech-Kauf sich besser präsentieren lässt als sechs Monate Foundation-Arbeit.

---

In den Kapiteln 3 bis 8 des Buchs baue ich die Referenzarchitektur im Detail auf: sechs Schichten, konkrete Tool-Entscheidungen, Build-or-Buy-Matrix. Nicht als Framework-Theorie, sondern als Arbeitsgrundlage.

→ Zum Buch