Agentengesteuerte Datenpipelines: Aufbau des Dagster + dbt + MCP-Stacks

Kernaussagen

• Fivetran und dbt Labs schlossen am 1. Juni 2026 eine Fusion ab (~600 Mio. $ kombinierter ARR, 100.000+ Datenteams) und lieferten Agents Schema — einen offenen Standard, der ein Warehouse-Schema in die governance-konforme, gemeinsam genutzte Kontextschicht für Agenten verwandelt.
• Databricks berichtet, dass über 80% der Datenbanken auf seiner Neon-Einheit von KI-Agenten bereitgestellt werden, nicht von Menschen — der primäre Konsument des Daten-Stacks hat sich bereits vom Analysten zum Agenten verlagert.
• Drei agentische Muster definieren die neue Pipeline — Agenten schreiben und gerüsten Pipeline-Code, Pipelines heilen sich selbst, indem sie Fixes vorschlagen und anwenden, und Agenten triagieren Ausführungsfehler im Chat — jedes davon benötigt maschinenlesbare Lineage, kein gerendertes Dashboard.
• Der Stack besteht aus drei governance-konformen Schichten — Dagster für Asset-Lineage, dbt für getestete Transformationen und geteilten Kontext, und ein MCP-Modul für richtlinienbeschränkten Zugriff — sodass ein Agent die Struktur der Pipeline unter denselben Kontrollen liest wie ein Mensch.

Der Daten-Stack wurde für menschliche Analysten gebaut: die Pipeline über Nacht laufen lassen, morgens ein Dashboard lesen, ein Ticket einreichen, wenn eine Zahl falsch aussieht. KI-Agenten konsumieren Daten anders. Wie es das fusionierte Fivetran + dbt Labs ausdrückt, arbeiten Agenten „kontinuierlich, parallel und mit Maschinengeschwindigkeit" — und sie benötigen die Struktur der Pipeline (Lineage, Tests, Definitionen), nicht nur ihre Ausgabe. Innerhalb eines Quartals bauten sich die größten Anbieter für Datenbewegung und -transformation um diese Tatsache herum um: die Fivetran + dbt-Fusion lieferte Agents Schema und stellte die dbt-Fusion-Engine als dbt Core v2.0 als Open Source bereit, und Databricks übernahm Electric, um jedem Agenten sein eigenes wegwerfbares Postgres zu geben.

Dieser Leitfaden baut das Muster in einem B2B-Beschaffungskontext: eine Pipeline, die Lieferantenkataloge, Preise und Bestände einliest und einem RFQ-Agenten zur Verfügung stellt. Er behandelt die drei Schichten — Dagster für asset-zentrierte Orchestrierung, dbt für governance-konforme Transformation und ein MCP-Modul für begrenzten Agentenzugriff — sowie die drei agentischen Muster, die die Pipeline sich selbst warten lassen. Am Ende wissen Sie, was jede Schicht beiträgt, warum Asset-Lineage die tragende Entscheidung ist, und wo der Mensch im Loop bleibt.

Warum asset-zentrierte Orchestrierung das Fundament ist

Die meisten Orchestrierungs-Fehlschläge für Agenten beginnen mit dem falschen mentalen Modell. Aufgabenzentrierte Scheduler (das klassische Cron-plus-DAG-Design) beantworten „ist dieser Job gelaufen?" Ein Agent, der fragt „warum ist der Acme-Preis veraltet?", braucht eine andere Antwort: „welches Daten-Asset ist veraltet, wovon hängt es ab, und was speist es?" Das ist eine Asset-Frage, und deshalb ist Dagsters asset-zentriertes Modell hier das Fundament und keine Präferenz.

In Dagster deklarieren Sie das Ding, das Sie produzieren — supplier_catalog, normalized_prices, availability_snapshot — und seine Abhängigkeiten. Der Orchestrator kennt dann den vollständigen Lineage-Graphen. Dagsters Declarative Automation lässt ein Asset aktualisieren, wenn sich sein Upstream ändert, statt nach einer festen Uhr, sodass „veraltet" zu einer Eigenschaft wird, über die das System nachdenken kann. Genau dieser Lineage-Graph ist es, was ein Agent braucht, um eine falsche Zahl ohne Raten auf ihre Quelle zurückzuverfolgen.

import dagster as dg

@dg.asset(group_name="procurement")
def supplier_catalog(context: dg.AssetExecutionContext) -> dg.MaterializeResult:
    rows = fetch_supplier_feed()  # NetSuite, EDI, CSV drop, etc.
    write_bronze("supplier_catalog", rows)
    return dg.MaterializeResult(metadata={"row_count": len(rows)})

