How to Automate Your Entire Data Operations as a Large Enterprise

You automate data operations at enterprise scale by giving agents the back office one domain at a time, on an autonomy level your team sets per domain, with every change approved or reversible and recorded on a receipt. Data Workers is the agentic data platform built for exactly that: an autonomous Data-Conductor that runs the work, a swarm of specialist agents that do it, one context graph across every platform, and a catalog where people review, approve and roll back.

This guide covers what to automate, in what order, the guardrails that make it safe to let agents write to production, and the plan for the first quarter.

Picture the estate first. A large enterprise runs Snowflake and Databricks side by side, BigQuery in one business unit, dbt in most teams, Airflow and a managed ingestion tool, two BI tools, a catalog and a data observability product. Forty data teams sit on top. The work that keeps it all running is the back office: classifying and tagging data, answering access requests, keeping pipelines green, chasing schema changes, documenting tables, keeping spend down, and producing evidence for auditors. Every one of those jobs is done by a person today, ticket by ticket, across tools that each own one slice.

Key takeaways

• •Automate the back office, by domain. Governance, compliance, pipeline management, catalog and metadata, quality and cost are the jobs that never end. They are where agents return the most time.
• •Set autonomy per domain, from L0 to L4. L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous. Catalog upkeep can run at L3 while access stays at L2, in the same estate.
• •Start every domain at L1 observe. The Conductor ships observe-only: the agents read your estate and show you the work they would take, and change nothing on their own until your team raises a level.
• •No agent can promote its own work, and anything irreversible needs a named person's approval. Deletes, access grants and anything that raises spend go to a person at every level.
• •Every change leaves a receipt. Who or what acted, why, what it touched, the before and after, the approver and how to undo it, on a hash-chained audit trail.
• •Long jobs run as Conductor goals. "Check every pull request in the marketing estate for personal-data columns" becomes a governed loop: the privacy check reads column names and annotations, the team's classification tool stays the record, and tag and masking changes arrive as proposals, with a daily budget, a breaker for runaways and a receipt per change.
• •Zero migration. Data Workers works on top of the warehouses, orchestrators, catalogs and BI tools you already run.

What "data operations" means at enterprise scale

Data operations is everything that has to happen after a pipeline is built for the data to stay correct, safe, documented and affordable. We group it into ten domains, the same lifecycle stages we use across our platform guides:

• •Catalog and context: descriptions, owners, glossary terms, lineage.
• •Data quality: tests, contracts, anomaly triage, root cause.
• •Observability and incidents: detection, diagnosis, the fix, the postmortem.
• •Pipelines and ingestion: failed runs, reruns, backfills, freshness.
• •Schema and migration: upstream changes, downstream breakage, planned moves.
• •Governance and access: access requests, reviews, revocations, policy.
• •Security and privacy: PII classification, masking, retention, right to be forgotten.
• •Cost and FinOps: idle warehouses, oversized compute, runaway queries.
• •MLOps and models: feature freshness, training data health.
• •Analytics and insights: the metrics people read, and whether they are right.

In a large enterprise each domain has an owner, a queue and a backlog. Automating data operations means each owner can hand their queue to agents at the level they trust, and see exactly what the agents did.

Why your current tools don't do this themselves

Your warehouse, your observability product and your catalog are each excellent at their job. Most were designed read-only or human-confirmed on purpose, and that is the right design for a product that owns one slice: it can see a problem in its own system, and it should not be liable for changes in systems it doesn't own.

Writing to production across systems is a different product category. It needs blast-radius scoping over lineage that spans every platform, an approval flow that knows who owns what, rollback that works across tools, receipts an auditor will accept, and context about every other system the change touches. AWS's reference architecture for agentic data operations makes the same call: it calls itself "a build-time accelerator, not a runtime dependency", where agents generate code and controls, engineers review them, and CI/CD promotes them to production (AWS, Aug 2026). That is a sensible place to stop for a build-time tool. Data Workers is the product that keeps going after the build: it runs the operations, under your rules.

