Suchergebnisse für: „Agenten“

Die Frau des Autors ist Vizepräsidentin für Marketing bei einem ordentlich gewachsenen Scale-up. Ihr Unternehmen setzt stark auf KI und nutzt Claude an vielen Stellen. Trotzdem klafft eine große Lücke zwischen dem Nutzen, den sie aus agentischer KI zieht, und dem, was der Autor als Techniker daraus holt. Das liegt nicht an ihren Fragen, sondern an der Bauweise der Systeme, mit denen sie arbeitet.

Dasselbe Muster wiederholt sich in Unternehmen jeder Größe. Auf der einen Seite stehen Marketingteams, die seit Jahren mit Kundendaten arbeiten und genau wissen, welche Fragen sie stellen wollen. Auf der anderen Seite steht eine Dateninfrastruktur, die für Menschen gebaut wurde, nicht für Agenten. Zwischen beiden liegt eine Lücke, und dort entsteht gerade ein neuer Typ Software, der in Fachkreisen als Agentic CDP diskutiert wird. Dieser Text ordnet die Entwicklung ein, ohne Übertreibung und mit Blick darauf, was technisch wirklich passiert.

Warum Agentic AI ausgerechnet im Marketing zuerst ankommt

Wenn man den sozialen Netzwerken und den einschlägigen Newslettern glaubt, ist Agentic AI längst überall. Der Autor einer aktuellen Analyse widerspricht dem ausdrücklich, und er hat einen Punkt. KI schreibt inzwischen einen erheblichen Teil neuer Software, und in der technischen Arbeit sind Agenten längst produktiv. In den kaufmännischen Domänen dagegen ist davon wenig zu sehen. Die meisten Fachleute außerhalb der IT nutzen KI weiterhin als Chatbot, vielleicht mit einem E-Mail-Sortierer oder einer Notizroutine. Von echten Agenten, die eigenständig Aufgabenketten abarbeiten, sind sie weit entfernt.

Die Ursache ist struktureller Natur. Agentic AI wurde zuerst im Terminal gebaut, also in der Kommandozeile – ein Ort, den viele Fachleute nicht einmal kennen. Wer technisch versiert ist, kann Agenten an seine Entwicklungsumgebung anschließen, Aufgaben gegen lokale Dateien laufen lassen und vorgefasste Anforderungen automatisiert abarbeiten. Für einen Daten- oder Softwaremenschen fühlt sich das intuitiv an. Für einen Marketingleiter, einen Finanzvorstand oder einen Betriebsleiter fühlt es sich wie eine geschlossene Tür an.

Interessanterweise könnte ausgerechnet das Marketing diese Tür zuerst öffnen. Das hat eine gewisse Logik, denn Marketing war immer schon der Einstiegspunkt für jede Datenwelle. Direkt-Mail-Segmentierung in den Siebzigerjahren, Loyalitätsprogramme in den Neunzigern, dann CRM, Webanalyse, der ganze Martech-Stack und schließlich die Customer Data Platform. Jede dieser Wellen hat mit Kundendaten gearbeitet und die Arbeitsweise der Marketingteams verändert. Dass es nun wieder so kommt, überrascht niemanden, der diese Geschichte kennt.

Was diesmal anders ist: Agenten wirken von beiden Seiten auf die Customer Journey ein. Kunden setzen sie ein, um Produkte zu recherchieren, zu vergleichen und zunehmend auch zu kaufen. Unternehmen setzen sie ein, um genau diese Kunden zu verstehen, zu segmentieren und anzusprechen. Eine Untersuchung von CI&T unter rund eintausend US-Konsumenten kommt zu dem Ergebnis, dass 74 Prozent bereits mindestens gelegentlich KI-Werkzeuge im Einkaufsprozess verwenden. Und es ist nicht nur die Chat-Oberfläche. Agenten browsen zunehmend über Schnittstellen, vergleichen Preise und tätigen Käufe über mehr Kanäle und sehr viel schneller, als ein Mensch klicken könnte. Die Werbeplätze von ChatGPT erreichten innerhalb von zweihundert Tagen eine Milliarde Dollar Jahresumsatz. Manche Marketingteams haben die Zeichen also erkannt.

