Who owns the agents?

Your data team owns them, the same way it owns pipelines: each domain has a named owner who sets its autonomy level from L0 manual to L4 autonomous, approves its changes at L2, reviews the receipts, and can pause or roll back at any time. Platform and security teams own access grants and policy, data stewards own definitions, and leadership sees the outcomes.

Data Workers, the agentic data platform, is built around that split. The agents do the operational work; every decision about how far they go, and every sign-off that makes a change official, belongs to a person you already know by name.

Key takeaways

• •Ownership follows your domains. Revenue, marketing, product and finance data each get a named owner, the same person who already answers for that data today. The agents in that domain answer to them.
• •The owner holds the dial. Each domain runs at the level its owner sets, L0 manual, L1 observe, L2 propose, L3 act reversibly or L4 autonomous, and the owner can lower it or pause the domain at any time.
• •No agent approves its own work. Approvals route to a named person; agents can't approve their own changes, promote their own drafts to authoritative, or raise their own autonomy. Changes that spend money always wait for a person.
• •Security keeps the keys. Platform and security own access grants, policy and the identity provider, and hold an org-wide stop for every agent.
• •Everything leaves a receipt. Who asked, what changed, what was checked, who approved and how to undo it, in a tamper-evident audit trail that leadership and auditors can read.

Ownership works the way it already works for pipelines

Most data teams already run on domain ownership. Someone owns the revenue models, someone owns the marketing attribution tables, someone owns the customer dimension. When a pipeline breaks, everyone knows whose phone rings. Data Workers keeps that map and puts the agents inside it.

Domain owners are the center of the model. On the Autonomous Data-Conductor, autonomy opens "domain by domain: which agents can write, how far a change may spread, what still comes to a human." The owner of each domain makes that call, approves what comes to a human, reads the receipts and decides when the domain moves up a level.

Data engineers on call review what the agents propose. A fix arrives as a diff for the owner to merge, with the root cause, the blast radius and a rollback plan attached, and the engineer approves it, steers it or sends it back.

Platform and security teams own access. People sign in through your own identity provider (Okta, Entra or similar), and Data Workers verifies those tokens; it issues none of its own. Grants follow your policy: the provision_access tool applies least privilege and column-level permissions with a 90-day expiry by default, and check_policy evaluates a request against your rules before anyone signs. Unity Catalog, Snowflake roles and your other permission systems stay the source of truth, by design.

Data stewards own meaning. Agents can draft a metric definition or an asset description, and it lands as a derived fact. Promoting it to authoritative (the mark_authoritative tool) needs a named human, and the product rejects an agent or a self-approval at that step. As the Spellbook Data Catalog page puts it: "Nothing becomes official without a signature."

Leadership sees outcomes across domains: what closed, what was escalated, what was rolled back, and where autonomy should rise next. generate_audit_report assembles the record for a quarter or an auditor.

Who decides what

The chart below is a RACI-style starting split. Each domain can adjust it, and most teams keep it close to this.

Three rules hold regardless of how a team adjusts the split.

Agents propose and execute; people decide. Every human gate in the product (goal approvals in the Conductor, promotions to authoritative, review sign-off on high-risk findings, workspace allowlist changes) rejects an agent id or a self-approver, and an authority guard in the write path stops any agent from promoting its own work to authoritative or canonical.

Money is never autonomous. Teams set every change that spends money to approve-to-act, and Data Workers holds that floor at every autonomy level and in every mode: the Conductor stamps it on every run it plans, and with the permission ladder enforcing, no setting lifts it.

Tightening is always allowed; widening is always recorded. Anyone with the right role can lower a domain's level or pause it. Raising it is a deliberate act by the owner, logged with their identity.

The controls each owner holds

The dial. At L0 manual, people do the work and agents stay out. At L1 observe, agents watch, trace and explain. At L2 propose, agents prepare the change and a named person approves it. At L3 act reversibly, agents apply changes that can be undone and report them. At L4 autonomous, agents close the loop end to end inside the guardrails the owner set. Conductor ships observe-only, and a new tenant starts with autonomy off until a named person turns it on at onboarding; with the permission ladder enforcing, every governed write in the meantime routes to approval. Our explainer on autonomy levels from L0 to L4 walks through each step.