The model: autonomy per domain, L0 to L4

The unit is a domain. Finance's catalog domain can run at L3 while Risk's access domain stays at L2. Your team sets each level and can lower it at any time.

• •L0 manual. Agents stay out. People do the work.
• •L1 observe. Agents read, detect and diagnose, and show the fix they would make. Read-only.
• •L2 propose. Agents prepare the change with a dry run, blast radius and undo path. A named person approves, edits or rejects it. Nothing runs until they do.
• •L3 act reversibly. Agents apply changes that can be undone, verify them against your checks and leave a receipt. Anything that can't be undone is still proposed.
• •L4 autonomous. Agents close the loop end to end in the domain, including multi-step and multi-system work and long-running goals. Irreversible actions still go to a named person.

The dial goes to fully autonomous, and each domain climbs as fast as its receipts allow. The goal is that every domain sits at the highest level its evidence supports.

The guardrails that make it safe to let agents write

Leaders ask one question before anything else: what can the agents do without us? These are the answers, and they hold at every level.

• •Governed writes. Agents act through the roles you grant them, scoped to your tenant from a trusted sign-in claim, and enterprise workspaces carry a tool allowlist whose denials land in the audit trail.
• •No agent can promote its own work. The guard sits in the write path and accepts only a named human approver for anything that becomes authoritative. A goal the Conductor proposes itself needs a named person to accept it, and accepting it never widens the autonomy ceiling. Approval requests go to a named person; an unanswered one expires and escalates, never auto-grants.
• •Anything irreversible needs a named person's approval. Deletes, access grants and anything that raises spend go to a person at every level. Spend increases always ask, whatever budget is left.
• •Blast radius before action. For a data change the agent maps what it touches across lineage, column by column, down to the dashboards, and the proposal carries that map.
• •Rollback recorded before the write. Each fix records its undo path before it runs. A fix that fails its post-checks is escalated to the owner, never marked resolved. Tags and descriptions the agents write can be reverted to any earlier version.
• •A receipt on every change. The audit trail is hash-chained, so an auditor can check that no entry was altered or removed.
• •Stop. One org-wide stop halts all autonomous dispatch. A budget breaker drops a goal back to proposals when it hits its cap, and a runaway breaker pauses a routine until a person re-enables it.

Read more in is it safe to let AI agents change production data and how approvals work for AI data agents.

Step by step: from no automation to autonomous data operations

Step 1. Connect, with zero migration. Connect Data Workers to your warehouses, orchestrators, transformation layer, catalog and BI tools with scoped, read-first credentials, and check which connectors are live against your systems. The agents run in your infrastructure; the hosted Conductor sees workflow metadata only, never rows, credentials or model keys. Every domain starts at L1 observe.

Step 2. See what can be automated. At L1 the agents work through your estate and log what they found and what each action would have needed. Ask Spellbook in plain English what is waiting in your domain and you get the list: new columns the pull request privacy check flagged by name or annotation, recurring quality-check failures and their root causes, failed runs that are safe to rerun, Snowflake spend by dbt model, undocumented tables.

Step 3. Pick two or three domains to raise first. Choose high-volume work with clean undo. Catalog enrichment, PII flags in pull request review and reruns of idempotent failed tasks are the usual first picks. Cost starts with attribution: Snowflake spend traced to the dbt model, with cost-safe warehouse settings drafted for the owner to apply. Leave access and schema changes at L2.

Step 4. Run at L2 and read the receipts. Each proposal arrives with the change, a dry run, the blast radius and the undo path. Your domain owners approve, steer or send it back. The Conductor escalates exactly one decision for a multi-step fix, so an incident costs your on-call engineer a single approval.

Step 5. Move clean classes to L3. Your team reviews the agents' records and receipts against the bar it set: how many proposals were approved unchanged, how many were edited, how many changes were undone, whether any caused an incident. Most teams start narrow and widen it as the receipts pile up. A domain owner makes the move, and can lower it again at any time.