Was eine Customer Data Platform leistet – und wo sie an Grenzen stößt

Wer verstehen will, was eine Agentic CDP ist, muss zuerst verstehen, was eine klassische Customer Data Platform tut. Sie ist eine Kundendatenplattform für Marketing und nimmt Daten aus all den Orten auf, an denen sie im Unternehmen verstreut liegen: Website, App, CRM, Transaktionssysteme, soziale Medien, Support-Tickets. Sie führt diese Quellen zu einem einheitlichen Profil pro Person zusammen. Damit können Marketingteams Zielgruppen bilden und direkt in Kampagnen schieben, ohne für jeden Schritt das Datenteam zu fragen.

Man kann sich das wie einen Kurier vorstellen, der Kopien zwischen Abteilungen trägt. Das Datenteam sitzt im Archiv und verwaltet die Originale. Der Kurier bringt eine Abschrift ins Marketing, damit dort gearbeitet werden kann. In vielen Unternehmen war das eine große Erleichterung, denn vorher musste für jede Zielgruppendefinition ein Ticket geschrieben werden. Die CDP lieferte einheitliche Profile, datengetriebene Segmentierung, Reverse ETL in Aktivierungswerkzeuge und eine bedienbare Oberfläche für Analyse und Auswertung. Das war ein großer Fortschritt, und viele Unternehmen arbeiten seitdem schneller.

Nur war die CDP nie die perfekte Lösung. Sie sitzt zwischen der Datenplattform, dem Martech-Stack und den Ausspielkanälen. Meist gehört sie dem Marketing und liegt damit außerhalb des kontrollierten Datenbestands, den ein Unternehmen offiziell verwaltet. Reverse ETL half, die Lücke zu überbrücken, aber es synchronisierte eine Kopie, keine lebenden Daten. Anders gesagt: Die CDP wurde für die Aktivierung gebaut, nicht für logisches Schlussfolgern und Datenklarheit. Deshalb fehlen ihr häufig die modellierten Strukturen, die über die Zeit Konsistenz sichern: definierte Körnung, abgestimmte Dimensionen, modellierte Beziehungen, Datenherkunft und vereinbarte Geschäftsdefinitionen.

Solange Menschen diese Kopien prüften, war das in Ordnung. Ein Marketingmitarbeiter, der eine Zielgruppe baute und eine Kampagne entwarf, bemerkte eine zerrissene Seite im Kurierpaket. Ein Agent bemerkt sie nicht. Genau an dieser Stelle kippt die bisherige Bauweise.

Der eigentliche Bruch: Middleware war nie für Agenten gedacht

Wenn ein Agent eine personalisierte Ansprache auslösen oder eine Kampagne messen soll, braucht er Kontext. Er muss wissen, wie ein Kunde definiert ist, welche Kennzahlen eine Kampagne ausmachen, was als Abwanderung zählt, wie die Kaufhäufigkeit aussieht und wie all das zusammenhängt. Steht ihm nur eine Abschrift zur Verfügung, die von der zentralen Datenhaltung abgekoppelt ist, bekommt er eine Darstellung des Datenbestands, nicht den Datenbestand selbst. Und damit trifft er jede Entscheidung auf Basis eines unscharfen Bildes.

Manche Organisationen verzichten ganz auf diese Zwischenschicht. Sie lassen KI aus ihrem Werkzeug – etwa Claude oder ChatGPT – direkt auf das Data Warehouse zugreifen. Das klingt praktisch, ist aber gefährlich. Es schafft Probleme für das Datenteam, das diese Daten verantwortet. Sobald Fachabteilungen über den Chatbot Daten ziehen, entsteht ein Sicherheits- und Verwaltungsproblem, das sich kaum kontrollieren lässt.

