Data trust used to come after the fact. With Claude, it ships with your code.

Data teams have always wanted quality and reliability to be a built-in property of how data gets produced and consumed — not a separate chore bolted on after the fact. The whole point of data observability has been to shrink data downtime — the periods when data is wrong, missing, or otherwise inaccurate — by catching problems close to where data is built and used.

It’s why we built monitors as code: so monitoring becomes a natural part of the data engineering workflow which, as we put it back in 2021, “consists of writing code, tests, and now, monitors.” A developer defines monitoring for a new table right alongside the model that creates it and deploys it through CI — version-controlled, reviewed, and consistent. On the consumption side, we’ve heard the same instinct for years: teams want quality signals to surface inside the tools where data is actually used. That’s why we built integrations with catalogs like Atlan to carry trust signals to the point of consumption.

Now Claude and other AI agents are in both halves of that workflow — writing SQL, building pipelines, and modifying schemas on one side; answering business questions on the other. That’s a fresh opportunity to rethink where reliability lives, and to make it a default behavior of the agents themselves rather than something a human has to remember.

Two shifts make this urgent. First, agents are fast and capable but have none of the operational instincts a senior engineer builds over years of production incidents — and as Barr argued in When Agents Manage Agents, Blame Disappears, they don’t feel accountable, and they don’t stick around to make sure what they built keeps working. Designing for “human-centric accountability” means every agent’s output stays observable and owned. Second, as data increasingly feeds AI, quality has to move upstream — bad data anywhere multiplies across every agent that touches it.

In our last post, Claude and Cursor Can’t Do Data Right, we looked at the consumption side: why agents answering business questions need trust signals before handing a confident answer to a stakeholder. This post is about the development workflow — shipping data products that are correct at release and stay reliable long after the developer has moved on.

Step 1: Ship it correct — validate before release

The first step in releasing trusted data is making sure it’s correct and validated before it goes out. That’s harder with agents in the loop, because an agent will happily build a transformation on top of a stale table or push a schema change that silently breaks a dozen downstream dashboards — it doesn’t know to check.

That’s why we built the Prevent skill in the Monte Carlo Agent Toolkit. Installing the toolkit takes less than two minutes and when installed, Prevent uses editor hooks to enforce a safety-first loop as the developer (and their agent) work:

• Before an edit, it surfaces downstream blast radius, active alerts, monitor coverage, and a risk-tiered recommendation for the model being changed — so the agent knows what it’s about to affect before it writes a line.
• After the edit, it offers to generate monitors-as-code for any new transformation logic.
• Before the commit, it checks for unresolved monitor-coverage gaps.
• To validate, it generates targeted SQL checks confirming the change behaved as intended before merge.

The net effect: changes ship with their impact understood and their correctness checked, instead of relying on the developer to remember to do both.

Step 2: Keep it healthy after you’ve moved on

The second step is the one teams skip most often — and it matters more. A pipeline that’s correct on release day is not the same as one that stays correct three months later, after the developer has moved to four other projects and stopped watching it. This is exactly where data downtime quietly creeps back in. Agentic development is what finally makes “set it up so it keeps working” a routine, low-effort part of every change.

The highest-leverage move isn’t assembling a pile of skills — it’s treating agentic development as a system. Here’s the shape of what we built for our own engineering org, and what we’d suggest for yours.

1. Teach agents how to develop in your environment

Encode how your team actually builds into a shared library of skills, rules, and guardrails that every agent picks up automatically. A few patterns that have paid off for us:

• A structured workflow, not a loose pile of skills. Our engineers move through a consistent sequence — plan → review the plan → implement → ship → review → capture learnings — with specialized agents at each gate. The value is catching issues at the cheapest possible moment: a modelling or compliance gap caught at planning time is far cheaper than the same gap caught at PR time or in production.
• A shared, centrally-managed set of standards. A common rules file — think a managed block that lands in every engineer’s agent config and auto-updates — carries coding standards, architectural guidance, and safety rules (e.g. never commit without approval, never bypass a blocked operation). Agents then behave consistently across engineers and repos without per-repo duplication; personal preferences layer on top.
• A safety guardrail for tool use. A pre-tool-use hook that lets the routine ~80% of operations through silently while blocking or escalating the risky ones keeps agents fast without giving up safety — you avoid both constant permission prompts and a no-guardrails free-for-all.
• Specialized, per-repo review agents. Rather than one generic reviewer juggling security, testing, architecture, and docs all at once, give each concern its own focused agent — and let each team add domain-specific reviewers that know its data model, SLAs, and conventions. Focused scope plus repo-specific knowledge is where the real leverage is, and it’s the hook we use for the monitoring step below.

