DataDiese Woche in DataSoftware & SaaS

Wenn Agents die neuen Hauptkonsumenten Ihrer Daten sind: Ist Ihre Infrastruktur für die falsche Zielgruppe gebaut?

Auf dem dbt Summit 2026 haben Fivetran und dbt Labs eine Reihe neuer Produkte vorgestellt, die Unternehmensdaten für AI-Agents statt für menschliche Analysten nutzbar machen sollen. CDOs müssen den tatsächlichen architektonischen Wandel vom Vendor-Positioning trennen.

Die Ankündigungen vom dbt Summit 2026 haben diese Woche eine gemeinsame Prämisse: Der primäre Konsument von Unternehmensdaten verändert sich, und eine Infrastruktur, die für menschliche Analysten gebaut wurde, reicht für AI-Agents immer weniger aus, die in Maschinengeschwindigkeit abfragen, schlussfolgern und handeln. Ob diese Prämisse zur dauerhaften architektonischen Realität wird oder ein Marketing-Frame bleibt, hängt von Entscheidungen ab, die CDOs gerade jetzt treffen: zu Metadaten, zu Transformationslogik und dazu, was „ready“ eigentlich heißt.

Was ist auf dem dbt Summit 2026 wirklich GA gegangen?

Laut dbt Labs (einem Anbieter mit direktem kommerziellen Interesse an der Verbreitung dieser Tools) haben dbt Core v2 und dbt State auf dem dbt Summit 2026 beide General Availability erreicht. dbt State ist für die meisten Teams heute das praktisch relevantere der beiden. Es löst ein simples und teures Problem: Bei Standard-dbt-Runs wird jedes Modell von Grund auf neu gebaut, selbst wenn sich die zugrunde liegenden Daten nicht geändert haben. dbt State verfolgt, was sich zwischen zwei Runs geändert hat, und baut nur neu, was neu gebaut werden muss.

dbt Labs gibt an, dass Fanatics, das Unternehmen für Sportartikel, mit dbt State die Warehouse-Compute-Kosten deutlich gesenkt hat, indem unnötige Rebuilds wegfielen. Das Unternehmen erzählt das als Story über Compute-Kosten und Entwicklungsgeschwindigkeit. Diese Case Study sollte man als Richtungssignal behandeln, nicht als Benchmark: Vom Anbieter veröffentlichte Fallstudien selektieren auf positive Ergebnisse.

Für CDOs lautet die praktische Frage nicht, ob dbt State im Prinzip funktioniert (inkrementelle Berechnung ist gut etabliert), sondern ob das eigene dbt-Estate so strukturiert ist, dass State Tracking zuverlässig läuft. Teams mit schlecht dokumentierten Dependencies oder uneinheitlichem Model-Tagging werden den vollen Nutzen ohne vorherige Aufräumarbeit nicht erreichen.

Das Release von dbt v2 formalisiert außerdem die Richtung fürindustrialisierte SQL-Transformation im Enterprise-Maßstab: Das Tool positioniert sich ausdrücklich als Definition Layer dafür, was Daten bedeuten, getrennt davon, wo sie gespeichert oder berechnet werden.

Fivetran Context Layer und das Versprechen der Agent-Readiness

Die Hauptankündigung, gemeinsam von Fivetran und dbt Labs (beides Anbieter, beide mit kommerziellem Interesse an diesem Framing), ist der Fivetran Context Layer. Die Behauptung: Er macht Unternehmensdaten „agent-ready“, indem er AI-Agents strukturierten Kontext zu Datenassets liefert: was eine Tabelle darstellt, wie sie gebaut wurde, welche Business Rules für sie gelten und wie sie mit anderen Assets zusammenhängt.

Das ist relevant, weil Agents, die ein rohes Warehouse ohne diesen Kontext abfragen, unzuverlässige Outputs liefern. Ein Modell, das eine Spalte namens „revenue“ sieht, ohne zu wissen, ob es sich um realisierten, fakturierten oder eingegangenen Umsatz handelt, halluziniert sich eine Definition zusammen. Der Context Layer wird als Mechanismus präsentiert, der diese Lücke schließt.

Nehmen Sie das kommerzielle Framing hier ernst. Fivetran und dbt Labs haben ein gemeinsames Interesse daran, ihren Stack als Standard für Agent-Readiness zu positionieren. Das architektonische Konzept dahinter, Agents Zugriff auf reichhaltige Metadaten und semantischen Kontext zu geben statt nur auf rohe Tabellen, ist tragfähig und wird branchenweit zunehmend diskutiert. Die konkrete Umsetzung ist aber die Antwort eines Anbieters auf das Problem, kein etablierter Industriestandard.