Der Autor beschreibt die Lage seiner Frau als Beispiel. Sie ist Vizepräsidentin für Marketing und nutzt KI intensiv, würde aber gerne auf das Snowflake-Warehouse ihres Unternehmens zugreifen. Sie hat keinen machbaren Weg dorthin. Es gibt eine technische Lücke zwischen Warehouse und KI-Werkzeug, keine Qualitätsprüfung dazwischen und keine architektonische Aufsicht über ihre Nutzung. Sie könnte eine MCP-Verbindung beantragen, aber damit bekäme eine nichttechnische Anwenderin eine direkte Leitung in produktive Kundendaten. Selbst wenn ein Warehouse kontrollierte MCP-Zugriffe unterstützt, kostet es das Datenteam erhebliche Ressourcen, Nutzer anzuleiten und zu überwachen. Kein Datenteam hat diese Kapazität.

Die Folge ist ein Muster, das dem Autor am meisten Sorgen macht. Nichttechnische Fachleute wissen nicht genau, was sie mit ihrem KI-Werkzeug tun, machen es aber trotzdem. Die Definitionen driften, nichts ist wiederholbar, alles veraltet. Oder das Marketing baut sich etwas Eigenes, weil die Zusammenarbeit mit dem Datenteam zu langsam ist. Dann gibt es eine zweite Version der Wahrheit. Das ist das eigentliche Risiko, und es ist genau das Problem, das eine CDP einmal lösen sollte. Nur wurde sie nicht mit eingebetteter KI im Kopf gebaut.

Was eine Agentic CDP anders macht

Die Agentic CDP setzt an dieser Stelle an. Drei Merkmale unterscheiden sie von ihren Vorgängern. Erstens ist sie vollständig in die kontrollierte Datenplattform eingebettet, arbeitet also auf dem Originalarchiv und nicht auf der Kurierkopie. Zweitens ist sie von Grund auf für Agenten gebaut, nicht für menschliches Klicken mit einer KI-Funktion als Anhang. Und drittens ist sie für Marketingfachleute gestaltet, nicht für Entwickler.

Diese Kombination erzeugt, was der Autor als goldenen Kontext bezeichnet. Damit ist gemeint, dass Kundendaten nicht nur vorhanden, sondern einheitlich definiert, verknüpft und mit klaren Geschäftsregeln hinterlegt sind. Ein Agent kann daraus zuverlässig ableiten, wer ein Kunde ist, was eine Abwanderung bedeutet und wie sich Kaufverhalten über die Zeit verhält. Er arbeitet nicht mit Vermutungen, sondern mit dem geprüften Bild des Unternehmens.

Databricks hat für diese Idee ein Produkt namens CustomerLake aufgelegt, und der Autor weist transparent darauf hin, dass der Beitrag in Zusammenarbeit mit dem Unternehmen entstanden ist. Der Hinweis ist nötig, denn kommerzielle Interessen und technische Analyse sollten getrennt bewertet werden. Unabhängig von der Marke gilt jedoch das Muster: Eine Customer Data Platform mit KI ist nicht dasselbe wie eine Agentic CDP. Wer Agenten im Marketing produktiv einsetzen will, braucht eine Datenbasis, die Modellierung, Herkunft und Governance verbindet. Ein nachträglich angeschraubtes KI-Merkmal an eine bestehende CDP erfüllt das nicht.

Von der Frage zur Kampagne – wie die Anwendungsfälle aufeinander aufbauen

Die praktischen Anwendungsfälle einer Agentic CDP bauen aufeinander auf. Am Anfang stehen Fragen an den kontrollierten Datenbestand: Wie viele Kunden haben im letzten Monat zum zweiten Mal gekauft? Welche Merkmale teilen sie? Wie haben sich diese Merkmale im Jahresverlauf verändert? Solche Fragen klingen harmlos, sind aber in vielen Unternehmen heute nicht in Minuten zu beantworten.

