AWS ADOP: KI-Agenten in der Entwicklung, deterministischer Code in der Produktion

Jeder Head of Data Engineering, der auf ein Plattformbudget für 2027 schaut, stellt sich dieselbe unbequeme Frage: Wie viel von der agentischen KI-Welt gehört tatsächlich in den Laufzeitpfad – und wie viel bleibt in der IDE? AWS hat gerade eine klare Antwort veröffentlicht, und es ist genau die Antwort, bei der ein CFO nachts ruhig schlafen kann. Die Architekturentscheidung hinter ADOP lohnt sich selbst dann zu studieren, wenn man sie nie einsetzt – denn sie definiert neu, was ein „agentisches Datenplattform" überhaupt bedeuten darf.

Das Problem

Eine neue regulierte Datenquelle aufzusetzen ist bei den meisten Series-B- und Enterprise-Unternehmen noch immer eine wochenlange Übung. Jemand schreibt den PySpark. Jemand anderes schreibt die Great Expectations-Checks. Eine dritte Person aktualisiert den Semantic Layer. Die Rechtsabteilung prüft die Lineage-Dokumentation zwei Sprints später. Bis der Gold-Table bereitsteht, hat sich die Geschäftsfrage, die den Auftrag ausgelöst hat, längst weiterentwickelt.

Die naheliegende Lösung – und die, die jeder Anbieter bis 2025 angepriesen hat – war, einen LLM-Agenten in den Laufzeitpfad zu integrieren. Den Agenten die Quelle inspizieren lassen, die Transformation generieren, ausführen, aus dem Fehler lernen, erneut versuchen. Das verkauft sich gut in einer Demo. Es besteht drei Tests in einer regulierten Umgebung nicht: Kostenprognostizierbarkeit, Audit-Reproduzierbarkeit und die unangenehme Realität, dass ein Modell, das sich am Dienstag anders verhält als am Montag, kein Bankprüfer hören möchte.

Die Agentic Data Operations Platform, wie Amazon Web Services (AWS) berichtete, ist eine Referenzarchitektur auf Amazon Bedrock, die darauf ausgelegt ist, diesen Zeitraum von Wochen auf Stunden zu verkürzen. Das Interessante ist nicht der Komprimierungsanspruch. Den macht jeder agentische Ansatz in irgendeiner Form. Das Interessante ist, wo die Agenten leben. Im Standardmuster von ADOP laufen Agenten ausschließlich in Entwicklungsumgebungen. Sie generieren deterministischen PySpark, SQL, Airflow DAGs, IAM-Policies und Cedar-Autorisierungsregeln. CI/CD befördert diese Artefakte in die Produktion. Die Produktion führt sie aus, ohne ein Modell aufzurufen.

Das ist eine Designphilosophie, kein Feature. Sie besagt, dass das Modell ein Build-Time-Beschleuniger ist, keine Laufzeitabhängigkeit. Und sie entspricht fast genau dem, wie reife Engineering-Organisationen bereits über Code-Generierung denken: Ein Senior Engineer nutzt Copilot, um eine Funktion zu entwerfen, überprüft sie, liefert die geprüfte Version aus – und das Modell ist dem Produktions-Request-Pfad nirgendwo nahe.

Die verfügbaren Optionen

Ein Datenplattform-Lead, der agentisches Tooling bewertet, hat derzeit ungefähr vier verschiedene Muster zur Auswahl – und sie sind nicht austauschbar.

Muster eins: Modell im Loop zur Laufzeit. Agenten beobachten Produktionsdaten, entscheiden Transformationen on the fly und führen sie aus. Das ist das Muster, das die meisten agentischen Startups verkaufen. Es maximiert Flexibilität – und maximiert Kostenvarianz. Jeder Pipeline-Lauf ist eine Token-Rechnung. Jede Modellversionsänderung ist ein Regressionsrisiko. Für ein Ad-Tech-Unternehmen, das sich schnell mit unregulierten Daten bewegt, vertretbar. Für jeden, der PHI- oder KYC-Daten verarbeitet, ein Compliance-Albtraum, der auf seinen ersten Audit wartet.

