Adobes Data Engineering Agent: Onboarding von Wochen auf Tage reduziert

Wer schon einmal einen Adobe Experience Platform-Rollout begleitet hat, kennt die ersten sechs Wochen: Jemand pflegt Mapping-Tabellen, ein anderer jagt einen Marketo-Export hinterher, und ein Data Engineer baut nachts um 23 Uhr Schemas neu auf, weil Loyalty-IDs als Strings ankamen. Genau dieses Szenario will Adobe nun automatisieren. Am 20. April kündigte Adobe den Data Engineering Agent an – einen neuen agentenbasierten Workflow auf Basis des Experience Platform Agent Orchestrator, der „bald" allgemein verfügbar sein wird.

Was passiert ist

Wie Adobe for Business in einem Beitrag von Huong Vu berichtete, soll der Data Engineering Agent den Daten-Lebenszyklus für Engineers, Architekten und Datenkonsumenten wie Marketing-Operations-Spezialisten vereinfachen. Die Botschaft ist klar: Traditionelles Daten-Onboarding in die Experience Platform dauert oft Wochen, manchmal Monate. Adobe verspricht, diesen Zeitraum auf Tage zu reduzieren.

Der Agent ist noch nicht verfügbar. Adobe beschreibt ihn als demnächst erscheinend, betrieben durch den Experience Platform Agent Orchestrator und gesteuert über die KI-Assistenten-Konversationsoberfläche. Nutzer interagieren über natürlichsprachliche Prompts innerhalb eines Human-in-the-Loop-Workflows – der Agent schlägt vor, der Mensch genehmigt.

Der Umfang ist weitreichend. Beim Onboarding zieht der Agent Daten aus Quellen wie Amazon S3, Data Landing Zone und Marketo, validiert die Datenqualität, genehmigt KI-empfohlene Felder für die Schema-Erstellung, konfiguriert semantische Anreicherung und erstellt Dataflows über den AI Assistant zur Aufnahme in die Experience Platform. Auf SQL-Seite generiert er optimierte, schema-bewusste SQL-Statements mit Vorschauen vor der Ausführung, überwacht und behebt SQL-Jobs ohne Wechsel in die Queries-Benutzeroberfläche, validiert die Datensatzbereitschaft vor der Ausführung und führt Nutzer durch automatische Fehlerbehebung.

Die nachgelagerten Nutznießer sind die üblichen Adobe-Verdächtigen: Real-Time Customer Data Platform, Customer Journey Analytics und Journey Optimizer. Saubere Daten hinein, schnellere Aktivierung heraus. Adobe erklärt außerdem, dass der Agent operative Einblicke liefert, die Lineage, Abhängigkeiten und Beziehungen visualisieren, sowie kontextbezogenes Produktwissen aus Experience League, Community-Foren und öffentlicher GitHub-Dokumentation.

Meine Einschätzung: Adobe holt damit zur agentenbasierten Data-Engineering-Story auf, die Snowflake und Databricks seit einem Jahr erzählen – aber gezielt auf die Marketing-Datenebene ausgerichtet, auf der Adobe die Kundenbeziehung noch dominiert.

Technische Architektur

Zieht man das Marketing-Vokabular ab, ist die Architektur ein klassisches Orchestrator-plus-Tool-Use-Muster. Der Agent Orchestrator ist der Planer. Der AI Assistant ist die Konversationsoberfläche. Der Agent selbst greift auf die bestehenden Primitiven der Experience Platform zurück: Source Connectors, Schema Registry (Experience Data Model), Dataflows und den Query Service. Die Neuerung besteht darin, dass ein Sprachmodell die Artefakte erstellt, die ein Data Engineer normalerweise manuell anfertigt.