Auf dieser Basis entsteht Kampagnengestaltung. Ein Agent kann Segmentvorschläge machen, Botschaften skizzieren, Kanäle gewichten und die zu erwartende Wirkung überschlagen. Das ist mehr als Textgenerierung, denn der Agent kennt die Daten, auf die er sich bezieht. Er kann seine Vorschläge belegen, nicht nur formulieren.

Daraus folgt der nächste Schritt, die nächstbeste Aktion. Ein Agent, der weiß, welcher Kunde wann zuletzt gekauft hat und welche Signale auf abnehmendes Interesse hindeuten, kann Maßnahmen vorschlagen, bevor die Abwanderung eintritt. Und schließlich geht es um kontinuierliches Engagement, also den laufenden Austausch mit Kunden über viele Berührungspunkte hinweg. Hier wird Agentic AI im Marketing wirklich interessant, denn hier zahlt sich der Kontext aus, der über Monate aufgebaut wurde.

Eines betont der Autor ausdrücklich. Wer die Plattform kauft, steigt damit nicht automatisch in der Reifegradleiter auf. Er stellt sich nur eine Leiter hin. Bestiegen werden muss sie trotzdem, und das Fundament muss dafür vorhanden sein. Ohne definierte Daten, klare Verantwortlichkeiten und gepflegte Definitionen hilft auch das beste Produkt nicht weiter.

Was das für Marketingteams konkret bedeutet

Man kann diese Entwicklung als die nächste Stufe einer langen Reihe von Datenwellen verstehen, die das Marketing zuerst erfasst haben. Erst kamen die Statistiker, dann die Analysten, dann die Plattformen, nun die Agenten. Was sich diesmal unterscheidet, ist die Doppelwirkung: Kunden nutzen Agenten gegen das Unternehmen, das Unternehmen setzt Agenten ein, um diese Kunden zu verstehen. Wer nur eine Seite dieser Bewegung im Blick hat, wird die andere früher oder später spüren, ob im Wettbewerb oder in den eigenen Zahlen.

Die Agentic CDP ist kein fertiger Zustand, sondern eine Richtung. Sie soll Kundendaten dort zeigen, wo Entscheidungen getroffen werden, und dabei jene Ordnung bewahren, die Agenten brauchen. Ob sich das Konzept flächendeckend durchsetzt, hängt davon ab, ob Unternehmen ihre Datenplattform tatsächlich aufräumen, ob sie Marketing ernsthaft Zugang geben und ob sie bereit sind, Verantwortung zu verteilen statt sie nur zu zentralisieren. An der Technik scheitert es nicht. Die Mühe liegt an anderer Stelle.

Für Marketingteams bedeutet das zunächst, die eigenen Hausaufgaben zu prüfen. Sind die Kundendefinitionen im Unternehmen einheitlich? Sind die Kennzahlen abgestimmt? Ist bekannt, was eine Abwanderung ist und wie sie gemessen wird? Wer diese Fragen heute nicht beantworten kann, wird morgen auch keinen Agenten sinnvoll steuern können. Wer sie beantwortet, kann in einer Welt, in der Kaufentscheidungen immer schneller ablaufen, mithalten – und mehr.

Quelle: thedataecosystem.substack.com

Automatisierte Zahlungen im Browser gehören zu den heikelsten Schritten einer Agenten-Automatisierung. Meist wird angenommen, ein Agent müsse die Zahlungsoberfläche nachbauen: Felder auslesen, Schaltflächen erkennen, Klicks in der richtigen Reihenfolge auslösen. Die Stripe-Dokumentation zu WebMCP beschreibt einen anderen Weg. Die Zahlungsseite selbst stellt strukturierte Werkzeuge bereit, die der Agent aufrufen kann, statt die Oberfläche Feld für Feld nachzustellen.