Die haltbarere Erkenntnis betrifftaktive Metadaten und das, was ein Data Catalog leisten muss, wenn Agents und nicht Analysten die Zielgruppe sind. Agents brauchen Metadaten, die maschinenlesbar sind, immer aktuell und zum Zeitpunkt der Abfrage an den Daten hängen, statt in einem separaten Katalog zu liegen, in den Menschen gelegentlich hineinschauen. CDOs, die diese Lücke noch nicht adressiert haben, sollten nicht darauf warten, dass ein einzelner Anbieter sie für sie schließt.

dbt Charts und die Open-Lakehouse-Vision beobachten, noch nicht einführen

dbt Labs hat außerdem dbt Charts angekündigt, eine schlanke Visualisierungsfunktion, zusammen mit dem, was das Unternehmen als „Open Lakehouse Vision“ bezeichnet. Beides sind frühe Ankündigungen eines einzelnen Anbieters. dbt Charts adressiert einen realen Reibungspunkt: Teams, die Metriken heute in dbt definieren, brauchen weiterhin ein separates Tool, um sie darzustellen, und dieser Übergang erzeugt Inkonsistenzen. Ob ein Visualisierungs-Layer innerhalb eines Transformationstools bestehende BI-Investitionen verdrängt, wird sich erst über mehrere Quartale zeigen.

Das Open-Lakehouse-Framing ist eher strategisch als konkret. dbt Labs signalisiert, dass es auch auf der Storage- und Architekturebene antreten will, nicht nur bei der Transformation. CDOs mit bestehenden Databricks- oder Snowflake-Commitments sollten das als Positionierungsschritt notieren und die Entwicklung beobachten, insbesondere die für November 2026 angekündigte Abkündigung der dbt Snowflake Native App, eine konkrete Änderung, die jedes Team mit dieser Konfiguration im Blick behalten muss.

Modellierung für Agents folgt der Token-Ökonomie, nicht dem Analystenkomfort

Die Entwicklung, die diese Woche die meisten unterschätzen werden, ist ein kurzer Beitrag von dbt Labs darüber, wie ein Team die Token-Kosten um den Faktor zwanzig gesenkt hat, indem es Gong-Call-Transkripte im Warehouse modelliert hat, bevor sie an eine AI gingen, statt Rohtranskripte an die API zu schicken. Die Reduktion kam daher, dass die Daten so umstrukturiert wurden, dass der Agent nur das bekam, was er brauchte, in einem Format, das er effizient verarbeiten konnte.

Das ist eine andere Designdisziplin als klassische Datenmodellierung. Analysten tolerieren breite Tabellen, redundante Spalten und geschwätzige Schemata, weil sie gut filtern können. Agents nicht. Sie verbrauchen Tokens, und ihre Kosten skalieren mit der Ausführlichkeit dessen, was sie erhalten. Für CDOs heißt das: Datenprodukte für die Nutzung durch Agents brauchen explizite Modellierungsentscheidungen zur Token-Ökonomie, nicht nur semantische Klarheit. Teams, die Agent-Readiness als Übung im Beschriften von Metadaten behandeln, laufen beim Sprung vom Prototyp zur produktiven Last in genau dieses Problem.

Das Framing von O'Reilly Radar, „intelligent data orchestration“ als Nachfolger der Dashboards, weist in dieselbe Richtung: Die Frage verschiebt sich von „Kann ein Mensch das lesen?“ zu „Kann eine Maschine daraus zuverlässig und günstig schlussfolgern?“

Die praktische Priorität für die meisten CDOs in diesem Quartal ist nicht die Einführung eines bestimmten Tools aus den Ankündigungen dieser Woche. Sie besteht darin, zu prüfen, ob die eigenen Transformations- und Metadaten-Layer einem Agent genug Kontext geben würden, um eine belastbare Antwort zu erzeugen, und ehrlich zu benennen, wie groß der Abstand zwischen dem Ist-Zustand und dem Nötigen ist.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1dbt (data build tool): industrialisierte SQL-TransformationModerne Datenarchitektur
  2. 2Active Metadata und der Data CatalogModerne Datenarchitektur
  3. 3Der Metrics- und Semantic LayerAnalytics, BI & Decision Intelligence
  4. 4Data Lineage & Metadata Management: wissen, wo Ihre Daten geboren wurdenData Governance & Compliance
  5. 5Data Products: Definition, Design & Lifecycle ManagementModerne Datenarchitektur

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.