@dg.asset(deps=[supplier_catalog], group_name="procurement",
          automation_condition=dg.AutomationCondition.eager())
def normalized_prices() -> None:
    # dbt owns the transformation logic; Dagster owns the lineage + trigger
    run_dbt(select="normalized_prices")

deps und automation_condition sind der springende Punkt: Der Agent (und die Selbstheilungsschleife weiter unten) kann diesen Graphen als Daten lesen. Airflow kam von der anderen Seite zur selben Schlussfolgerung — Airflow 3.2 fügte einen Common AI Provider und asset-bewusste Planung hinzu — und die Konsolidierung ist real: Prefect übernahm Dagster im Juli 2026. Unabhängig davon, auf welchen Orchestrator Sie sich standardisieren, ist die Anforderung dieselbe: Assets mit deklarierter Lineage, keine undurchsichtigen Aufgaben.

Warum dbt die Transformation und den governance-konformen Kontext besitzt

Dagster löst Arbeit aus und verfolgt Lineage; es sollte Ihre Geschäftslogik nicht enthalten. Die gehört in dbt, wo jede Transformation ein versionskontrolliertes SQL-Modell mit angehängten Tests, Dokumentation und semantischer Definition ist. Für Agenten ist das keine Annehmlichkeit — es ist die Vertrauensgrenze. dbts eigene Position ist, dass die Transformationsschicht das ist, was agentische Pipelines vertrauenswürdig macht: Ein Agent, der SQL gegen undefinierte, ungetestete Tabellen schreibt, automatisiert Chaos nur schneller.

Die wichtigste Ergänzung nach der Fusion ist Agents Schema: ein dediziertes Warehouse-Schema, das Metrikdefinitionen, semantische Modelle, dbt-Lineage und Geschäftsdokumentation als einfache SQL-Tabellen speichert. Statt dass jeder Agent neu ableitet, was „verfügbarer Bestand" bedeutet, lebt die Definition an einem einzigen governance-konformen, kundeneigenen Ort, von dem der Agent liest. Es ist das datenseitige Gegenstück zu einem governance-konformen Connector-Modul — eine einzige, richtlinienbeschränkte Quelle geteilten Kontexts statt einer pro-Agent-Kopie, die auseinanderdriftet.

-- models/marts/availability_snapshot.sql
select
    sku,
    warehouse_id,
    on_hand - allocated as available_qty,   -- the governed definition
    updated_at
from {{ ref('normalized_inventory') }}

-- schema.yml: the test that gates the agent's trust
-- - name: available_qty
--   tests: [not_null, {dbt_utils.accepted_range: {min_value: 0}}]

Ein fehlgeschlagener Test ist ein Signal, dass der Agent gegen diese Zeile keinen Preis nennen sollte. Genau diese eine Tatsache — ein maschinenlesbares Bestehen/Fehlschlagen für jedes Modell — ist es, was die nächsten zwei Muster laufen lässt, ohne dass ein Mensch jeden Schritt beobachtet.

Wo der Agent andockt: ein MCP-Modul, kein Datenbank-Login

Ein Agent sollte niemals rohe Warehouse-Zugangsdaten besitzen. Er sollte ein governance-konformes MCP-Modul aufrufen, das eine kleine Menge typisierter Tools bereitstellt — get_availability(sku, warehouse), get_tier_price(sku, customer_tier), list_substitutes(sku) — jedes davon einem getesteten dbt-Modell zugeordnet und jedes mit Richtlinienbereich, Ratenbegrenzung und Audit-Logging versehen. Das ist dasselbe Modulmuster, das für ERP- und Commerce-Connectoren verwendet wird, angewendet auf die eigene Ausgabe der Pipeline. Es hält den Explosionsradius klein: Der Agent kann availability_snapshot lesen, aber kein beliebiges SQL ausführen, und jeder Aufruf wird protokolliert.

Diese Grenze ist auch der Ort, an dem der pro-Agent-Zustand passt. Databricks' Übernahme von Electric — WASM Postgres (PGlite) innerhalb der Agenten-Sandbox, synchronisiert mit zentralem, governance-konformem Zustand — existiert, weil Agenten „Tausende winzige, wegwerfbare Datenbanken" für Arbeitskontext benötigen, getrennt von den dauerhaften, governance-konformen Tabellen. Die Faustregel: dauerhafte, geteilte, governance-konforme Daten leben hinter dem MCP-Modul; schnelllebiger, pro-Lauf-Scratch-Kontext lebt in der eigenen Sandbox des Agenten.