Wer heute Stripe Checkout oder eine gehostete Rechnungsseite automatisiert, kennt die Bruchstellen: ein geändertes Layout, ein zusätzlich eingeblendetes Feld, eine andere Fehlermeldung — und der Ablauf steht. Dieser Text erklärt, wie man WebMCP für Stripe-Zahlungen im Browser nutzt, welche Werkzeuge zur Verfügung stehen und was noch nicht fertig ist.

WebMCP verwandelt die Zahlungsseite in einen Werkzeugkasten

Bisher stand ein Agent vor einer fremden Werkbank und musste erraten, welches Gerät wofür gedacht ist. Er beobachtete, was andere taten, und ahmte die Bewegungen nach. Bei WebMCP bekommt er beschriftete Werkzeuge, die er direkt benutzt. Ein Browser-Agent arbeitet dadurch nicht mehr über Seiten-Scraping und simulierte Klicks mit der Stripe-Zahlungsoberfläche, sondern über Werkzeugaufrufe, die in der Webseite registriert sind.

Der Unterschied liegt in der Verlässlichkeit. Ein Klick-Simulator ist nur so stabil wie das Markup, auf das er zielt, und auf dieses Markup kann man sich über Versionen hinweg nicht verlassen. Ein Werkzeugaufruf richtet sich dagegen an eine definierte Schnittstelle mit definierten Eingaben. Das macht den Zahlungsfluss robuster, und es sind deutlich weniger Zwischenschritte nötig, um herauszufinden, was gerade zu tun ist.

Welche Stripe-Zahlungsoberflächen den Werkzeugkasten ausliefern

Stripe liefert die Werkzeuge nicht überall im gleichen Umfang aus. Unterstützt werden nach derzeitigem Stand mehrere Varianten der Zahlungsoberfläche: die vollständige Checkout-Seite, das eingebettete Checkout-Formular, Stripe Elements als Bausteine in einer eigenen Seite sowie die gehostete Rechnungsseite. Welche Werkzeuge tatsächlich verfügbar sind, hängt zusätzlich vom Zustand der Sitzung ab.

Der Werkzeugkasten verändert sich also mit dem Zahlungsfluss. Welche Zahlungsmethoden angeboten werden, gehört zum Sitzungszustand, und auch welches Formular gerade aktiv ist, spielt eine Rolle. Eine Liste von Werkzeugen, die man einmal aus der Dokumentation abgeschrieben hat, beschreibt also nicht zwingend das, was auf der Seite vor einem liegt.

Diese Werkzeuge stehen für den Zahlungsfluss bereit

Stripe stellt Werkzeuge bereit, mit denen ein Agent den Zahlungsvorgang vollständig begleiten kann. Dazu gehört zunächst das Auslesen des Kontexts: der offene Betrag, die verfügbaren Zahlungsmethoden, je nach Oberfläche auch Angaben aus einer Rechnung. Ein zweites Werkzeug erlaubt die Auswahl einer Zahlungsmethode, ein drittes das Befüllen von Formularfeldern.

Bei Oberflächen, deren Absendeaktion Stripe selbst kontrolliert, gibt es zusätzlich ein Werkzeug, um die Zahlung in Gang zu setzen. Die Verantwortung bleibt dabei geteilt: Der Agent sammelt und füllt, die Abwicklung liegt weiterhin bei Stripe. Wie viele Werkzeuge eine konkrete Zahlungsoberfläche anbietet, lässt sich pauschal nicht sagen.

Die Dokumentation empfiehlt deshalb, das Werkzeugset von der Zahlungsseite selbst abzuholen. Die aktuelle Definition eines Werkzeugs sagt, was es tut und welche Eingaben es erwartet. Wer die WebMCP-Tools für den Stripe-Zahlungsfluss sucht, findet sie nicht in einer statischen Übersicht, sondern im laufenden Betrieb.

