The Agentic Workflow for Your Data Workflows
Turn data work and drift into governed, human-reviewed dbt changes, inside the tools and infrastructure your team already controls.
- Runs in your CI
- Opens a draft change
- Never merges it
Data work never arrives in one neat queue.
Your team is pulled by requests from people and by changes in the systems underneath them. Both demand context, judgment, and a change someone can review.
Requests from people
Each one waits on whoever holds the context.
Drift from systems
Usually found by whoever trusted the number.
- 1Grounded
Reads your dbt project and warehouse before it writes anything.
- 2Authored
Model SQL, tests, and semantic definitions in your project's layout.
- 3Validated
Parsed and built against a dev target, never production.
- 4Reviewed
A draft change with the run attached. Your reviewers decide.
Both end in something your team can review.
Two workflows. One review contract.
Whether work begins with a person or a changing warehouse, Dex Enterprise grounds the change in the same dbt project and returns control to your team.
Turn the backlog into reviewable dbt changes.
A request arrives with the context the person gave it. Dex Enterprise grounds that request in your project and your warehouse, authors the change, validates it against a dev target, and hands back a draft pull request tied to the work that asked for it.
Add net_revenue to fct_orders
Run evidence
- Grounded in
- 12 models · 3 sources, read this run
- Plan validated
- every ref and grain resolved
- Dev build
- passed on the dev target
- Linked to
- DATA-418
Turn drift into action before it becomes breakage.
A scheduled check compares the warehouse against the baseline your team accepted. Findings arrive grouped rather than one alert at a time, and each one resolves into either a proposed change or an advisory that names the decision a person needs to make.
Baseline accepted 12 Aug · advances only when a person accepts it
2 findings · 1 draft change · 1 advisory
Repeat findings are deduplicated and cooled off, not filed again.
You get a diff, its evidence, and a decision to make.
The thing that lands in your repository is reviewable the ordinary way: a small change in your project's own layout, with the run that produced it attached, and nothing merged on your behalf.
Grounded, or it stops
Every change is authored against your dbt project and warehouse as they were read during that run. If a reference cannot be resolved in that evidence, the run refuses to author rather than guessing at a column or a join.
Validated on a dev target
The change is parsed and built before you see it, against a dedicated dev namespace with no production write. If the build fails, the draft says so. It is never described as verified when it is not.
A diff, not a description
Model SQL, schema tests, and semantic definitions, written in the paths your project already uses. You review a normal pull request, with the same rules and the same reviewers as any other change, and a review comment starts another grounded run rather than a conversation with a model.
Quiet by design
Findings are fingerprinted, grouped, capped, and cooled off, so a recurring problem does not become a recurring notification. An unrecognised finding becomes an advisory, never an edit.
What a run can propose
Dex Enterprise proposes familiar analytics-engineering changes. Configuration and governance remain under human control.
Authored
Proposed as a draft change for review.
- Model SQL
- Tests and documentation
- Semantic definitions
- Changes in your analytics project
Advisory only
Named for a person to decide. Never built or published unattended.
- Changes requiring design judgment
- Project configuration
- Dependencies
- Other work that needs an owner
Outside the workflow
Repository governance and system configuration stay with your team.
- Review and merge rules
- Workflow configuration
- Access and policy settings
- Anything outside your analytics project
The engine that writes the change is open source.
Dex Enterprise decides when analytics-engineering work runs and how the result reaches your team. The analytics engineering itself is open-source Dex: Apache-2.0, readable before you buy anything, and measured in public.
Your organizational workflow
Exmergo DexOpen-source Dex- Warehouse access and project understanding
- dbt and semantic authoring
- Plan validation and reviewable diffs
- Four-axis drift detection
- Reconcile plans and blast-radius ordering
- Cost guard and PII policy
Measured on somebody else's benchmark
data-eng-bench hands an agent a ticket against a 2,356-model dbt project and scores whether that task's own verifier runs clean afterwards. It is the same shape of work Dex Enterprise runs unattended, scored by somebody who does not sell it.
Runs in your environment. Answers to your controls.
Workflow execution happens inside the CI environment your organization already governs, using identities and services you control.
Your identities
Access and permissions remain under your control.
Your warehouse
Your team governs the environment and safeguards around it.
Your review rules
Branch protection stays authoritative, with no Dex bypass.
Your inference provider
Your account, your region, your retention policy.
Your secrets
Credentials remain managed within your environment.
Your records
Run history remains with your organization.
Your controls remain authoritative.
Dex Enterprise is designed to produce a reviewable proposal within the controls your team already owns, not to act as an independent operator in your systems.
No merge authority
It can propose a change, but your repository rules decide what is merged.
Customer-governed execution
The run works within the environment and access your team controls.
Bounded workflow
A run follows the agreed workflow rather than operating freely in your systems.
Exmergo does not receive customer data-plane content.
No Exmergo service sits in the workflow run path.
The normal output is a draft change. Dex Enterprise does not approve or merge it.
What it does not claim: that every proposed change is correct, that every secret is detected, or that a required human review makes a diff safe to merge. Human review is a control, not proof.
Frequently asked questions
- What is Dex Enterprise?
- Dex Enterprise is the organization-wide workflow for Exmergo Dex. It turns data requests and scheduled drift into governed, human-reviewed dbt changes while the dbt project and the customer’s review rules remain authoritative.
- How is Dex Enterprise different from open-source Dex?
- Open-source Dex gives an individual analytics engineer the complete Explore, Transform, Maintain loop on demand. Dex Enterprise brings that same analytics-engineering foundation into unattended organizational workflows around requests, scheduling, review, and audit. The engine that reads the warehouse and writes the dbt change is the same open-source engine in both cases.
- What does Dex Enterprise change in my repository?
- An unattended run may propose model SQL, schema tests and documentation, and semantic definitions in the project paths you configure. Configuration, workflow, and repository-governance files remain for a person to decide. Every proposal arrives as a draft change for your normal review process.
- What stops the agent from doing something destructive?
- Dex Enterprise works within the controls your organization owns and produces a draft change for review. It does not independently approve or merge a change; your repository rules and reviewers remain authoritative.
- How does Dex Enterprise avoid flooding my team with pull requests and alerts?
- Drift findings are fingerprinted, grouped, capped, and cooled off, so a scheduled check produces one grouped result rather than an alert per finding, and a recurring problem does not become a recurring notification. A finding the engine does not recognise becomes an advisory rather than an edit. The accepted baseline only advances when a person accepts it, so a scheduled run never quietly redefines what good looks like.
- Does Dex Enterprise run in Exmergo’s cloud?
- No. Dex Enterprise workflow execution runs in the customer’s CI environment using identities and services the customer controls. Exmergo does not receive customer data-plane content, and no Exmergo service sits in the workflow run path.
- Does the model see our data?
- Dex Enterprise is designed to keep execution in your environment and to avoid sending customer data-plane content to Exmergo. Your organization controls the inference provider, account, region, and retention posture used by the workflow.
- How are warehouse and model costs controlled?
- The open-source engine estimates billable work before it runs it, gates it against a per-command ceiling and a cumulative session ceiling, caps results, and settles actual spend. Workflow policy can lower that ceiling for a given run but can never raise it. Because the run is in your environment, your own warehouse timeouts, resource monitors, statement limits, and billing alerts remain an independent second brake.
- Can Dex Enterprise merge changes automatically?
- No. The normal output is a draft change for human review. Dex Enterprise does not intentionally approve or merge it; the customer’s repository rules and reviewers decide what becomes part of the dbt project. The publishing step contains no merge or approval operation, and your branch protection is expected to require independent review with no bypass for the Dex identity.
- What happens when a reviewer asks for a change?
- A reviewer can ask for another pass through the same governed workflow. The change is reconsidered against the current project and returns as another reviewable draft, with your team deciding whether and when to proceed.
- What does the audit trail contain?
- Each run leaves a record of the workflow and the draft it produced. Content is excluded by default, and the record remains with your organization for your own audit and review processes.
- What does Dex Enterprise work with?
- It runs against a dbt project in version control, on the warehouse that project already targets, using the same connectors as open-source Dex. We work with design partners to fit Dex Enterprise into the systems and workflows their teams already use.
- Is Dex Enterprise available today?
- Dex Enterprise is being developed with design partners and is not generally available. Data teams can apply to discuss the workflows they want to improve.
Become a Dex Enterprise design partner
We are working with a small group of data teams to shape Dex Enterprise around the workflows they need to run continuously, without giving up review, governance, or control.
What the conversation covers
- The requests and maintenance work your team absorbs today
- How a change gets reviewed and merged in your repository
- Where an unattended run would have to stop and ask a person
What we look for
- A dbt project in version control, with review required to merge
- A warehouse your team already governs, and CI you already run
- A person who owns what a definition means