Approval routing. An approval goes to a specific person, not an anonymous queue. Each request carries the proposed change, the blast radius (from blast_radius_analysis, column level and across engines), the checks that ran and the rollback plan. A request nobody answers expires and escalates; it never quietly auto-grants. Spellbook gathers them in one inbox where the owner can "approve it, steer it, send it back, or roll it back after the fact, with the full trace of what the agent saw and why it acted." Our page on how approvals work for AI data agents covers the routing in detail.

Pause and stop. Spellbook lets an owner "point the fleet, scope it, pause it anytime." The product has two levels of brake. A user-facing stop freezes the Conductor's autonomous work for a tenant without losing its history, and only a named person resumes it. An org-wide stop, held by platform and security, halts all autonomous dispatch at once, and an admin kill switch that takes two people revokes every API key, install token and active session for the tenant in one step. The system also pauses itself: if a routine's run rate jumps past twice its trailing average, it stops and waits, and if its heartbeat goes quiet, dispatch halts until a person looks.

Rollback. Every reversible change records how to undo it before it runs. Schema changes, pipeline deployments, data promotions and configuration changes can be reversed, and rollback_migration rolls back an applied schema migration, with a dry-run option to validate it first. See how to roll back an AI agent change.

Receipts. Every change leaves a receipt in a tamper-evident, hash-chained audit trail: who asked, what was touched, what was checked, who approved and how to undo it. Changes to autonomy itself are recorded with the identity of the person who made them. Spellbook (in preview) is where owners, stewards and leaders read them.

A week of ownership: an illustration

Here is one week in a revenue domain on Fivetran, Snowflake, dbt, Looker, Jira and Okta. It is an illustration, not a customer record or a measured result. The domain starts the week with schema fixes and freshness reruns at L2 propose.

Tuesday, schema. At 07:40 the billing source behind a Fivetran sync renames plan_tier to plan_code. By 07:44 Data Workers has caught it and mapped the blast radius: two dbt models and the ARR Explore in Looker. At 08:00 a dbt fix and a new test are proposed with a backfill and rollback plan, routed to the revenue domain owner. She approves at 09:10; the backfill runs in Snowflake, row counts and the Looker tiles are verified, and the receipt is filed.

Tuesday, access. At 11:00 an analyst asks in Jira for access to finance.arr_by_customer. By 11:02 the grant is drafted by policy: one role, PII columns masked, 30 days. Platform and security run the policy check and approve at 14:30 with the domain owner's sign-off. The analyst signs in through Okta as usual.

Wednesday, meaning. The agent updates the ARR definition to use the new field and saves it as a derived draft. The metrics steward reviews it that afternoon and signs; only then is it marked authoritative.

Thursday, rollback. Finance spots that a handful of legacy plans now map to the wrong tier. The owner rolls back the mapping change from the Spellbook inbox in one step. The new receipt links to the original, so the record shows both the change and its reversal.

Friday, the dial. The head of data reads the week's receipts with the owner. Schema fixes stay at L2, because Thursday showed they still deserve a human eye. Freshness reruns, which were right every time, move to L3 for this domain. That is how autonomy grows: one domain at a time, on the record.

How ownership works with other agents

Every option below is a sensible design for the job it was built to do. The difference is who the agent answers to.

Platform-native agents. Databricks Genie Code runs in a user's chat under that user's Unity Catalog permissions, with approval modes from "Ask every time" to "Auto-approve," where an AI classifier blocks actions that go beyond the user's request. Its documentation says the default for every chat on first use is Auto-approve, calls auto-approve "a productivity feature, not a security boundary," advises keeping it off "when working with production data," and says "You remain responsible for reviewing Genie Code's results" (checked Oct 2, 2026). Snowflake's CoCo CLI (formerly Cortex Code CLI), in its default Confirm mode, auto-approves read-only SQL, prompts for writes and for role or warehouse switches, and lets an organization enforce policy through a managed settings file (checked Oct 2, 2026). Both make the individual user the owner inside one platform. That is right for an assistant; running operations across every platform, with an owner per business domain, is a different product.

