Autonomy Levels For Data Agents: From Copilot To Fully Autonomous
A five-level scale for deciding how much a data agent may do without asking
Autonomy levels for data agents describe how much an agent may do before a human has to approve it, and we find five levels cover the real range: suggest, draft, act with approval, act and report, and act on its own. The idea is borrowed from the driving-automation scale in SAE J3016, which defines six levels of driving automation. It is useful for data teams because the question is never "should the agent be autonomous" but "autonomous at what, with what blast radius." The scale below is our own framing, not an industry standard.
Key Takeaways
- •Autonomy is a per-domain dial, not a platform-wide switch: an agent can be fully autonomous on freshness checks and read-only on PII policy at the same time.
- •The right level is set by blast radius and reversibility, not by how capable the model is.
- •Most teams today sit at level 1 or 2 (copilot) because their tools only suggest; the gap to level 3 is mostly approvals, audit trails and rollback, not model quality.
- •Read-only is a legitimate level. Our open-source edition (dw-claw) runs locally and is read-only by default for that reason.
- •Moving up a level should be earned with evidence from the level below, such as a track record of approved proposals that were never edited.
Autonomy levels for data agents: the five-level scale
We use five levels. Each is defined by who holds the pen when something changes in the data platform.
| Level | Name | What the agent does | What the human does |
|---|---|---|---|
| 0 | Manual | Nothing. Engineers use scripts and dashboards. | Everything. |
| 1 | Suggest | Answers questions and explains findings, read-only. | Decides and executes every change. |
| 2 | Draft | Produces a ready change: a SQL diff, a migration, a policy. | Reviews, edits and applies it. |
| 3 | Act with approval | Applies the change after an explicit approval, with audit trail and rollback. | Approves or rejects each action. |
| 4 | Act and report | Applies pre-agreed classes of change on its own and reports afterward. | Reviews reports, handles exceptions. |
| 5 | Autonomous | Detects, diagnoses, fixes and verifies end to end. | Sets policy and reviews outcomes periodically. |
Levels 1 and 2 are what most people mean by a copilot. A chat window in an editor that explains a failing dbt model is level 1. One that rewrites the model and opens a pull request is level 2. The jump to level 3 is where the work changes character: the agent now holds write credentials, so approvals, audit logs and rollback stop being optional.
What each level looks like in a real data team
Take a single incident: the nightly pipeline is three times slower this week, and a downstream dashboard is stale. Here is how the same incident plays out at each level.
- •Level 1: an engineer asks an agent in Claude Code or Cursor "why is the nightly pipeline 3x slower this week?" The agent traces the query history and names the culprit, perhaps a join that lost its partition filter. The engineer fixes it.
- •Level 2: the agent also writes the corrected model and a test, and the engineer reviews the diff.
- •Level 3: the agent opens the change, waits for an approver, deploys it, and records who approved what and when.
- •Level 4: for a defined class of fix, such as retrying a transient warehouse failure or re-running a backfill, the agent acts and posts a summary.
- •Level 5: the agent diagnoses the root cause, maps the downstream blast radius, ships the fix and verifies freshness, and a human only sees the report.
The expensive part of an incident is rarely detection. It is the stretch between "something is wrong" and "it's fixed," which in our experience is hours of coordination across tools that do not share context. Autonomy levels are a way of deciding which pieces of that stretch an agent may own.
How to choose a level: blast radius and reversibility
We set the level per domain using two questions. How far does a wrong action spread, and how easily can it be undone? A retried job is local and reversible. Dropping a column, changing a masking policy or granting access to PII columns is neither.
| Domain | Typical ceiling | Why |
|---|---|---|
| Freshness and quality monitoring | Level 5 | Read-heavy, easily reversed, high alert volume. |
| Pipeline retries and backfills | Level 4 | Bounded and idempotent when designed well. |
| Schema migrations | Level 3 | Downstream consumers can break; approval pays for itself. |
| Cost optimization (warehouse sizing) | Level 3 to 4 | Reversible, but changes can affect latency SLAs. |
| Access and PII policy | Level 2 to 3 | Security and compliance consequences; humans keep the pen. |
These ceilings are our opinion and your risk tolerance may differ. The point is that they differ by domain, which is why a single global "autonomy" toggle on a platform is the wrong abstraction.
What has to exist before you move above level 2
Capability is not the gating factor. Four controls are, and they are the same ones security teams ask for in any system that holds write access.
- •Scoped credentials: the agent gets the narrowest role that does the job, per connector.
- •Approval workflows: a recorded decision for each level 3 action.
- •Tamper-evident audit trails: every tool call, input and result is logged and attributable.
- •Rollback: a tested way to undo the change, whether a migration revert or a restored policy.
The Model Context Protocol gives agents a standard way to call tools, but it deliberately leaves authorization policy to the host and server. That is why autonomy has to be enforced in the platform and not assumed from the protocol.
Where Data Workers fits, and where it does not
Data Workers is fifteen MCP-native agents that run the data platform together, and our Autonomous Data Conductor exposes the autonomy dial per domain. The open-source edition (dw-claw, Apache 2.0) runs locally and is read-only by default, which is level 1 and 2 territory. Pro adds writes, enterprise connectors, approval workflows and audit trails, which is what level 3 needs. Enterprise adds SSO/SAML, tenant isolation and VPC or on-prem deployment for teams that need those controls around the higher levels.
Our Incidents Agent diagnoses root cause across lineage, logs and queries, our Schema Agent maps blast radius before a column change, and our Pipeline Agent deploys the fix. Because they share context, a schema change that broke a pipeline and violated a governance policy is visible to all three at once. In early pilot testing, 60% of incidents auto-resolved before a human was notified; that is our pilot data, not an industry benchmark, and it depends on the autonomy level each customer chose.
Where we do not fit: if your team only needs level 1 answers inside an editor, a single-purpose assistant is simpler. And we do not recommend level 5 for access policy or anything touching regulated data until you have a long record at level 3. We covered how the Governance Agent handles PII detection and RBAC policy generation in a separate post.
Because every agent is an MCP server, you invoke them from Claude Code, Cursor, Windsurf, VS Code or any MCP-compatible client. There is no new dashboard to adopt; the autonomy level is a setting on the agent, not a different product.
How to move a domain up a level
- •Run the domain at its current level for a fixed window and log every proposal.
- •Measure how many proposals were approved without edits. If most were edited or rejected, stay put.
- •Write the class of action you are about to delegate in one sentence, with its rollback.
- •Raise the level for that class only, keep everything else where it is.
- •Review the first two weeks of reports daily, then weekly.
This is deliberately boring. The teams we expect to get value from autonomy are the ones who treat it like any production change: scoped, observable and reversible.
Frequently Asked Questions
What is the difference between a copilot and an autonomous data agent? A copilot suggests or drafts and a human applies the change (levels 1 and 2). An autonomous agent applies changes itself, either with approval (level 3) or within pre-agreed limits (levels 4 and 5). The difference is who holds write access and who is accountable for the action.
Which level should a data team start at? Start read-only at level 1 and 2 for every domain. It costs almost nothing in risk, and it generates the proposal history you need to justify moving up. Open-source dw-claw is read-only by default for this reason.
Can different data domains run at different autonomy levels? Yes, and they should. Freshness monitoring can sit at level 5 while access policy stays at level 2 or 3. Setting a single platform-wide level forces you to pick the most cautious domain for everything.
Do autonomous data agents need human approval? Not always, but they need a defined approval model. Level 3 requires a recorded approval per action, while levels 4 and 5 replace per-action approval with pre-agreed policy, audit trails and rollback.
Does an agent's autonomy level depend on which model it uses? Not mainly. A more capable model can make better proposals, but the level should be set by blast radius, reversibility and the controls around the agent.