The Agentic Data Platform: From Human-Facing to AI-Facing
A New Kind of User
In my earlier posts, I wrote about why and when a company needs a data platform, and the six components inside one. Both posts had one assumption that I didn’t say out loud: the users are people. An analyst opens a dashboard, a data scientist writes a query, a manager reads a weekly report.
This assumption is changing. When a company puts agents into customer support, sales, finance, or engineering, these agents need enterprise data to do their job. So a growing part of the requests to the data platform does not come from a person anymore. It comes from an agent. I believe that in a few years, agents will be the biggest users of most data platforms, by number of queries, and by a large margin.
This is the start of a new kind of data platform. People call it the agentic data platform, and I see two sides of it. It serves AI agents with governed enterprise data, and agents also do a big part of the work to build and run it. It also needs two more things: a feedback loop, so it gets better from every request, and guardrails that extend its governance to agents. In this post I focus on structured data, the tables, metrics, and pipelines most data platforms are built around.
The six components don’t go away. You still need ingestion, storage, transformation, metadata, governance, and consumption. Actually, the basics matter even more. An analyst who sees a strange number can walk over and ask a coworker whether the table is right. An agent cannot. It uses whatever it finds, and if the data is wrong, it repeats the same mistake very fast and many times. So bad data quality, missing descriptions, and unclear ownership hurt more with agents than with people.
A Data Platform for Agents
An agent uses data differently from a person. Instead of looking at a chart, it calls a tool, reads the answer as text or JSON, and decides what to do next. A BI tool is designed for human eyes and a mouse. An agent can still click through a web page with computer use, or call the endpoint behind a button, but this is slow and breaks easily. So the important things in your platform should have a proper API or CLI: running a query, searching the catalog, checking the freshness of a table, looking up lineage, or reading a metric definition.
Besides the interface, the format and content of what the platform provides need to change too. A UI shows what fits on a screen and what a person can read quickly. An agent needs something different. For example, a data catalog service I used to work on showed the 5 most common values of each column on its UI. For a person, 5 values are usually enough to understand what the column looks like. But a text-to-SQL agent may need 1,000 or more example values, so it knows the real spelling, format, and range of the values, and can write more robust queries. 1,000 values are far too many to show on a UI, but for an agent they may still not be enough. This is not only about the catalog. An agent knows nothing about your company. It does not know that orders_v2 replaced orders, or that revenue in finance excludes refunds, unless the platform tells it. So the whole data platform should give agents the content they need, in a format they can use, not just a copy of what the UI shows to people. Because of this, I think the data catalog will move from a side tool that people open when they are lost, to a key service of the platform. It is where agents learn what the data means before they touch it.
Then there is the output. Today the end of the line is usually a dashboard or an alert in Slack, and a person decides what to do next. In an agentic platform, the output of one step is often the input of the next agent. When a data quality check fails, the result should come through an API in a structured format, so another agent can skip the bad table, tell the user the number may be wrong, or even start troubleshooting the issue and creating a fix. Monitoring results, job status, and quality scores all become context for the next agent.
A Data Platform Run by Agents
The other side is about who builds and runs the platform. A lot of data engineering work is honestly not very interesting: writing another ingestion job, mapping the columns of a new source, fixing a pipeline after someone renamed a field upstream, turning a business requirement into a query. Coding agents are already good at this kind of work.
They can do both the coding and the operations. An analyst writes a business requirement in plain words, and the agent turns it into SQL or dbt models, a Python script, or a Spark job, adds tests, and opens a change. When a new source arrives, the agent profiles the data, reads the column names and sample values, and proposes how to map them to the target model. When a source renames a column, it finds the affected tables through lineage and fixes each of them. When a job fails or a quality check finds bad data, an agent picks up the alert, troubleshoots the issue, and opens a fix or starts a backfill, often before anyone has looked at it. It can also look at the data and suggest quality checks, like “this column looks like an email” or “this count usually stays in this range”.
So what do data engineers do then? In my opinion, they stop writing most of the pipelines themselves, and build the system that writes and runs them. That means the development pipeline for agents: the standards and naming rules the agent must follow, the context it gets about the data models, the tests and evaluations that decide whether a change is good, and the guardrails around what it is allowed to change. Once this system is solid, the code review can also be done by an agent, together with automated tests. People design the system and handle the cases it cannot.
This also changes what the platform itself needs. For agents to run the platform, the platform has to be easy for an agent to change and test. Pipelines, schemas, permissions, and quality rules should all be defined as code, so an agent can read them and change them through the normal development pipeline. Agents need a safe place to try things, like a development environment with a copy or a sample of production data, so a wrong change breaks nothing. After a change, the agent also needs to check the result by itself: run the tests, compare the data before and after the change, and read the job logs. All of these should be available through an API, so the agent can verify its own work without waiting for a person.
Closing the Feedback Loop
Today, a data platform improves slowly. Someone notices a report is wrong, files a ticket, and maybe the fix lands a few weeks later. With agents, the platform can learn from every request, but only if the outcomes come back to it automatically: every query an agent ran, whether it succeeded, how much it cost, whether the user accepted the answer or corrected it, and what action followed.
Text-to-SQL is a good example. Every generated query gets some feedback from the user. They accept the answer, run the query again later, edit it, or say it is wrong. Most of this feedback is lost today. But it is exactly what a text-to-SQL model needs. Queries that are used again and again by many users, with good feedback, are proven pairs of a real business question and a correct query. The queries users corrected are even more useful, because they show the mistake and the fix together. Collect these, and use them to improve and evaluate the text-to-SQL model, as fine-tuning data, or as examples the model retrieves when it gets a similar question. A better model gets used more, more usage brings more feedback, and the feedback makes the model better again. That is the flywheel you want to get spinning. The corrections also show where the metadata is unclear, or where a metric definition is missing, so the platform improves together with the model.
The same flywheel works for other agent tasks on the platform. Review comments that engineers accept or dismiss can train the code review agent, alerts marked as real or noise can tune the quality checks, and tags corrected by the governance team can improve PII classification. In my opinion, this feedback data is one of the most valuable datasets a company has. No vendor or public model can have it, but most companies throw it away today.
Guardrails for Agents
Most data platforms already have access control, masking, and audit logs, and all of them still apply. But they were designed for two kinds of users: people, and service accounts that run fixed pipelines. An agent is neither. It works for a person but is not that person, it writes and runs its own code, it can call many tools, and it can spend money or change data without anyone watching each step. So the existing governance needs guardrails for this new kind of user.
It starts with identity. Each agent should log in as itself, not with a shared service account, and get only the data its task needs. When an agent works for a user, it should never see more than that user can see. And there must be no way around the rules. If row filters and column masks are applied on views, the agent should not be able to read the raw files in storage, or switch to another tool with wider access. Code generated by the agent should run with the same identity and the same limits.
Cost needs a guardrail too. An agent can run hundreds of queries in a few minutes, and one bad loop or one query without a filter on a huge table can cost real money. So set spend limits per agent and per task, on query cost, data scanned, runtime, and number of calls.
Most agents only need to read. Writing to production tables, changing schemas, or deleting data should go through the agent development pipeline with its tests and checks, or need explicit approval. And these rules belong in the platform, not only in the prompt. “Never read payment data” in a prompt is a suggestion. The same rule enforced by the platform still holds when the model behaves in a way nobody expected. Finally, log every query and action with the agent’s identity, and make sure you can stop one agent, see what it did, and undo what can be undone, without stopping the whole platform.
What Can Go Wrong
Most of the failures I expect are not the model’s fault. The agent does what it is designed to do, but the data or the context it gets is wrong.
Wrong answers that look right. This is the one I worry about most. A generated query runs without error and returns a clean number, but it used the wrong join or missed a filter. Nobody reads every query an agent writes. Being mostly right is fine for exploring data, but not for a number that goes to finance. The best protection I know is a test set of real questions with known correct answers, which runs every time the metadata, the data models, or the agent changes. The queries with good user feedback from the previous section are a good start for this test set.
Too much context, or the wrong context. If an agent searches the catalog and finds 200 tables with “customer” in the name, it will pick one, and maybe the wrong one. More metadata is not always better. Certified tables, usage statistics, and clear ownership help the agent choose the table people actually trust.
Agents that don’t see each other. When several agents work on the same customers or the same data, and each keeps its own record, they start to disagree. A marketing agent sends an offer to a customer who complained to the support agent an hour ago. So agents that work on the same customers should read from and write to the same place, and record what they did there in a structured way, so the next agent can see it.
If you look at these three again, none of them is really a model problem. They are data platform problems, and to me that is good news, because these are problems data engineers already know how to solve.