Topics worth covering: repo and project conventions, local dev and test data, testing standards, deployment and CI/CD, code-review standards, and observability expectations (including the monitoring bar in #3). None of this is Monte Carlo–specific — it’s the substrate that makes the monitoring step automatic rather than aspirational.

2. Make it shared, contributed-to, and self-improving

A skills library only compounds if it’s the real source of truth. Make using it the default and contributing to it part of the job. The piece that’s easiest to miss is a learnings loop: when an agent gets something wrong and an engineer corrects it, that correction should be routed back into the shared skills or rules — not lost to a one-off chat or buried in one person’s local memory. Treat skills like code: reviewed, versioned, owned, and auto-updated so every engineer inherits the latest on their next session. That’s what turns one-off agent productivity into a flywheel where best practices compound across the whole team instead of resetting every session.

3. Make monitoring coverage a required step in every agentic code review

This is where reliability stops being optional. Add a skill — ideally one of the per-repo review agents from #1 — that ensures any new or materially changed table, pipeline, or data product ships with solid monitoring, and run it on every agentic code review the same way you’d run a security or testing reviewer. Codify the Agent Toolkit to do the work: assess coverage and blast radius with the Prevent and monitoring skills (backed by the Monte Carlo MCP server), validate fields and tables against your live workspace, and emit deployable monitors-as-code YAML.

A starting template you can drop into your skills repo as a reviewer agent:

---
name: enforce-data-monitoring
description: >
  Reviewer agent. Ensures every new or materially changed table, pipeline,
  or data product has appropriate Monte Carlo monitoring before a PR is
  approved. Runs on every agentic code review, alongside the security and
  testing reviewers.
---

# Enforce Data Monitoring

## When to use
On any pull request that adds or modifies a model, transformation, or
pipeline that materializes data. Part of the standard review pass, not an
afterthought.

## Steps
1. Identify affected assets. List tables / data products added or materially
   changed in this PR (new materializations, changed grain, changed business
   logic, schema changes).

2. Check existing coverage. For each asset, use the Monte Carlo Agent Toolkit
   (the `prevent` and `monitoring-advisor` skills, via the MCP server) to
   assess current monitor coverage, downstream blast radius, and active alerts.

3. Define the required bar. Every new materialized table must have, at minimum:
     - Freshness + volume monitoring
     - Schema-change detection
     - At least one validation/quality check on a business-critical field
   Data products and key assets additionally need monitoring aligned to their
   SLAs.

4. Generate what's missing. Where coverage is below the bar, have
   `monitoring-advisor` generate monitors-as-code YAML — validated against the
   live workspace so it references only real tables and fields — and write it
   to `monitors/` alongside the changed model so it deploys through CI.

5. Gate the review. If a required asset still lacks coverage after step 4,
   leave a blocking review comment summarizing the gap and the suggested
   monitors. Do not approve until coverage meets the bar or an owner
   explicitly waives it with a reason.

## Notes
- Monitors are version-controlled and deploy via existing CI/CD — no
  click-ops in the UI.
- Fix coverage in the same PR that introduces the asset, so reliability ships
  *with* the change rather than as a follow-up that never happens.

Because the monitors are generated as code and deploy through your existing CI/CD, coverage lands in the same PR as the asset that created it — and the thing most likely to be skipped becomes automatic.

The compounding payoff

Put these together and reliability stops being a separate workstream. Prevent keeps bad changes from shipping. A shared, self-improving skills system makes every agent build the way your best engineers do. And an enforced monitoring step means nothing reaches production without the coverage to keep it healthy after attention has moved on. The operational instincts that used to live only in senior engineers’ heads become encoded, shared, and applied on every change — by humans and agents alike. That’s what human-centric accountability looks like when agents are doing the building.

Get started: Agent Toolkit docs · MC Prevent · Monitors as Code · GitHub: mc-agent-toolkit

Our promise: we will show you the product.