How dbt and Dex form the agent-native data stack

Every coding agent can write a dbt model now. That is not the hard part.

Point an agent at a schema.yml and ask for a staging model; it will produce SQL. It may even compile. But analytics engineering is not primarily an exercise in producing SQL. It is deciding what the data means, understanding what the project already says about it, and noticing when the two have stopped agreeing.

That is where an ungrounded agent fails. It begins each session with no reliable memory of the warehouse, no understanding of the dbt graph. Give it raw shell access and it will often compensate the only way it can: enumerate schemas, sample rows, guess, and keep going. That is a poor way to make production definitions.

The useful question is not whether an agent can author a dbt model. The question is what has to surround that capability before an analytics engineer can trust the work.

Our answer:

• The warehouse holds the current facts.
• dbt holds the transformations, tests, documentation, and semantic definitions a team has reviewed.
• Dex gives an agent a governed way to learn from the first and change the second.

dbt remains the source of truth for the analytics project. Dex does not introduce a second modeling system for an engineer to reconcile. It explores the warehouse, reads the project as context, proposes changes as ordinary project diffs, and keeps evidence about what was true when the work was done.

That sounds like a small distinction. It is the difference between an agent that writes code and one that can be a useful contributor to the analytics engineering lifecycle.

The job is Explore, Transform, Maintain

Analytics engineering has a loop that is easy to overlook because we often discuss only the middle of it.

First, you make sense of a warehouse. Then you turn raw data into models and metrics. Then you keep those definitions correct while source systems, data shapes, and business rules move underneath them. Explore, Transform, Maintain.

dbt is excellent at the middle. It gives data teams a durable, reviewable home for models, tests, and semantic definitions. Dex is built around the full loop, because an agent needs the work before and after a model change as much as it needs the change itself.

Explore: evidence before SQL

Before an agent writes a model, it needs to know which tables matter, what their grain is, whether a supposed key is actually unique, and whether a column is safe to inspect. Dex profiles selectively rather than dumping an information schema into an agent’s context. It builds a map of relationships, candidate keys, data-quality findings, and likely PII. Read-only against the warehouse.

The dbt project can then act as a useful prior, not a substitute for observation. With project context enabled, Dex can see declared relationships, model lineage, declared grain, and the semantic models that depend on a relation. A relationship declared in the project stays a declaration. If a warehouse probe finds that its parent side is largely missing, Dex reports a finding; it does not rewrite your project’s claim based on one measurement.

That is the right relationship between data and code. The warehouse supplies evidence. dbt supplies intent. A discrepancy is a decision for an engineer, not an opportunity for an agent to invent a new definition.

This matters most on the mundane problems that make analytics projects expensive: a CDC feed with duplicate records, a source that changes an identifier’s format, a join that shares a promising column name but has no overlap, or a table whose grain has always been assumed rather than measured. These are context problems, not SQL generation ones.

Transform: a proposal, not an autonomous edit

Once the agent has done its grounding work, Dex orchestrates implementation work on dbt’s native materials: model SQL, schema tests and documentation, and MetricFlow semantic YAML. It can scaffold a staging model, trace references before a rename, decide where a shared derived column belongs in the graph, or propose a semantic definition. The output is a diff in the project your team already reviews. Dex lives and breathes your workflow.

Every proposed edit is stored as a plan and pinned to the files it was built against. Before applying it, Dex checks those files again. If a human changed one in the meantime, the plan does not overwrite their work. It surfaces the divergence and requires the work to be reconsidered against the current project.

That is much more than a convenient (or bureaucratic) approval step. It makes the human the authority in the. An agent can move quickly without being allowed to turn a stale understanding into a silent change.

The same posture shows up in more specialized work. transform rename follows the dbt reference graph and refuses if it cannot prove a complete rewrite. transform remove refuses while reads remain, rather than guessing what an expression or Jinja conditional should become. Semantic changes are validated against dbt’s own parser before they become a plan. And the cherry on top: builds are limited to a dev target, with a cost preflight before billed work runs.

None of that is glamorous. It is what lets an engineer use an agent on a real project without treating every output as an untrusted starting point.

Maintain: the part most agents forget

A model can be correct on the day it is merged and wrong a month later without a line of dbt changing. A source column disappears. A backfill breaks uniqueness. A new category arrives that no metric definition maps. Finance changes what a metric is supposed to mean.

This is the part of analytics engineering that general coding agents are least equipped to do. They have no reliable recollection of what they observed last week, and a fresh schema dump cannot tell them what is new.

Dex’s maintain loop compares the current warehouse and project with a known-good snapshot. It looks for four kinds of drift: schema, volume, grain, and semantic definition drift. Findings are ranked by likely blast radius, and reconciliation is proposed as a reviewable dbt change or surfaced as an advisory when a human has to make a definition decision.

