Data Agents

Autonomy and Governance for modern data platforms

The Query That Runs Itself

For decades, the hard part of enterprise analytics was access: getting the right data, in the right format, to the right person, at the right time. A data pipeline was something you scheduled. A query was something you wrote. Access rights were assigned to humans with job titles.

Data Agents break all three assumptions simultaneously. They query data autonomously. They transform it mid-flight. They evaluate permissions at runtime, not at provisioning time. And unlike the human analyst who fetches a report once and moves on, an agent can run hundreds of operations per minute - across tables, APIs, and data systems - in pursuit of a goal it was given in natural language.

Fig. 1: Data Agents represent an evolution of modern data management

The capability is real, and it is arriving faster than the governance frameworks designed to contain it.

What a Data Agent Actually Does

A Data Agent is not simply a chatbot with database access. It is a control layer - one that sits between an AI reasoning system and the data infrastructure, brokering every operation it executes. When a multi-agent system needs information, the Data Agent determines what data is needed, validates whether the requesting agent has permission to access it, and executes only the permitted operations within a defined scope.

Fig. 2: A definiton of Data Agents

This makes the Data Agent architecturally distinct from both a traditional query interface and a general-purpose AI agent. A standard query interface executes what it is told. A general-purpose AI agent decides what to do next. A Data Agent does both - it plans a retrieval strategy, enforces governance rules in real time, and delivers results in a format the orchestration layer can act on.

The spectrum of autonomy is wide. At one end: a natural-language-to-SQL system that translates questions into database queries with human review before execution. At the other: a fully autonomous system that plans multi-step analyses, synthesizes findings across data products, and feeds conclusions into downstream agents - all without human checkpoints. Most enterprise deployments today occupy the middle range, with varying degrees of confirmation loops and policy guardrails.

Memory Changes the Architecture

What makes Data Agents structurally different from earlier automation is persistence. Through Long-Term Memory systems, agents do not start from zero at the beginning of each session. They accumulate context across interactions - which users asked about which datasets, which queries returned anomalous results, which data products are unreliable under certain conditions.

Fig. 3: Long-Term Memory enables the Data Agent

This persistence is powerful: an agent that has worked with a data environment over time can surface insights that a stateless system would miss entirely. But it also creates a new class of data artifact that existing governance has no model for. The agent’s accumulated memory is itself a derived representation of enterprise data. Who owns it? Who can audit it? What happens when a user’s access rights are revoked - but the agent retains inferences drawn from data the user once accessed?

These are not hypothetical edge cases. They are design decisions that every organization deploying persistent Data Agents will need to make explicitly - or discover implicitly, at the worst possible moment.

The Coordination Layer Arrives First, Governance Second

As organizations move from single-agent experiments to coordinated deployments, Enterprise AI Orchestration becomes the backbone: connecting AI models, agents, data pipelines, and business rules into unified workflows. The orchestration layer handles routing, sequencing, and failure recovery - it knows which agent to call and in what order.

Fig. 4: Enterprise AI Orchestration handles the complex procedure

But orchestration and governance are not the same thing. A well-orchestrated system of Data Agents can execute flawlessly and still violate data access policies - because the orchestration layer optimizes for workflow completion, not for auditability of data access. Ensuring that every agent action is traceable to an identity, a timestamp, and a business justification requires a separate governance layer that most orchestration frameworks do not provide out of the box.

LangGraph and similar orchestration frameworks offer graph-based execution models that make agent workflows deterministic and inspectable - a significant step forward. But deterministic execution is not the same as governed execution. The trace shows what happened. Governance determines whether what happened was permitted.

Agent Sprawl: The System-Level Failure Mode

The most consequential risk in enterprise Data Agent deployments is not the single agent that misbehaves. It is the proliferation of agents deployed independently across business units — each individually reasonable, collectively ungovernable.

Agent Sprawl is the uncontrolled accumulation of AI agents across an enterprise without centralized oversight. Business teams deploy agents to automate repetitive analyses. Data engineering teams deploy agents to monitor pipeline health. Finance deploys agents to track anomalies in procurement data. Each deployment is locally justified. Across the enterprise, the result is a web of autonomous actors accessing sensitive data with overlapping, sometimes contradictory, permission sets - and no single system that knows all of them exist.

Fig. 6: Agent Spawl - do you still have overview?

Traditional Data Governance was built for human access patterns: known roles, predictable behavior, audit trails that map actions to individuals. Agentic Access Governance extends this model to non-human identities, treating each agent as a principal with its own identity, its own access rights, and its own activity log. The agent that queries customer revenue data at 2am needs to answer the same governance questions as the analyst who queries the same data at 9am: who authorized this? What was the business purpose? Was the data used within policy?

Building the Infrastructure for What Comes Next

Data Agents are a structural shift, not a feature. They represent the first generation of enterprise software actors that are neither human nor deterministic rule engines - and that distinction matters for every layer of the data stack.

For data architects, the question is no longer only which data is available and how to pipeline it, but which agents are authorized to access it, under what conditions, and with what retention policy for derived inferences.

For governance teams, the challenge is extending frameworks built for human principals to cover non-human identities that operate at machine speed, accumulate memory, and may act on behalf of multiple stakeholders simultaneously.

For platform engineers, the design constraint is observability: a Data Agent that cannot be audited after the fact is a liability, not a capability. Every data access, every transformation, every inference that flows through an agent needs to be traceable to a provenance chain that a regulator, a security team, or a business owner can inspect.

The agents are already arriving. The governance infrastructure to receive them is still being built.