# Dex Enterprise: 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. Dex Enterprise brings the open-source Dex analytics-engineering loop into the organization. Data requests and meaningful drift move through one governed path to a draft change or a clear advisory, while your dbt project, review rules, and people remain authoritative. It runs in your CI. It opens a draft change. It never merges it. [Talk to Sales](https://www.exmergo.com/contact-sales) about bringing Dex Enterprise into your data workflow. ## 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** arrive on their schedule: a new metric, a model duplicated after a backfill, a definition that has to match finance. Each one waits on whoever holds the context. - **Drift from systems** arrives without warning: a source column dropped, a table that lost its unique key, a metric that no longer matches the business. It is usually found by whoever trusted the number. Both end in something your team can review, along one path: 1. **Grounded.** Reads your dbt project and warehouse before it writes anything. 2. **Authored.** Model SQL, tests, and semantic definitions in your project's layout. 3. **Validated.** Parsed and built against a dev target, never production. 4. **Reviewed.** A draft change with the run attached. Your reviewers decide. ## 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. ### 01. Requested work: 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. What the reviewer opens is a normal draft pull request on a Dex branch: the changed model SQL, schema file, and semantic definition with their diff counts, and a run-evidence block recording what the change was grounded in, that every reference and grain resolved, that the dev build passed on the dev target, and which work item asked for it. Review is required, with no bypass for the Dex identity. ### 02. Continuous maintenance: 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. A nightly check reports all four axes, including the ones with nothing to say. A dropped source column becomes one reconcile change across the models that reference it. A grain that no longer holds becomes an advisory, because the fix is a definition decision rather than a mechanical edit. Repeat findings are deduplicated and cooled off, not filed again, and the accepted baseline advances only when a person accepts it. ## 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, and changes in your analytics project. - **Advisory only**, named for a person to decide and never built or published unattended: changes requiring design judgment, project configuration, dependencies, and other work that needs an owner. - **Outside the workflow:** repository governance and system configuration stay with your team, including review and merge rules, workflow configuration, access and policy settings, and 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. The organizational workflow owns triggers, scheduling, actor authority, review context, noise policy, and the audit trail. Open-source Dex owns warehouse access and project understanding, dbt and semantic authoring, plan validation and reviewable diffs, four-axis drift detection, reconcile plans and blast-radius ordering, and the cost guard and PII policy. The output of that workflow is a draft change or an advisory, and the next authority is human review. Measured on somebody else's benchmark: - **76% on ADE-bench**, Dex with Claude Sonnet 5, 57 of 75 tasks. - **57.3% on data-eng-bench at k=1**, the highest published figure for any Claude Sonnet 5 configuration. 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. Inside that boundary: the work item, the CI workflow, the guarded Dex run, the draft pull request, and human review. - **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. ## Design Partnership 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, and 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, and a person who owns what a definition means. [Apply as a Dex Enterprise design partner](https://www.exmergo.com/contact-sales?type=dex-enterprise), or [start with open-source Dex](https://www.exmergo.com/dex).