/ Florian Stompe

Warum die meisten Agentic-Piloten an der Integration scheitern

Mehr als die Hälfte agentischer Marketing-Pilotprojekte scheitert daran, dass Agenten keinen funktionierenden Zugriff auf die Systeme haben, die sie steuern sollen.

integration mcp observability agentic-ai

Die Architektur steht, die Rollen sind definiert, das Framework ist installiert – und trotzdem passiert nichts. Der Content-Agent kann nicht ins CMS schreiben. Der Decisioning-Agent bekommt keine Daten aus der CDP. Der Distribution-Agent kann die Ad-Plattform nicht steuern. Das ist kein konstruierter Fall, sondern der häufigste Grund, warum agentische Pilotprojekte im Marketing stecken bleiben: Mehr als die Hälfte scheitert nicht an der KI, sondern an der Infrastruktur dahinter.

Das Problem liegt selten an der Modellqualität - die ist bei den heutigen Frontier-Modellen hervorragend. Es liegt daran, dass Integration in den Tech-Stack als nachgelagerte Aufgabe behandelt wird – etwas, das man klärt, nachdem die Architektur steht, statt etwas, das die Architektur von Anfang an mitdenkt.

Die Verbindung ist der leichte Teil

Ein Agent, der handeln soll, braucht Zugriff: auf die CDP, um Kundendaten zu lesen, auf das CMS, um Content zu veröffentlichen, auf die Ad-Plattform, um Kampagnen zu steuern. Vier Muster decken in der Praxis fast jeden Fall ab: API-basierte Integration, Webhooks, ereignisgesteuerte Architekturen und das Model Context Protocol (MCP).

MCP ist dabei der interessanteste Fall, weil es das eigentliche Skalierungsproblem löst. Ohne einen gemeinsamen Standard braucht jede Kombination aus Agent und System einen eigenen, handgebauten Adapter – bei fünf Agenten und sechs Systemen sind das im schlechtesten Fall dreißig Einzelintegrationen, jede mit eigenen Fehlern, eigener Wartung, eigenem Risiko. Ist für ein System einmal ein MCP-Server gebaut, kann jeder MCP-kompatible Agent ohne zusätzliche Integrationsarbeit darauf zugreifen. Der Skalierungsaufwand wächst nicht mehr quadratisch, sondern nur noch linear.

Diese technische Verbindung herzustellen, ist aber der einfache Teil. Er lässt sich in einem Sprint erledigen und in einer Demo zeigen. Was Agenten-Systeme in der Praxis zum Scheitern bringt, liegt eine Ebene tiefer.

Wo es wirklich schwierig wird

Vier Details entscheiden in der Praxis, ob eine Integration trägt oder unter Last zusammenbricht.

Schreibrechte, die zu weit gefasst sind. Ein Agent, der Segmente in der CDP aktualisieren soll, braucht dafür nicht automatisch Schreibzugriff auf das komplette Kundenprofil. Je weiter die Rechte gefasst sind, desto größer der Schaden, wenn ein Agent einen Fehler macht – und Agenten machen Fehler.

Daten, die zu alt sind. Ein Decisioning-Agent, der auf einem Datenstand von gestern entscheidet, trifft heute die falsche Entscheidung – etwa wenn ein Kunde inzwischen widerrufen oder gekauft hat. Wer wurde noch nicht von Retargeting-Ads für Produkte verfolgt, die er längst gekauft hat. Wie aktuell die Datenanbindung sein muss, hängt vom Anwendungsfall ab, aber die Frage muss beim Entwurf beantwortet werden, nicht erst, wenn der erste Beschwerdefall auftaucht oder die Kosten aus dem Ruder laufen.

Token-Kosten, die niemand eingeplant hat. Ein Agent, der bei jedem der 100.000 täglichen Kundenkontakte mehrere API-Aufrufe und Modell-Calls auslöst, kann schnell in einen Kostenbereich laufen, der im ursprünglichen Business Case so nicht berücksichtigt wurde. Token-Kosten gehören daher vor dem Rollout auf dem Tisch gelegt.

Audit-Logs, die nachträglich lückenhaft sind. Wenn eine Entscheidung sich im Nachhinein nicht mehr rekonstruieren lässt – welche Daten lagen vor, welche Regel griff, welches Ergebnis kam heraus –, ist das Problem nicht nur ein Compliance-Risiko. Es bedeutet auch, dass niemand aus dem Fehler lernen kann.

Was du nicht siehst, kannst du nicht kontrollieren

Für Agenten gilt das in besonderer Weise, weil sich Fehler nicht lokal halten lassen – sie wandern durch die Architektur. Ein Workflow aus sieben aufeinanderfolgenden Agenten-Tasks mit je nur zwei Prozent Fehlerchance pro Schritt läuft rechnerisch nur noch in 87 Prozent der Fälle vollständig fehlerfrei durch. Bei täglich tausenden Ausführungen ist das kein Fakt, der ignoriert oder auf die lange Bank geschoben werden darf.

Ein System ohne Monitoring und Tracing zeigt diese Fehler nicht an – es lässt sie einfach passieren. Ein fehlerhafter Agent mit zu weit gefassten Schreibrechten überschreibt dann nicht einen Kundendatensatz, sondern potenziell alle, die in seinem Zugriffsbereich liegen. Der Unterschied zwischen einem kontrollierbaren und einem unkontrollierbaren System liegt selten am Modell – er liegt daran, ob jemand von Anfang an hinschaut.

Hinzu kommt: Seit August 2026 verlangt der EU AI Act für bestimmte KI-Anwendungen dokumentierte Aufsichtsmechanismen und Protokollierung. Ein Audit-Trail, der von Tag eins mitgebaut wird, ist damit Teil der technischen Grundausstattung – genau wie Monitoring und Tracing.

Was das konkret heißt

Vier Punkte, die sich vor dem ersten produktiven Rollout klären lassen:

Rechte pro Agent statt pro System definieren. Statt „Agent X darf auf die CDP zugreifen”: genau festlegen und dokumentieren, welche Felder er lesen und welche er schreiben darf – und warum.

Auf Standards statt auf Einzeladapter setzen. Wo mehrere Agenten auf dasselbe System zugreifen sollen, lohnt sich ein MCP-Server, auch wenn die erste Integration allein schneller mit einem einfachen API-Call gebaut wäre.

Monitoring vor dem ersten produktiven Task bauen. Tracing, Fehlerraten und Audit-Trail sind Kern-Architekturanforderungen, keine Ausbaustufe für später.

Die Fehlerquote pro Schritt kennen und die Kette durchrechnen. Ein einzelner Agent mit 98 Prozent Erfolgsquote klingt zuverlässig. Eine Kette aus mehreren solcher Agenten ist es rechnerisch nicht automatisch – das muss man vor dem Rollout durchrechnen und transparent machen.

Integration ist die Voraussetzung, unter der Agenten überhaupt handeln können – und der Punkt, an dem sich in der Praxis entscheidet, ob ein Pilotprojekt zum produktiven System wird oder eine gut dokumentierte Demo bleibt.


Kapitel 11 des Buchs behandelt die Integration entlang der 4D-Schichten im Detail: die vier Integrationsmuster in der Praxis, CDP- und Data-Warehouse-Anbindung, und wie Monitoring, Observability und Audit-Trails von Anfang an mitgebaut werden.

→ 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