Das Onboarding funktioniert ungefähr so: Der Nutzer verweist den Agent auf eine Datei oder Quelle wie S3, Data Landing Zone oder Marketo. Der Agent untersucht die Nutzdaten, schlägt Feld-Mappings auf XDM vor, kennzeichnet Qualitätsprobleme, empfiehlt semantische Anreicherung und erstellt den Dataflow. Ein Mensch genehmigt vor der Veröffentlichung. Dieses Genehmigungsgateway trägt viel Last. Schema-Drift in einem Kundenprofil-Datensatz kann ein CDP monatelang still vergiften, bevor jemandem auffällt, dass ein Segment zu niedrig zählt. Die Veröffentlichung hinter einer Prüfung zu sichern, ist die richtige Entscheidung.

Für SQL ist das Muster ähnlich. Der Agent liest das Ziel-Schema, generiert ein schema-bewusstes Statement, zeigt eine Vorschau und überwacht die Ausführung. Wenn ein Job fehlschlägt oder ein Datensatz nicht bereit ist, zeigt er das Problem an und schlägt eine Lösung vor. Das ist eine wesentliche Verbesserung gegenüber dem aktuellen Workflow, bei dem ein Analyst eine Abfrage schreibt, sie startet und erst bemerkt, dass etwas schiefgelaufen ist, wenn eine Journey Optimizer-Kampagne falsch ausgeführt wird.

Der naheliegendste Vergleichspunkt ist der übrige Analytics-Stack. Teams, die dbt einsetzen, haben Tests und Lineage bereits als erstklassige Konzepte, dokumentiert in dbt's Dokumentation. Snowflake und Databricks liefern beide agentenstil-SQL-Copiloten. Adobes Wette ist, dass Experience Platform-Kunden ihre Datenvorbereitung lieber innerhalb des Adobe-Perimeters behalten, anstatt eine externe Transformationsschicht anzubinden. Diese Wette ist vernünftig für Mid-Market-Marketing-Teams. Für Unternehmen, die bereits auf ein Lakehouse standardisiert haben, ist es schwerer zu verkaufen.

Die unbequeme Lesart: Der Agent hilft nur, wenn die Daten bereits in Adobe-freundlichen Formaten ankommen. Garbage in, LLM-unterstütztes Garbage out.

Wer betroffen ist

Drei Gruppen müssen aufhorchen. Erstens: Adobe-Implementierungspartner. Ein erheblicher Teil ihrer Umsätze entsteht durch die Abrechnung wochenlanger Data-Engineering-Arbeit für das Onboarding von E-Commerce-Transaktionen, Loyalty-Aktivitäten und Kundenprofilen – genau die Datensätze, die Adobe als Beispiele nennt. Wenn Wochen auf Tage schrumpfen, schrumpfen auch die Rechnungen. Partner, die nach Aufwand berechnen, werden das spüren. Partner, die nach Ergebnissen berechnen, kommen gut davon.

Zweitens: interne Data-Engineering-Teams bei Adobe-Kunden. Kein Job verschwindet, aber die Arbeit verlagert sich. Weniger Zeit für das Schreiben von Mapping-Logik, mehr Zeit für das Prüfen von Agent-Output, das Steuern des Modellverhaltens und das Bearbeiten von Sonderfällen, bei denen der Agent scheitert. Teams, mit denen ich bei der Einführung von SQL-Copiloten zusammengearbeitet habe, stellten fest, dass die Review-Last real ist: Generierten SQL sorgfältig genug zu lesen, um ihm zu vertrauen, dauert fast so lange wie das Schreiben – zumindest im ersten Quartal. Dafür sollte man Kapazitäten einplanen.

Drittens: Marketing-Operations-Spezialisten. Adobe macht explizit, dass Datenkonsumenten einschließlich Marketing Ops zu den Zielnutzern gehören. Das ist eine bedeutende Erweiterung des Personenkreises, der Schemas und Dataflows berührt. Es ist auch eine Governance-Tretmine. Wenn ein Marketing-Ops-Analyst über ein Chat-Interface einen neuen Marketo-Export einlesen kann, wird die Definition „genehmigter Datenquellen" unschärfer. Rechnen Sie damit, dass die nächsten 90 Tage jedes Adobe-Rollouts eine Diskussion darüber umfassen, wer Agent-Zugang erhält und wie die Genehmigungsrichtlinie aussieht.