Step 6. Run long jobs as goals. Some work is too big for one run: propose tags and masking for the 40,000 columns your classification tool marks as personal data, document every table behind the finance pipelines, keep reruns flowing across hundreds of DAGs. The Conductor holds it as a goal with routines that work through it, a budget in spend, tokens and runs per day, and a receipt for every change. Hitting the budget drops the goal to proposals rather than stopping the work, and the goal can be driven by our harness or by the agent runtime you prefer, through the same governed tools.

Step 7. Earn L4 where the receipts support it. After a sustained run of clean receipts, a domain can go to L4: multi-step, multi-system fixes end to end, long-running goals, and new goals the Conductor proposes for a person to accept. Irreversible actions still go to a named person.

Step 8. Govern from one place. Spellbook, in preview, shows where the work is going, what is running now and what needs you, with the full trace behind every change. The audit trail exports by date, actor and action as CSV or JSONL, and model spend is tracked per action. That is the picture you take to the CDO.

What goes on autopilot

The role swap is the whole idea. Your warehouse stores and computes, dbt models, Airflow schedules, Looker shows the number and your catalog keeps the inventory. Data Workers runs the back office across all of them, with one context, one approval flow and one audit trail, instead of one more console per slice.

One worked example: PII flags across an estate

An illustrative example.

• •Monday 09:00. The Governance and Security domains are at L1. The data owners have recorded the 214 columns their classification tools mark as personal data as approved facts in the context graph. Lineage shows two of them feeding Looker Explores used across the company.
• •Monday 09:20. The domain owner raises Security to L2 for the marketing schemas. Every pull request that touches them now gets Data Workers' privacy check: the review reads new column names and annotations, never values, and flags the ones that look personal, with the downstream dbt models and dashboards attached.
• •Tuesday to Thursday. Review flags 9 new columns across 6 pull requests. The owner confirms 8 and dismisses one. Each confirmed column's tag and masking change goes to the platform owner as a proposal with a receipt and a rollback path.
• •Following week. The records support L3 for posting flags in that scope, and the owner raises it, so flags post on every pull request without a person queuing them. Tags and masking stay proposals the owner applies.
• •Same week. The agents flag the two exposed fields to the Looker owner with a proposal to narrow access. That is an access change, so it waits for a named approver, at any level.

The owner spent their time on two edits and two decisions. The receipts are the audit evidence.

What changes for your organization

Domain owners become the people who set levels and make the decisions agents escalate. On-call engineers review receipts and approve the hard cases. Platform leads set goals and budgets for long-running work. Auditors read receipts. New hires inherit a catalog that stays current.

What to measure

• •Share of work handled by agents, per domain, and the level it ran at.
• •Time from detection to a verified fix, at L2 against L3.
• •Approved-unchanged rate on proposals, the main signal for moving up.
• •Reversal rate on applied changes, the main signal for moving down.
• •Caused incidents, which should stay at zero.
• •Receipt completeness, which should be 100%.
• •Model and warehouse spend, measured, with savings labelled as measured or estimated.

The ROI of agentic data operations piece and the ROI calculator show how to size it for your estate. Our design targets for cost reduction are 25 to 40% of addressable warehouse spend; your receipts show what you actually get.

What stays the same

Your warehouses, lakehouses, orchestrators, dbt projects, catalog and BI tools stay where they are. Your change process stays in charge of anything irreversible. Your engineers keep using the coding agents they like; connected over MCP, those agents call the same governed tools and leave the same audit trail. You can lower any level or stop every agent at any time.

Build it yourself, or use a platform

Teams with strong engineers ask whether they can wire this together with a coding agent and a few MCP servers. The agent part is the easy part. The work is the guardrails every write passes through, the approvals tied to real identities, rollback across systems, receipts an auditor accepts, blast radius over lineage that spans every platform, and the evidence that tells you when a domain is ready for more. That is the product. See build it ourselves with Claude Code and MCP servers for the longer answer.

