Open Data Infrastructure
dbt Core Exposure Contracts for AI Agents
How dbt exposures can describe downstream agent use, owners, freshness expectations, and incident routing.
An AI agent is a downstream consumer, even when nobody drew it in the DAG.
Agents need to be named as consumers
dbt projects are good at making transformation dependencies visible. AI workflows can undo that clarity if the agent is treated as an application outside the model graph. The model changes, the agent behavior changes, and nobody realizes the agent was a consumer until something breaks.
dbt exposures give analytics engineers a place to describe downstream use. For AI agents, that downstream use should include tool inputs, retrieved metrics, owner expectations, freshness windows, quality checks, refusal conditions, and incident routes.
Core idea: dbt exposures can become AI agent contracts when they name downstream agent use and the reliability evidence that use requires.
dbt exposures document downstream use
The dbt exposures documentation describes exposures as a way to define and describe downstream uses of a dbt project, including dashboards, applications, and data science pipelines. The exposure properties reference documents YAML-based exposure definitions.
That fits AI agents better than many teams expect. The agent does not need a special exemption from lineage. It needs a properly named downstream use case with owners, dependencies, and expectations.
Make the exposure agent-aware
- Create exposures for agents, tools, prompts, and workflows that depend on dbt models.
- Record owner, maturity, URL or runbook, freshness expectation, and required tests.
- Map model changes to affected agent actions before deployment.
- Attach incident response contacts to exposures that feed automated decisions.
- Review exposure coverage during AI governance audits.
This connects dbt Core and ODI, semantic contracts, and ODI for AI agents. The graph should show who depends on the model, even when the consumer is not human.
What breaks first
- A model rename breaks an agent tool, but the agent was never declared downstream.
- Freshness tests pass for dashboards but are too weak for automated action.
- The exposure names an application but not the agent behavior inside it.
- Incident routing goes to analytics engineering when the workflow owner needs to decide.
Questions to ask in exposure review
- Which agents, tools, or prompts consume this model?
- What freshness, quality, and semantic guarantees do they need?
- Who owns the downstream workflow when a model change changes agent behavior?
- Can the documentation site show affected agent exposures before deployment?
Sources to start with
These primary sources anchor the technical claims in this guide.
If an agent depends on a model, the graph should say so.