One system writes SQL. Another invokes SQL and Python, observes errors, and replans. The second system has more tools, but tool count alone does not make it more autonomous. The real questions are: Who sets the goal? Who organizes the work? Who is authorized to act? Who verifies the result? Who recovers—and remains accountable—when it fails?
Data Agent levels are therefore best understood as a transfer of responsibility, not a feature checklist. At each level, the agent inherits more operations, judgment, and risk.
The L0–L5 framework comes from the 2026 paper Data Agents: Levels, State of the Art, and Open Problems and its companion Data Agent repository. The authors place most public research at L0–L2, describe emerging end-to-end orchestration systems as Proto-L3, and treat L4 and L5 largely as future directions. It is a lens for human–agent roles—not a vendor leaderboard or procurement certification.
Five kinds of authority determine the level
The same product may operate at different levels in different workflows. Evaluate it across five dimensions:
| Dimension | The question to ask |
|---|---|
| Initiation | Must a person request the task, or can the system discover a problem? |
| Planning | Does a person define the steps, or can the agent decompose, select tools, and replan? |
| Execution | Can it only suggest, execute read-only work, or trigger writes and external actions? |
| Verification | Who decides that the result is reliable enough and the task is complete? |
| Recovery and accountability | Who stops, rolls back, takes over, and explains a failure? |
A critical human-controlled dimension can cap the practical level. An agent may generate and execute SQL automatically, but if a person specifies every step and validates the conclusion, it remains closer to L2 than L3.
L0: the human is the sole operator
At L0, an analyst or engineer locates data, writes queries or code, inspects results, and chooses every next step. Databases, BI tools, and notebooks are instruments; they do not exercise judgment on the user’s behalf.
L0 is not synonymous with obsolete. Full human control can be an appropriate design for financial close, regulatory reporting, or high-impact production changes. Its weakness is that throughput depends on individual expertise, tacit knowledge is difficult to transfer, and the process is hard to scale.
Production gate: versioning, review, explicit metric definitions, and an operating record. Without that foundation, adding an agent merely automates an opaque manual process.
L1: the agent advises; the human closes the loop
An L1 agent is a reactive assistant. It drafts SQL, explains an error, suggests a chart, or summarizes a result. It does not independently perceive the full environment or own the executed outcome.
This level is often undervalued. For an expert, a dependable and editable draft can be more useful than a system that occasionally “finishes everything” behind an opaque interface. The product should clearly mark generated content, show changes, and preserve review before execution.
Production gate: editable output, traceable sources, no automatic execution of dangerous content, and visible uncertainty.
L2: the agent executes; the human orchestrates
L2 is the first major boundary. The agent can inspect its environment, invoke SQL, Python, retrieval, or visualization tools, observe results, and handle some expected failures. A person or predefined workflow still controls the major phases, the transition between them, and the stopping decision.
Moving from L1 to L2 is not simply “connecting more tools.” The agent now touches real data and compute. Permissions, sandboxes, timeouts, budgets, idempotency, execution logs, and result validation become requirements rather than enhancements.
Production gate: explicit tool contracts; separate read and write privileges; traceable executions; resource limits, stopping conditions, and human takeover; deterministic or human verification of consequential results.
L3: the agent orchestrates; the human supervises
At L3, a person supplies the objective, constraints, and authorization boundary. The agent decomposes the task, selects tools, executes, verifies, and adapts the plan. The human moves from workflow director to supervisor, intervening for high-risk actions, material uncertainty, or exceptions.
The hard part is not generating a longer plan. It is knowing when not to continue in a real environment. L3 requires durable state, composable skills, failure classification, independent validators, approval policy, and recovery paths. If a person still scripts the full completion path in advance, the result is sophisticated L2 automation.
Proto-L3 is the more defensible label for current systems that demonstrate autonomous orchestration in bounded tasks but still lack broad evidence for cross-domain generalization, long-horizon reliability, and exception recovery.
Production gate: a bounded task domain and blast radius; explicit policy for every high-risk action; calibrated escalation under uncertainty; evaluation of success, refusal, exceptions, and recovery—not only happy paths.
L4: the agent discovers work; the human delegates and observes
An L4 agent does not wait for an explicit prompt. It continuously watches metrics, quality, cost, or pipeline state; identifies a problem; investigates causes; and organizes a response. The human becomes a delegator or observer.
Proactivity amplifies both value and noise. Without stable semantics and business priorities, the system can classify normal movement as an anomaly. Without an attention budget, it can spend indefinitely on low-value investigations. Without strict authorization, it can proactively create incidents.
Research gate: long-lived state, goal prioritization, low-false-positive monitoring, resource allocation across tasks, revocable authority, and evaluation that can prove silence was sometimes the correct action. A scheduled alert plus an LLM summary is not, by itself, L4.
L5: the agent invents methods, not merely selects them
The L5 vision goes beyond unattended execution of known workflows. Faced with a new problem, the agent creates new data methods, tools, or research paradigms and validates where they apply. A person is no longer a necessary participant in the routine loop.
This is a research direction, not a practical procurement specification today. A system that generates code, creates a tool, or produces one novel experiment has not demonstrated stable generative autonomy. The real bar is sustained, reviewable creation of effective methods together with responsibility for their validation.
Why one product can have several levels
Attach the level to a workflow × environment × permission set, not a brand. A business-data product might be:
- L1 when it drafts SQL for an analyst to execute;
- L2 when it runs queries against a read-only warehouse;
- Proto-L3 when it decomposes a bounded business question, runs a multi-step investigation, and requests final approval;
- exploring L4 when it monitors metrics and initiates investigations.
Change the data domain, permission, or write capability and the risk changes; the old rating no longer transfers automatically. “Our product is L3” is therefore incomplete without task scope, authorization boundary, verification method, and evidence date.
Capabilities commonly mistaken for higher autonomy
- More tools are not more autonomy. Ten tools invoked in a fixed sequence can still be an L2 workflow.
- A longer chain is not more autonomy. An expanded prompt may not adapt meaningfully to the environment.
- Write access is not more autonomy. It increases blast radius, not judgment.
- Self-critique is not independent verification. A model restating its own conclusion does not replace rules, executed checks, or human review.
- Sending proactive messages is not L4. Scheduled triggers are different from problem discovery and priority management.
A safer progression path
Teams do not need to jump from L1 to L3. A more credible path gives every transfer of responsibility an evidence gate:
- Make recommendations reviewable. Preserve inputs, context, drafts, and human edits to build a real error set.
- Open read-only execution. Use sandboxes, permissions, and budgets to bound impact and make results reproducible.
- Separate verification from generation. SQL, statistical claims, data quality, and engineering changes need different validators.
- Allow orchestration only in a narrow domain. Fix the available tools, maximum steps, escalation rules, and approval points.
- Discuss proactivity last. First prove control of false positives, resources, and long-lived goals; then allow the system to initiate work.
At every step, test four classes of cases: normal completion, insufficient information, tool failure, and high-risk requests. A system that performs only when an answer exists, permissions are sufficient, and every tool works has not earned additional responsibility.
Autonomy is a responsibility contract
The value of L0–L5 is not ranking products. It is forcing a team to make an implicit operating model explicit. At each level, ask: Which authority did the agent gain? What evidence justifies that transfer? Which guardrail bounds it? Who can take over when it fails?
Without clear answers, “more autonomous” usually means harder to audit. When responsibility, verification, and recovery become concrete system design, autonomy can begin to create durable value.