The important distinction is between change and drift. Warehouses change all the time. Drift is a change relative to a state the team accepted as correct.

Long-term memory should be evidence, not a black box

People often describe agents as having a memory problem. In analytics engineering, the problem is much more specific: the agent needs a record of what it learned, how it learned it, and what the team accepted as true. It also needs that record to survive the next session, the next engineer, and the next model provider.

Dex keeps that memory in .dex/ beside the project. The exploration cache records profiles, PII flags, inferred relationships, grain evidence, and data-quality findings. A snapshot records the baseline used for drift detection. Query and spend ledgers make the agent’s warehouse activity inspectable without retaining result values or credentials.

This memory is deliberately non-canonical. Delete it and the project definitions are still in dbt; the warehouse is still the warehouse. Dex can rebuild its cache. But while it exists, it changes the quality of the next interaction. The agent no longer needs to rediscover a large warehouse from scratch, and a coworker can see which observations underpinned a proposed change.

Keeping this evidence with the repository also makes acceptance visible. Updating a baseline is not an invisible action inside a vendor service. It is a change that can be reviewed like a lockfile update. That matters when the question is not merely “did something change?” but “when did we agree that this was the state we trusted?”

There is an important discipline here: memory is only useful when its coverage is honest. A partial exploration should not masquerade as a complete warehouse map. Dex reports what it profiled and what it elided, so a team can decide whether a snapshot is sufficient for the drift checks it expects to run. A stale or incomplete baseline is not worse than no baseline because it exists; it is worse when it looks like one the team can rely on.

Guardrails are part of the capability

It is tempting to describe guardrails as restrictions on an agent. In data work, they are what make the agent usable.

Dex keeps warehouse exploration read-only. Agent-authored SQL runs through a query firewall, and values reach agent context only from profiled, PII-cleared columns in bounded results. Credentials do not cross the command boundary. A likely sensitive column is flagged conservatively; clearing a false positive is a durable, reviewable configuration decision, not a hidden exception in an agent session.

It also treats cost as an engineering constraint rather than an unpleasant surprise. On metered warehouses, Dex estimates billable work before it runs and asks for an explicit budget confirmation. Connector-specific server-side caps provide a second brake. The exception is worth stating: when a hosted dbt Cloud Semantic Layer runs a query on its own warehouse connection, Dex cannot impose its own cost ceiling. It labels that limitation on every result instead of implying a guarantee it cannot enforce.

Finally, changes are proposed, not imposed. The engine can write a plan and apply a reviewed diff; it does not silently rewrite the project or run production builds. These boundaries are implemented in the tool, not requested in a prompt. That is the difference between “make no mistakes” and a refusal an agent cannot talk its way past.

When the user becomes a data team

For one analytics engineer, this is already useful: less rediscovery, better grounding, and faster diffs. For a data team, the same ideas become operational.

Memory stops being a personal productivity trick and becomes a shared asset. A reviewed baseline means five engineers and their agents do not independently learn that a source key lost uniqueness. Guardrails stop depending on the habits of the person who happened to run the agent. And drift work no longer waits until a stakeholder discovers a broken metric.

The bottleneck changes, too. Agents can author faster than people can review. A useful team workflow therefore cannot generate an alert or a pull request for every observation. It needs to group findings, preserve the evidence, distinguish a safe mechanical change from a definition decision, and return work through the review process the team already trusts.

Dex for the Enterprise data team

Dex Enterprise is the organizational workflow around the open-source engine. It turns two sources of analytics work into governed, human-reviewed dbt changes: requests from people and scheduled checks for drift.

For requested work, a task is grounded in the current dbt project and warehouse, authored as model SQL, tests, documentation, or semantic definitions, validated on a dev target, and delivered as a draft change tied to the request. For continuous maintenance, a scheduled check compares current reality with the baseline the team accepted. It groups the findings and produces either a proposed change or an advisory that names the decision an owner must make.

The review contract is the point. Dex Enterprise runs in the CI environment your organization controls, using your identities, your warehouse permissions, your inference provider, and your retention policy. It opens a draft change. It never merges it. Repository rules, reviewers, workflow configuration, and access policy remain with your team.

It also draws a clear line around unattended work. Model SQL, tests, documentation, and semantic definitions may be proposed in the project paths you configure. Configuration, dependencies, governance, and design decisions remain advisory. That is how an agent can accelerate a data team without becoming an independent operator in its systems.

Start with the stack you already have

dbt is where your team defines its data. Dex gives your coding agent the evidence, memory, and guardrails to work with those definitions responsibly.

If you are an analytics engineer, install open-source Dex in the agent environment you already use:

npx skills add exmergo/dex

If you run a data team and need scheduled maintenance, a shared review contract, and an agent workflow that stays inside your controls, see Dex Enterprise.

Resources

www.exmergo.com/dex

www.exmergo.com/dex/enterprise