Pipelines de datos orquestados por agentes: construyendo la pila Dagster + dbt + MCP

Conclusiones clave

• Fivetran y dbt Labs completaron una fusión el 1 de junio de 2026 (~$600M de ARR combinado, más de 100,000 equipos de datos) y lanzaron Agents Schema — un estándar abierto que convierte un esquema de warehouse en la capa de contexto compartido gobernado para agentes.
• Databricks reporta que más del 80% de las bases de datos de su unidad Neon las aprovisionan agentes de IA, no humanos — el consumidor principal de la pila de datos ya cambió del analista al agente.
• Tres patrones agénticos definen el nuevo pipeline — los agentes escriben y andamian código de pipeline, los pipelines se autorreparan proponiendo y aplicando correcciones, y los agentes triajan fallos de ejecución en chat — cada uno de los cuales necesita linaje legible por máquina, no un dashboard renderizado.
• La pila son tres capas gobernadas — Dagster para el linaje de activos, dbt para transformaciones probadas y contexto compartido, y un módulo MCP para acceso con alcance de política — de modo que un agente lee la estructura del pipeline bajo los mismos controles que usaría un humano.

La pila de datos se construyó para analistas humanos: ejecutar el pipeline durante la noche, leer un dashboard por la mañana, abrir un ticket cuando un número parece incorrecto. Los agentes de IA consumen datos de otra manera. Como lo expresó la fusión de Fivetran + dbt Labs, los agentes "operan de forma continua, en paralelo, y a velocidad de máquina" — y necesitan la estructura del pipeline (linaje, pruebas, definiciones), no solo su salida. En un trimestre, los mayores proveedores de movimiento de datos y transformación se reconstruyeron en torno a ese hecho: la fusión de Fivetran + dbt lanzó Agents Schema y liberó el motor dbt Fusion como código abierto bajo dbt Core v2.0, y Databricks adquirió Electric para darle a cada agente su propio Postgres desechable.

Esta guía construye el patrón en un contexto de aprovisionamiento B2B: un pipeline que ingiere catálogos de proveedores, precios e inventario, y los expone a un agente de RFQ. Cubre las tres capas — Dagster para orquestación centrada en activos, dbt para transformación gobernada, y un módulo MCP para acceso de agente con alcance limitado — y los tres patrones agénticos que hacen que el pipeline se mantenga a sí mismo. Terminarás sabiendo qué aporta cada capa, por qué el linaje de activos es la elección estructural, y dónde permanece el humano en el bucle.

Por qué la orquestación centrada en activos es la base

La mayoría de los fallos de orquestación para agentes comienzan con el modelo mental equivocado. Los planificadores centrados en tareas (el diseño clásico de cron más DAG) responden "¿se ejecutó este trabajo?" Un agente que pregunta "¿por qué el precio de Acme está desactualizado?" necesita una respuesta distinta: "¿qué activo de datos está desactualizado, de qué depende y qué lo alimenta?" Esa es una pregunta de activo, y es la razón por la que el modelo centrado en activos de Dagster es la base aquí, más que una preferencia.

En Dagster declaras la cosa que produces — supplier_catalog, normalized_prices, availability_snapshot — y sus dependencias. El orquestador entonces conoce el grafo de linaje completo. La Declarative Automation de Dagster permite que un activo se actualice cuando cambia su upstream en lugar de en un reloj fijo, de modo que "desactualizado" se convierte en una propiedad sobre la que el sistema puede razonar. Ese grafo de linaje es exactamente lo que un agente necesita para rastrear un número incorrecto hasta su origen sin adivinar.

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")

Los deps y automation_condition son el punto central: el agente (y el bucle de autorreparación más abajo) pueden leer este grafo como datos. Airflow llegó a la misma conclusión desde el otro lado — Airflow 3.2 añadió un Common AI Provider y programación consciente de activos — y la consolidación es real: Prefect adquirió Dagster en julio de 2026. Sea cual sea el orquestador en el que estandarices, el requisito es el mismo: activos con linaje declarado, no tareas opacas.

Por qué dbt posee la transformación y el contexto gobernado

Dagster dispara trabajo y rastrea linaje; no debe contener tu lógica de negocio. Eso pertenece a dbt, donde cada transformación es un modelo SQL versionado con pruebas, documentación y una definición semántica adjunta. Para los agentes esto no es un lujo — es el límite de confianza. La propia postura de dbt es que la capa de transformación es lo que hace confiables a los pipelines agénticos: un agente que escribe SQL contra tablas indefinidas y no probadas automatiza el caos más rápido.

La incorporación posterior a la fusión que más importa es Agents Schema: un esquema de warehouse designado que almacena definiciones de métricas, modelos semánticos, linaje de dbt y documentación de negocio como tablas SQL simples. En lugar de que cada agente vuelva a derivar qué significa "disponibilidad en existencia", la definición vive en un único lugar gobernado y propiedad del cliente, del que el agente lee. Es la contraparte del lado de los datos de un módulo conector gobernado — una sola fuente de contexto compartido con alcance de política, en lugar de una copia por agente que se desalinea con el tiempo.

