How Monte Carlo and Dex keep your data healthy

The alert arrived before the stakeholder did. Your monitoring worked!
But, and there’s always a but: someone still has to find the affected models, work out what should change, update the tests and metric definitions, and get a pull request through review. 
That person was supposed to be building something else today!

For a data and analytics leader, this is how maintenance takes over a roadmap. Each incident is reasonable work. 100 incidents together are a concoction that consumes the engineering team’s bandwidth.

Monte Carlo brings data observability to the data stack: visibility into data health, dependencies, and incidents. A team needs that visibility alongside the capacity to build and maintain its analytics project. 

That’s where Dex comes in.

Dex is an open-source analytics-engineering toolkit for coding agents such as Claude. It gives an agent the tools to explore a warehouse, build transformation pipelines and semantic layers, and keep those definitions aligned as the data changes. Dex Enterprise is the organizational workflow around that toolkit: it picks up requested work and runs scheduled maintenance, returning proposed changes to your team’s review process.

Monitoring and action.
How do these responsibilities fit together? 
How much of the recurring engineering work can be delivered by an agent that has all the right context and tools?
Let’s explore these topics.

What Monte Carlo brings to the stack

Monte Carlo gives a team context for understanding whether its data can be trusted: freshness, active alerts, lineage, and monitoring coverage. Lineage makes dependencies visible, helping an engineer understand how an upstream problem could affect downstream assets. Its troubleshooting agent investigates possible causes across data changes, failed jobs, and code changes. Monte Carlo’s troubleshooting documentation describes how it uses that context during an incident.

That capability matters, a lot. A stale table feeding a board report deserves different attention from a stale table nobody reads, and tracing those dependencies by hand is expensive.

Monte Carlo also brings this information into coding-agent workflows. Its Agent Toolkit exposes observability context and supports investigation, remediation, monitoring, and checks around code changes. There is real overlap with the work an analytics engineer does while maintaining a project.

For a team evaluating autonomous workflows, the distinction to examine is the job each product is organized around. Monte Carlo brings an observability platform and its incident context. Dex brings an analytics-engineering toolkit, with Enterprise organizing that work around the backlog and a maintenance schedule.

The engineering loop behind Dex

An agent can write convincing SQL with very little understanding of the data. It can join two columns with the same name without checking whether their values overlap. It can assume one row means one order when a backfill has just made that assumption false.

Dex gives the agent a way to establish those facts before it changes the project. The work follows three steps: Explore, Transform, Maintain.

Explore builds evidence about the warehouse: which tables matter, what one row represents, whether keys are unique, and which joins hold up when measured. 
Transform uses that evidence to produce changes to model SQL, tests, documentation, and the semantic layer. These are the definitions that specify how business metrics are calculated. 
Maintain compares the warehouse and project with an accepted baseline and proposes work to reconcile the differences.

The definitions remain in your repository. The open-source engine provides the checks, evidence, and reviewable diffs around the agent’s reasoning and writing.

With open-source Dex, an engineer drives that loop through a coding agent. With Dex Enterprise, the workflow can begin from a ticket or a scheduled run. The team can delegate the investigation and implementation, then review the resulting change with its evidence attached.

What a scheduled maintenance run should bring back

Imagine a nightly check finds two changes. An upstream source has dropped a column that several staging models still reference. A daily orders table has also lost uniqueness on the combination of date and store: what used to be one row per store per day is now several.

Both need attention. They require different decisions.

For the dropped column, the workflow can examine the affected models and their dependencies, then prepare a reconciling change where the intended repair is supported by the project. The reviewer gets the SQL changes, the relevant tests and documentation, and the validation result. If the missing column carried a business rule whose replacement is unclear, that uncertainty belongs in the review.

The broken key needs more interpretation. Perhaps a batch loaded twice. Perhaps the source now distinguishes stores by channel. Removing duplicates might hide a source defect; adding channel to the key might change what every downstream metric counts. A successful build cannot decide which interpretation the business intended.

Dex distinguishes mechanical reconciliation from findings that need an owner’s decision. The useful output for the second finding is an advisory: what stopped holding, what depends on it, and what somebody needs to decide. Once that decision is explicit, the implementation has something reliable to follow.

This is the shape of scheduled drift detection and resolution worth asking for: a proposed repair where the evidence supports one, and a well-posed decision where it does not.

The engine checks four kinds of drift: schema changes, volume changes, changes to keys and row grain, and semantic-definition changes. That last category matters because a pipeline can keep running while the definitions in the project move out of alignment. A changed metric expression or broken reference is something a tool can detect. What finance meant by a new revenue policy still needs to be supplied by a person.

The same workflow can move the backlog

Maintenance is only one source of analytics work. Someone also needs a new revenue metric, a model for a new product, or an existing definition brought into line with an agreed business rule.

Dex Enterprise takes that requested work, grounds it in the current warehouse and dbt project, and authors the model SQL, tests, documentation, or semantic definitions it needs. Validation runs against a development target. The draft pull request stays tied to the original request, so the reviewer can assess both the implementation and whether it answers the ask.

That is why Dex and Monte Carlo make sense in the same modern data stack. Observability gives a team visibility into the health of what it operates. Analytics engineering builds and maintains the transformations and definitions on which that operation depends. Agentic capabilities can help in both places, and a data leader has reason to invest in both.

Autonomy the team can actually use

The practical unit of delegated work is a change someone can assess: what prompted it, what the agent established, which files changed, and what validation passed or failed.

Dex Enterprise runs in your organization’s CI environment, using the identities, warehouse permissions, and inference services you control. No Exmergo service sits in the workflow’s execution path, and Exmergo does not receive customer data-plane content. Your chosen inference provider remains part of your organization’s data-handling decisions.

The workflow prepares draft pull requests. It does not approve or merge them. Your team configures the scope of unattended work, while repository review rules remain authoritative. A run that cannot validate its work must make that visible; a draft with a failed development build is still unfinished work.

For a manager, that offers a concrete way to evaluate autonomy. Pick a bounded part of the project with recurring maintenance. Watch whether reviewers receive useful evidence, whether repeat findings stay quiet, and how much investigation remains before a proposed repair can be accepted. Measure the engineering time recovered and the quality of the decisions that reach the team.

Open-source Dex is available today. Dex Enterprise is in early access with design partners and is not generally available. If scheduled drift work keeps displacing your team’s roadmap, explore the Dex Enterprise design-partner program. The conversation starts with your maintenance workload, your repository’s review process, and where an unattended run should stop for a decision.