Die drei agentischen Muster, die dieser Stack ermöglicht

Mit Lineage (Dagster), getesteten Definitionen und geteiltem Kontext (dbt + Agents Schema) sowie begrenztem Zugriff (MCP) an ihrem Platz werden drei Muster praktikabel:

• Agentische Entwicklung. Agenten gerüsten neue Assets und Transformationen — entwerfen das dbt-Modell, schlagen den Schema-Test vor, verdrahten das Dagster-Asset — gegen den bestehenden Lineage-Graphen. Dagster liefert dagster-io/skills für Claude Code und Codex sowie einen Compass-Slack-Assistenten; Bruin stellt einen MCP-Server für denselben Zweck bereit. Der Mensch prüft einen Pull Request, keine leere Datei.
• Selbstheilende Pipelines. Wenn ein Schema-Test fehlschlägt oder ein Upstream-Asset ausfällt, liest der Agent die Lineage, isoliert das fehlerhafte Modell, schlägt einen Fix vor und wendet ihn entweder in einem Canary-Lauf an oder reicht einen PR ein. Weil Dagster den Abhängigkeitsgraphen kennt und dbt weiß, welcher Test fehlgeschlagen ist, ist der Fix lineage-bewusst statt ein blinder Wiederholungsversuch.
• Agentische Fehlerbehebung. Bei einem Ausfall liest der Agent die Ausführungsprotokolle und Metadaten und antwortet in Slack oder Teams mit der wahrscheinlichen Ursache und einem vorgeschlagenen Fix — das Muster, um das herum Dagster Compass und Snowflake Cortex gebaut sind. Bereitschafts-Debugging verschiebt sich vom Lesen von Dashboards zur Prüfung der Diagnose eines Agenten.

Keines davon entfernt den Menschen. Jede angewendete Änderung durchläuft ein Test-Gate, einen Canary oder eine Prüfung — dieselbe Disziplin, die die dbt Summit 2026-Keynotes als den Preis dafür beschrieben, Agenten Produktionsdaten anfassen zu lassen.

Der Stack im Überblick

Ein repräsentativer Aufbau

Ein Distributor, der NetSuite, zwei Lager und drei Lieferantenkataloge betreibt, wollte einen RFQ-Agenten, der Angebote erstellen konnte, ohne dass ein Mensch die Verfügbarkeit von Hand abruft. Die Pipeline war der Blocker, nicht das Modell. Wir deklarierten die Katalog-, Preis- und Bestands-Assets in Dagster mit expliziter Lineage; verschoben die Preis- und Verfügbarkeitslogik in getestete dbt-Modelle mit einem Agents Schema, das die Definition von „verfügbar zur Zusage" festlegte; und stellten drei typisierte Tools über ein auf Nur-Lesen beschränktes MCP-Modul bereit. Die Selbstheilungsschleife fängt jetzt einen defekten Lieferanten-Feed ab und reicht vor dem morgendlichen Angebotslauf einen PR mit dem Fix ein; die Bereitschaftszeit bei Pipeline-Ausfällen sank, weil die erste Antwort des Agenten eine Diagnose ist, kein Pager-Alarm. Der Agent erstellt Angebote gegen getestete Daten oder verweigert dies — er erstellt niemals ein Angebot gegen eine Zeile, die ihren Test nicht bestanden hat.

Weiterführende Lektüre

• Kaskadierende Pipeline-Ausfälle: Wie ein Agent den Bereitschafts-Debugging um 75 % senkt — die Selbstheilungs- und agentischen Fehlerbehebungsmuster als operativer Anwendungsfall mit den Bereitschaftszahlen
• MCP-Modul-Code-Standard — das strukturelle Muster hinter dem governance-konformen, richtlinienbeschränkten MCP-Modul, das die Pipeline vorschaltet
• KI-Agenten-Observability: Was Sie nicht sehen, wird Ihnen schaden — warum Ausführungsprotokolle und Lineage-Metadaten das Substrat sind, auf dem agentische Fehlerbehebung beruht

Der Aufbau einer agentengesteuerten Pipeline auf Ihrem eigenen Stack — NetSuite, ein Warehouse, Lieferanten-Feeds — beginnt damit, zu wissen, welche Assets existieren und wo die Definitionen liegen.

Einen abgegrenzten Build anfordern. Einwöchiges Discovery. Sie erhalten ein Systeminventar, eine Workflow-Map und einen festen Umfang — ob Sie mit uns bauen oder nicht.