How the platform fits together

The Autonomous Data-Conductor runs the detect, diagnose, fix, review and verify loop and the long-running goals. The Data-Agents Swarm is the twenty specialist agents that do the domain work. Data Context Wizard gives every agent one governed context graph across Snowflake, Databricks, BigQuery and the rest. Spellbook Data Catalog, in preview, is where people see the autonomy map, approve, undo and read receipts; Approval requests also reach the team in Slack or email. The autonomy levels explained post covers the ladder in more depth, and our platform playbooks show the climb on Snowflake, Databricks and AWS.

FAQ

Can agents really be trusted to write to production data? At the level you set, in the domain you choose, with the guardrails above. Start at L1, read what the agents would have done, and raise a level only when the evidence supports it.

What happens if an agent makes a bad change? Every fix records its undo path before it runs, and a fix that fails its post-checks is escalated to the owner, never marked resolved. Your team can lower the domain's level at any time. Irreversible changes never run without a named person.

Who can raise a domain's autonomy level? Your team, never the agents. The Conductor can propose a new goal, but a named person has to accept it, and accepting it never widens the autonomy ceiling. Your team can lower a level or use the org-wide stop at any time.

Do we have to move data or replace our catalog? No. Data Workers connects to what you run. The catalog you have stays the inventory; Spellbook is the control plane on top.

How do long-running jobs across hundreds of pipelines work? As Conductor goals: routines that work through the job, a daily budget in spend, tokens and runs, a breaker that pauses a runaway, and a receipt for every change. Hitting the budget drops the goal to proposals.

What does an auditor see? A hash-chained audit trail for every change, exportable by date, actor and action as CSV or JSONL, with the actor, what it touched, the outcome, the approver and the undo path.

Which domain should we automate first? The one with the most repetitive, reversible work. For most enterprises that is catalog enrichment and PII flags in pull request review, followed by pipeline reruns and cost attribution.

The case for your CFO

The outcome in business terms: the data back office (classification, access requests, failed runs, documentation, spend attribution, audit evidence) stops growing with headcount. Your engineers spend their time on decisions and design, and the agents take the queues.

The risk story is short. At L1 the agents only read and report. At L2 a named person approves every change before it runs. At L3 the agents act only on changes that can be undone, and each fix records its undo path first. Deletes, access grants and anything that raises spend go to a person at every level. Every change leaves a receipt on a hash-chained audit trail: who or what acted, why, what it touched, the approver and how to undo it. Nothing migrates: your warehouses, dbt, orchestrators, BI and catalog stay where they are, and your data stays in your systems.

Why now: the agents your teams already use can write to production, and the question is no longer whether agents touch your data but under whose rules. Data Workers gives you those rules, per domain, in one place.

The first win is a domain that runs itself at L2 or L3 within the first quarter, usually catalog enrichment or PII flags in pull request review, with receipts your auditors can read.

Start with a pilot on one or two domains in your own estate. You'll see the work the agents found, the decisions they brought to your owners, and real receipts from your systems. Details are on pricing; the pilot is credited in full against the first year.

The sentence for your CFO: we are handing the data back office to agents one domain at a time, at levels our owners control, with every change approved or reversible and recorded.

Sources

• •AWS Artificial Intelligence Blog, "Agentic Data Operations Platform (ADOP): Data engineering into hours", Aug 21, 2026. https://aws.amazon.com/blogs/machine-learning/agentic-data-operations-platform-adop-data-engineering-into-hours/ (checked Oct 2, 2026)
• •Data Workers product pages: /product/autonomous-data-conductor/, /product/spellbook-data-catalog/, /pricing/ (checked Oct 2, 2026). Product behaviour checked against the Data Workers agent swarm repository, main @ 0c2491e3 (Oct 2, 2026).