Produktionsvorfälle, die ich in iGaming und Fintech beobachtet habe, lassen sich fast immer auf eines von zwei Dingen zurückführen: eine Schema-Änderung, die niemand kommuniziert hat, oder ein SQL-Job, der stillschweigend die falsche Form zurückgegeben hat. Ein Agent, der SQL vor der Ausführung voranzeigt und die Datensatzbereitschaft validiert, adressiert beides – sofern Teams die Vorschauen tatsächlich lesen. Das ist ein großes Wenn, wenn sich die Oberfläche konversationell und schnell anfühlt.

Handlungsempfehlungen für Datenteams

Wer Analytics oder Kundendaten-Infrastruktur auf Adobe betreibt, sollte in der ersten Woche folgendes prüfen.

Erfassen Sie den aktuellen Onboarding-Rückstand. Listen Sie jeden Datensatz auf, der in der Pipeline feststeckt, das Quellsystem und die verbrauchten Engineer-Tage. Wenn der Agent verfügbar ist, möchten Sie einen messbaren Vorher-Nachher-Vergleich haben. „Wochen zu Tage" ist Adobes Versprechen. Ihr eigenes sollte spezifisch für Ihre Datensätze sein.

Legen Sie die Human-in-the-Loop-Richtlinie fest, bevor Sie den Agent aktivieren. Entscheiden Sie, wer Schemas, Dataflows und SQL-Ausführungen gegen Produktionsdatensätze genehmigt. Schreiben Sie es auf. Agentenbasierte Tools scheitern nur dann sicher, wenn die Genehmigungskette explizit ist.

Instrumentieren Sie Lineage unabhängig. Adobe sagt, der Agent wird Lineage, Abhängigkeiten und Beziehungen visualisieren. Gut. Verlassen Sie sich nicht allein darauf. Führen Sie ein externes Protokoll darüber, welche Datensätze welche Real-Time CDP-Audiences und Journey Optimizer-Kampagnen speisen. Wenn der Agent etwas falsch konfiguriert, möchten Sie Ihre eigene Karte haben.

Stresstest für SQL-Vorschauen. Bevor Sie agentengenerierten Abfragen in der Produktion vertrauen, führen Sie einen Sprint durch, in dem Engineers jede Vorschau bewusst prüfen. Katalogisieren Sie die Fehlermuster. Schema-bewusst bedeutet nicht semantisch-bewusst, und der Unterschied zeigt sich im Umsatz-Reporting.

Verhandeln Sie Partner-Verträge neu, wenn Sie nach Engineer-Wochen zahlen. Wenn das Onboarding tatsächlich kürzer wird, sind Ihre Statement-of-Work-Annahmen überholt. Fazit: Behandeln Sie den Agent als Produktivitätsmultiplikator für erfahrene Engineers, nicht als Ersatz für sie – dann wird Ihr Rollout auf die bestmögliche Art langweilig.

Wichtigste Erkenntnisse

• Der Adobe Data Engineering Agent, betrieben durch den Experience Platform Agent Orchestrator, wird bald Onboarding, SQL-Vorbereitung, Datenerfassung und Fehlerbehebung innerhalb der Experience Platform automatisieren.
• Adobe verspricht, dass die Onboarding-Zeit für Datensätze wie E-Commerce-Transaktionen, Loyalty-Aktivitäten und Kundenprofile von Wochen (manchmal Monaten) auf Tage sinkt.
• Unterstützte Quellen beim Launch umfassen Amazon S3, Data Landing Zone und Marketo, mit nachgelagerter Lieferung an Real-Time CDP, Customer Journey Analytics und Journey Optimizer.
• Der Agent verwendet einen Human-in-the-Loop-Workflow mit natürlichsprachlichen Prompts, SQL-Vorschauen vor der Ausführung und automatischer Fehlerbehebungsführung.
• Implementierungspartner, die nach Aufwand abrechnen, Marketing-Ops-Governance-Richtlinien und Vertragsannahmen müssen im nächsten Quartal überprüft werden.