Muster zwei: Agenten in der Entwicklung, deterministische Artefakte in der Produktion. Das ist ADOPs Standard. Sub-Agenten, die über das Dynamic Workflow-Feature von Claude Code gestartet werden, übernehmen Metadaten-Generierung, Ontologie-Ableitung, Qualitätsprüfungen, ETL und Orchestrierung über Airflow oder AWS Step Functions. Die Ausgabe wird überprüft, befördert und läuft kalt. Die Token-Rechnung ist durch die Häufigkeit der Einbindung neuer Quellen begrenzt, nicht durch das Traffic-Volumen. Prüfer erhalten statischen Code zur Überprüfung, keine Modell-Traces.

Muster drei: Verwaltete Laufzeit-Agenten-Plattformen. Amazon Bedrock AgentCore ist als Scale-Out-Laufzeit für Agenten positioniert, und ADOP kann bei Bedarf darauf hochgestuft werden. Das ist das „Wir betreiben Ihre Agenten im großen Maßstab"-Angebot, das in einem gewissen Spannungsverhältnis zu Muster zwei steht. AWS ist hier ehrlich: Beide Muster sind valide, sie optimieren für unterschiedliche Dinge. AgentCore optimiert für Flexibilität. ADOP optimiert für Kostenprognostizierbarkeit und Audit-Positionierung.

Muster vier: Eigenentwicklung mit dbt und Orchestrierung. Der Status quo. Ein gut geführtes dbt-Projekt mit ordentlichen Tests, einem Semantic Layer und diszipliniertem Code Review liefert bereits den größten Teil der Konsistenz, die ADOP verspricht. Der Unterschied liegt in der Onboarding-Geschwindigkeit und der Akzeptanz, dass Senior Data Engineers einen großen Teil ihrer Zeit mit Klempnerarbeiten statt mit Modellierung verbringen.

Die Build-vs-Buy-Frage ist hier ungewöhnlich, weil ADOP kein Produkt ist, das man kauft. Es ist eine Referenzarchitektur, die man von GitHub klont und anpasst. Die eigentliche Anbieterbindung liegt bei Amazon Bedrock und Claude Code als Coding-Oberfläche, plus dem nachgelagerten Compute (Spark auf EMR, Glue oder etwas wie Databricks, falls man dort bereits ist). Der Lock-in verschiebt sich vom Agenten-Runtime zum Modellanbieter und dem CLI-Tooling. Das ist in achtzehn Monaten eine wesentlich andere Verhandlungsposition.

Was Data-Teams konkret tun sollten

Meine Einschätzung: Wer regulierte Pipelines betreibt, sollte das ADOP-Muster als korrekten Standard verwenden – selbst wenn man die spezifische AWS-Implementierung nie anfasst. Die Architekturidee übernehmen. Agenten in der Entwicklung einsetzen, deterministischen Code ausliefern, die Produktion langweilig halten. Allein die Token-Ökonomie rechtfertigt das. Eine Pipeline, die bei jedem Lauf ein Modell aufruft, hat Kosten, die mit dem Traffic skalieren. Eine Pipeline, die einmal generiert und einmal überprüft wird, hat Kosten, die mit dem Onboarding-Volumen skalieren – das sind für die meisten Unternehmen ungefähr zwei Größenordnungen weniger.

Die Auswirkungen auf die Teamzusammensetzung verdienen Beachtung. Dieses Muster braucht weniger Prompt Engineers und mehr Plattform-Engineers, die CI/CD, Policy-as-Code und die Überprüfung von generiertem PySpark auf Korrektheit verstehen. Der Einstellungsmarkt für „AI Engineer" ist seit achtzehn Monaten überhitzt. Der Markt für einen starken Plattform-Engineer, der Cedar-Policies lesen und Airflow DAGs schreiben kann, ist eng, aber nicht irrational. Dieses Muster begünstigt das Team, das man tatsächlich einstellen kann.

Der CFO oder Head of Platform, der das Board-Deck dieser Woche liest, sollte eine konkrete Frage stellen: Welcher Anteil unserer prognostizierten KI-Infrastruktur-Ausgaben für 2026 entfällt auf Runtime-Inferenz in Datenpipelines – und welcher auf Build-Time-Code-Generierung? Wenn die Antwort stark in Richtung Runtime tendiert, muss das jemand gegenüber dem ADOP-Muster mit einem konkreten Grund verteidigen, nicht mit einem Bauchgefühl. „Das Modell muss im Loop sein" ist kein Grund. „Wir haben unstrukturierte Eingaben, deren Form sich täglich ändert, und statischer Code kann damit nicht umgehen" ist ein Grund.