Warum fest verdrahtete Tool-Namen im Zahlungsfluss scheitern

Werkzeugnamen, Schemas und Annahmen über die Verfügbarkeit gehören nicht in den Code. Der Grund ist praktisch: Das Schema eines Werkzeugs kann sich mitten im Zahlungsfluss ändern. Wählt man etwa eine bestimmte Zahlungsmethode aus, ändert sich die Menge der Felder, die der Agent zuvor einsammeln muss.

Ein Agent mit fest eingebauten Feldlisten kennt diese neuen Felder nicht und läuft ins Leere. Ein Agent, der nach jedem relevanten Schritt die aktuelle Definition liest, weiß, was jetzt verlangt wird. Der Werkzeugkasten wird während der Arbeit umgesteckt; wer ihn nur aus dem Gedächtnis kennt, greift irgendwann daneben.

Der Ablauf in drei Schritten und der Rückfall auf klassische Automatisierung

Für den praktischen Aufbau ergibt sich eine klare Reihenfolge. Zuerst entdeckt der Agent die verfügbaren Werkzeuge auf der Seite. Danach liest er die aktuelle Definition des Werkzeugs, das er aufrufen will, um zu entscheiden, welche Eingaben er liefern muss. Nach jeder Aktion, die das Zahlungsformular oder die verfügbaren Zahlungsmethoden verändern kann, entdeckt er das Werkzeugset erneut.

Der dritte Schritt wird am ehesten vergessen, weil er sich wie doppelte Arbeit anfühlt. Er ist aber die Voraussetzung dafür, dass sich Stripe Checkout mit einem Browser-Agenten zuverlässig automatisieren lässt, gerade bei Zahlungsmethoden, die zusätzliche Angaben verlangen. Ein Agent, der nur einmal am Anfang nachsieht und danach blind weiterarbeitet, verliert genau dort seine Verlässlichkeit.

Was passiert, wenn das benötigte Werkzeug nicht vorhanden ist? Dann greift der dokumentierte Rückfall auf die klassische Browser-Automatisierung. Die Fähigkeit ist also als zusätzlicher, bevorzugter Weg gedacht, nicht als vollständiger Ersatz für alles, was vorher funktioniert hat. Wer einen Browser-Agenten für Stripe-Zahlungen integriert, sollte beide Wege vorhalten.

Was der experimentelle Status für den produktiven Einsatz bedeutet

WebMCP ist eine experimentelle Browser-Fähigkeit, die auf einem vorgeschlagenen Webstandard beruht. Die Browser-Unterstützung kann sich ändern, die Verfügbarkeit einzelner Werkzeuge ebenfalls, und die Schemas sind keine eingefrorene Schnittstelle. Wer darauf aufbaut, baut auf etwas Bewegliches.

Für die Praxis heißt das: Der Ansatz gehört in die Kategorie „ausprobieren und beobachten“, nicht in die Kategorie „darauf verlassen“. Sinnvoll ist eine Architektur, die den Werkzeugaufruf bevorzugt, aber den Rückfall auf Standard-Automatisierung nicht wegkürzt. Wer beides vorhält, kann die strukturierten Werkzeuge nutzen, ohne sich von ihrem Reifegrad abhängig zu machen.

Der Unterschied liegt weniger in einer neuen Funktion als in einer verschobenen Zuständigkeit: Die Zahlungsoberfläche beschreibt selbst, was mit ihr möglich ist, statt dass der Agent es aus dem Aussehen der Seite ableitet. Wenn sich die Stripe-Zahlungsoberfläche mit WebMCP steuern lässt, heißt das vor allem, dass sich das Formular erklärt und der Agent nicht mehr einen Menschen mit Maus und Geduld simulieren muss. Das fällt auf, sobald sich das Layout ändert und der Agent trotzdem weiterläuft.

Quelle: docs.stripe.com