Coding agents. GitHub's Copilot cloud agent (formerly Copilot coding agent) can be triggered only by users with write access, pushes to its own branch, and "cannot approve or merge a pull request"; the person who asked for the pull request can't approve it either (checked Oct 2, 2026). Claude Code's permission modes run from Manual, which asks before edits, shell commands and network access, to auto mode, where a classifier reviews actions instead of the user; from v2.1.283, auto mode is the starting mode for interactive terminal and VS Code sessions, and an organization can turn it off. Teams and Enterprise plans add admin tools, SSO and server-managed settings, with role-based permissions on Enterprise (checked Oct 2, 2026). Ownership here is the repository's owners and reviewers, which fits code. Data Workers works alongside these agents over MCP; see Data Workers with your coding agents.

Build it yourself. A team can wire a coding agent to vendor MCP servers and write its own approval routing, per-domain levels, stop controls, rollback and receipts. That becomes a platform your engineers own on top of their day jobs. Our build-vs-buy page lays out that work.

For the full safety model behind every write, read is it safe to let AI agents change production data?. For where data lives and how identity works, read where does our data go?. Our resources on data steward vs data owner and human-in-the-loop approvals go deeper on the roles.

The case for your CFO

The outcome is speed without a new accountability problem. Data Workers takes the operational load (incident triage, schema fixes, backfills, access requests, definition upkeep) while accountability stays exactly where it sits today: with the domain owners, the platform and security team, the stewards and the head of data.

The risk story is the ownership model itself. Agents act only at the level each domain's owner sets. Approvals go to named people, no agent approves its own work, money always waits for a person, reversible changes carry a rollback, and every change leaves a receipt with who asked, what changed, what was checked and how to undo it. Security can stop every agent at once. Nothing is migrated; Snowflake, dbt, Looker and your permission systems stay as they are.

Why now: platform-native and coding agents are already in your teams' hands, each owned by whoever is running the chat. Putting operational agents under domain ownership before they spread gives the business one place to see what changed and who signed.

The first win is one domain, often incidents or freshness, at L2 propose, with an owner reading the receipts. Start with a pilot: $7,500 one-time, and the pilot is credited in full against the first year. Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing, model your numbers in the ROI calculator, and read the ROI of agentic data operations.

The sentence for upstairs: "Our data owners run the agents the way they run their pipelines, and every change has a name and a receipt on it."

FAQ

Who is accountable when an agent makes a bad change? The domain owner, exactly as for a bad pipeline change today. The receipt shows what the agent proposed, who approved it at what level, and how to undo it, so the fix is a rollback, not an investigation.

Can an agent raise its own autonomy level? No. Raising a domain's level is a decision by its owner, recorded with their identity. The system only ever tightens on its own, for example by pausing a routine whose run rate spikes.

Does this replace our RACI or data mesh ownership? It uses it. Data Workers maps agents onto the domains and owners you already have, and the starting split above adjusts per domain.

Who can stop everything at once? Platform and security hold an org-wide stop that halts every agent. Domain owners can pause their own domain, and a paused domain resumes only when a named person turns it back on.

Do the agents decide who gets access? No. They draft least-privilege, time-boxed grants by your policy. Platform and security own the grant and the policy, and the data owner signs off for their domain.

Will this replace people on the data team? No. It takes the repetitive operational load so the team spends its time on modeling, products and decisions. See will Data Workers replace my data team?.

Sources

• •Databricks, Genie Code agent mode, approval modes and auto-approve note: https://docs.databricks.com/aws/en/genie-code/agent-mode (checked Oct 2, 2026)
• •Snowflake, CoCo CLI security best practices, permission categories and managed settings: https://docs.snowflake.com/en/user-guide/cortex-code/security (checked Oct 2, 2026)
• •GitHub, Copilot cloud agent risks and mitigations: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations (checked Oct 2, 2026)
• •GitHub, About Copilot cloud agent (admin policy, repository opt-out): https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent (checked Oct 2, 2026)
• •Anthropic, Claude Code authentication and organization settings: https://code.claude.com/docs/en/iam (checked Oct 2, 2026)
• •Anthropic, Claude Code permission modes: https://code.claude.com/docs/en/permission-modes (checked Oct 2, 2026)
• •Data Workers, Autonomous Data-Conductor: https://dataworkers.io/product/autonomous-data-conductor/ (checked Oct 2, 2026)
• •Data Workers, Spellbook Data Catalog: https://dataworkers.io/product/spellbook-data-catalog/ (checked Oct 2, 2026)
• •Data Workers pricing: https://dataworkers.io/pricing/ (checked Oct 2, 2026)