Für Teams, die bereits auf Snowflake oder Databricks sind, erzwingt ADOP keine Migration. Es unterstützt jeden Dienst mit einem CLI- oder Model Context Protocol-Interface – was die ehrliche Art zu sagen ist, dass der Architekturvertrag mitreist. Die generierten Artefakte können auf das Warehouse gerichtet werden, das man bereits betreibt.

Fallstricke und Sonderfälle

Einige Punkte verdienen Aufmerksamkeit. Die Decision Engine, beschrieben als KI-kodierte Version eines Enterprise Architects, ist nur so gut wie die Standards, die man ihr mitgibt. Organisationen, die ihre Datenarchitekturprinzipien nie schriftlich festgehalten haben, werden feststellen, dass das Kodifizieren derselben die eigentliche Arbeit ist – nicht die Agenten-Orchestrierung. Das ist eine Sechs-Monats-Übung, die als Ein-Wochen-Setup verkleidet ist.

Jede Agenten-Entscheidung wird über etwas namens AgentTrace nachverfolgt, das nach CloudWatch oder in einen OpenTelemetry-Sink publiziert. Gut. Aber Traces eines Build-Time-Prozesses sind nicht dasselbe wie Produktions-Observability, und Teams sollten beides nicht verwechseln. Echtes Pipeline-Monitoring auf den deterministischen Artefakten ist weiterhin notwendig, sobald diese live sind.

Die Compliance-Geschichte hat Grenzen. ADOP wendet beim Onboarding einen Regulierungs-Prompt pro Governance-Framework an, und AWS stellt explizit klar, dass Kunden selbst dafür verantwortlich bleiben, ihre eigene Compliance zu bestimmen. Diese Formulierung ist wichtig. Eine generierte Cedar-Policy ist ein Ausgangspunkt für die Überprüfung durch den Rechtsbeistand, kein Ersatz dafür. Wer keine Compliance-Funktion hat, die Policy-as-Code prüfen kann, dem hilft ein Agent, der davon schneller mehr generiert, nicht weiter.

Schließlich ist die Claude Code-Abhängigkeit real. Kiro, Cursor und Codex werden als Coding-Oberflächen unterstützt, aber das Dynamic Workflow Sub-Agent-Muster ist ein Claude Code-Feature. Wenn die Organisation auf einen anderen Coding-Assistenten standardisiert hat, ist Anpassungsaufwand zu erwarten.

Wichtigste Erkenntnisse

• ADOPs Kernerkenntnis ist architektonischer Natur: Agenten in der Entwicklung, deterministische Artefakte in der Produktion. Das begrenzt die Token-Kosten auf das Onboarding-Volumen, nicht auf das Traffic-Volumen.
• Das Muster begünstigt Teams, die Plattform-Engineers einstellen können, gegenüber Teams, die auf rares Prompt-Engineering-Talent setzen.
• Für regulierte Workloads im Gesundheitswesen und in der Finanzbranche ist statisch generierter Code dramatisch einfacher zu prüfen als ein Modell, das sich nächste Woche möglicherweise anders verhält.
• Der Lock-in verschiebt sich vom Agenten-Runtime zum Modellanbieter und CLI-Tooling. Das sollte bei der Verlängerung von Bedrock- oder Claude-Verpflichtungen entsprechend verhandelt werden.
• Die eigentliche Arbeit besteht darin, Architekturstandards zu kodifizieren, damit die Decision Engine etwas durchzusetzen hat. Teams ohne schriftliche Standards werden das auf die harte Tour herausfinden.

Teams, die in den nächsten neunzig Tagen agentische Datenplattformen bewerten, sollten sich jetzt eine schärfere Frage stellen: Platziert der Anbieter das Modell in den Request-Pfad – und wenn ja, was rechtfertigt dieses Kostenprofil konkret gegenüber einer reinen Build-Time-Alternative? Wenn die Antwort eine Demo ist statt eines nachvollziehbaren Workload-Merkmals, gewinnt das ADOP-Muster allein auf Basis der Unit Economics, noch bevor die Compliance-Diskussion überhaupt beginnt.