-- 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}}]

Una prueba que falla es una señal de que el agente no debe citar esa fila. Ese único hecho — un pasa/falla legible por máquina en cada modelo — es lo que permite que los dos patrones siguientes se ejecuten sin que un humano vigile cada paso.

Dónde se conecta el agente: un módulo MCP, no un login de base de datos

Un agente nunca debe tener credenciales de warehouse en bruto. Debe llamar a un módulo MCP gobernado que expone un pequeño conjunto de herramientas tipadas — get_availability(sku, warehouse), get_tier_price(sku, customer_tier), list_substitutes(sku) — cada una mapeada a un modelo dbt probado y cada una con alcance de política, límites de tasa y registro de auditoría. Este es el mismo patrón de módulo usado para conectores de ERP y comercio, aplicado a la propia salida del pipeline. Mantiene pequeño el radio de impacto: el agente puede leer availability_snapshot pero no puede ejecutar SQL arbitrario, y cada llamada queda registrada.

Ese límite es también donde encaja el estado por agente. La adquisición de Electric por parte de Databricks — Postgres en WASM (PGlite) dentro del sandbox del agente, sincronizado con el estado central gobernado — existe porque los agentes "necesitan miles de bases de datos pequeñas y desechables" para contexto de trabajo, mantenidas separadas de las tablas duraderas y gobernadas. La regla general: los datos duraderos, compartidos y gobernados viven detrás del módulo MCP; el contexto de trabajo efímero y por ejecución vive en el propio sandbox del agente.

Los tres patrones agénticos que habilita esta pila

Con linaje (Dagster), definiciones probadas y contexto compartido (dbt + Agents Schema), y acceso con alcance limitado (MCP) en su sitio, tres patrones se vuelven prácticos:

• Desarrollo agéntico. Los agentes andamian nuevos activos y transformaciones — redactan el modelo dbt, proponen la prueba de esquema, conectan el activo de Dagster — contra el grafo de linaje existente. Dagster ofrece dagster-io/skills para Claude Code y Codex y un asistente de Slack llamado Compass; Bruin expone un servidor MCP con el mismo propósito. El humano revisa un pull request, no un archivo en blanco.
• Pipelines autorreparables. Cuando una prueba de esquema falla o un activo upstream se rompe, el agente lee el linaje, aísla el modelo con fallo, propone una corrección y la aplica en una ejecución canary o abre un PR. Como Dagster conoce el grafo de dependencias y dbt sabe qué prueba falló, la corrección está informada por el linaje en lugar de ser un reintento a ciegas.
• Resolución de problemas agéntica. Ante un fallo, el agente lee los logs de ejecución y los metadatos y responde en Slack o Teams con la causa probable y una corrección propuesta — el patrón sobre el que se construyen Dagster Compass y Snowflake Cortex. La guardia de turno pasa de leer dashboards a revisar el diagnóstico de un agente.

Ninguno de estos elimina al humano. Todo cambio aplicado pasa una barrera de prueba, un canary o una revisión — la misma disciplina que las ponencias de dbt Summit 2026 enmarcaron como el precio de dejar que los agentes toquen datos de producción.

La pila, en una sola vista

Una construcción representativa

Un distribuidor que operaba NetSuite, dos almacenes y tres catálogos de proveedores quería un agente de RFQ capaz de cotizar sin que un humano tuviera que consultar la disponibilidad a mano. El pipeline era el obstáculo, no el modelo. Declaramos los activos de catálogo, precio e inventario en Dagster con linaje explícito; movimos la lógica de precios y disponibilidad a modelos dbt probados con un Agents Schema que fijó la definición de "disponible para prometer"; y expusimos tres herramientas tipadas a través de un módulo MCP con alcance de solo lectura. El bucle de autorreparación ahora detecta un feed de proveedor roto y abre un PR con la corrección antes de la ejecución de cotización matutina; el tiempo de guardia por fallos de pipeline se redujo porque la primera respuesta del agente es un diagnóstico, no una alerta. El agente cotiza contra datos probados o se niega — nunca cotiza contra una fila que falló su prueba.

Lecturas relacionadas

• Pipeline Failures That Cascade: How an Agent Cuts On-Call Debugging by 75% — los patrones de autorreparación y resolución agéntica como caso de uso operativo con las cifras de guardia
• MCP Module Code Standard — el patrón estructural detrás del módulo MCP gobernado y con alcance de política que da la cara al pipeline
• AI Agent Observability: What You Can't See Will Hurt You — por qué los logs de ejecución y los metadatos de linaje son el sustrato del que depende la resolución de problemas agéntica

Construir un pipeline orquestado por agentes sobre tu propia pila — NetSuite, un warehouse, feeds de proveedores — empieza por saber qué activos existen y dónde viven las definiciones.

Solicita una construcción con alcance definido. Descubrimiento de una semana. Obtienes un inventario del sistema, un mapa de flujo de trabajo y un alcance fijo — construyas o no con nosotros.