What an AI agent needs to know about your warehouse before it can act safely
Schema, lineage, ownership, policy and cost: the context layer that separates a useful agent from a risky one
An AI agent needs five kinds of context about your warehouse before it can act safely: the live schema, column-level lineage, who owns each asset, which policies apply to the data, and what each action costs. Without them it can still write valid SQL, but it cannot tell whether that SQL is safe to run. Tools like Claude Code already read and edit files and run commands in a terminal, and the Model Context Protocol gives them a standard way to reach your data systems. The missing piece is the context that tells the agent what it is looking at.
Key Takeaways
- •Valid SQL is not safe SQL: an agent that only sees table names cannot know what a change will break downstream.
- •Five context types gate safe action: schema state, lineage, ownership, policy and cost.
- •Read-only access by default is the cheapest safety control, and writes should sit behind approval and audit.
- •Context has to be served at query time from live metadata, because a stale description of the warehouse is worse than none.
- •Autonomy should be a dial set per domain, not a switch for the whole platform.
What an AI agent needs to know about your warehouse before it can act safely
We think the useful test is simple: could a new engineer, on their first day, safely do this task with only the information the agent has? If the answer is no, the agent should not do it either. A new engineer would ask what depends on this table, who owns it, whether it contains personal data, and what the job costs to run. Most agents today are never given a way to ask.
Below we walk through the five kinds of context, what goes wrong when each is missing, and what it takes to supply it. This is our opinion from building agents against real warehouses, not a benchmark result.
1. Schema state: what the tables look like right now
An agent working from a stale schema will write queries against columns that were renamed last week. The failure is usually quiet: the query runs, returns rows, and the numbers are wrong. The agent needs the current column names, types and nullability, plus a history of what changed. A question like "What changed in the orders schema since last deploy?" should be answerable from metadata, not from the agent guessing.
Our Schema Agent tracks column-level drift and projects what a change touches downstream. The point for safety is that drift is detected from the warehouse itself, not from documentation that someone has to remember to update.
2. Lineage: what breaks if this changes
Lineage is the context that turns "drop this column" from a guess into a decision. Before an agent edits a model, renames a field or drops a column, it needs to know which downstream tables, dashboards and jobs read it. Table-level lineage is a start, but column-level lineage is what answers "What's the blast radius if I drop this column?" and "Is the customer_id join safe after the migration?"
Without lineage the agent has two options: refuse everything, or act and hope. Neither is useful. With it, the agent can say a change touches fourteen downstream assets, three of them owned by the finance team, and ask for approval on exactly that.
3. Ownership: who to ask and who to notify
Every production asset has a person or team who answers for it. Agents need that mapping so a proposed fix goes to the right reviewer and an incident goes to the right channel. Ownership also tells the agent which assets are shared infrastructure and which are one team's scratch space, and those deserve very different levels of caution.
We covered how Data Workers keeps the catalog current in a separate post. The short version is that ownership and descriptions are only useful if they are refreshed from the systems of record, and our Catalog Agent) federates across the catalogs a team already runs rather than asking for a second copy.
4. Policy: what the agent is not allowed to touch
The most dangerous gap is policy. An agent that can query any table can also surface personal data into a chat window, a log file or a pull request description. Before acting, it needs to know which columns hold personal data, who is allowed to see them, and which retention and compliance rules apply. "Who has access to PII columns in analytics?" is a question the agent should be able to answer, and, more importantly, one it should check before it answers anything else.
Policy has to be enforced below the agent, not requested of it. A prompt that says "do not read PII" is a suggestion. Role-based access control, redaction and audit trails at the framework level are controls. Our Governance Agent handles PII detection and policy generation, and the same controls apply to every agent and every tool call, so there is no side door.
5. Cost: what this action will spend
Agents are tireless, which makes them good at running expensive queries repeatedly. Before acting, an agent should know the warehouse's current spend, which warehouses are sized for which workloads, and roughly what a proposed query will scan. A cost estimate is context in the same way lineage is: it lets the agent decide whether to proceed, narrow the query, or ask a human.
Usage history matters here too. Knowing that a table has not been queried in 90 days tells the agent it is a deprecation candidate, not a table to rebuild nightly.
Where the context should live
There are three places to put this context, and we have a clear view of each.
| Approach | What it gives the agent | Where it breaks |
|---|---|---|
| Paste it into the prompt or a rules file | Fast to start; works for small, stable projects | Goes stale; cannot enforce anything; grows past the context window |
| Let the agent query the warehouse directly | Always current schema and row data | No lineage, ownership or policy; the agent sees everything its credentials allow |
| Serve it through MCP tools backed by live metadata | Current, scoped, auditable context at the moment of the decision | Requires the metadata to exist and be connected |
We build for the third row. The MCP specification defines how a client such as Claude Code or Cursor discovers and calls tools exposed by a server, and the reference material lives in the modelcontextprotocol GitHub organization. Because each Data Workers agent is an MCP server, the context arrives as tool results at the moment the agent needs it, rather than as a static document that was accurate in March.
A worked example: the 40% row count drop
Take a question we hear often: "Why did row counts drop 40% overnight?" An agent with only SQL access will count rows, compare to yesterday and speculate. An agent with the five context types behaves differently. It checks schema history and finds a type change on a join key. It follows lineage to see the affected table feeds three downstream models. It looks up the owner of the upstream source and sees the change shipped in a release yesterday. It confirms no policy blocks the proposed fix, and it estimates the backfill cost before proposing it.
In our design the Incidents Agent diagnoses root cause, the Schema Agent maps blast radius, and the Pipeline Agent proposes the fix. That is context shared across agents instead of re-derived by a human in a terminal. In early pilot testing, 60% of incidents auto-resolved before a human was notified. That is our pilot data, from a small sample, and your results will depend on how much of the context above already exists in your stack.
Where Data Workers fits, and where it does not
Data Workers is an open-source platform of fifteen MCP-native agents. The Apache 2.0 edition (dw-claw) runs locally and is read-only by default, which matches the safety posture above: an agent that cannot write cannot do much damage while you learn what it does. Pro adds writes, enterprise connectors, approval workflows and audit trails. Our Autonomous Data Conductor sets a per-domain autonomy dial, so you can let agents resolve incidents on a low-risk domain while keeping human approval on finance tables.
It does not fit every situation. If your warehouse has no ownership records, no lineage and no classification, the agents will surface those gaps rather than fill them, and that is useful but not magic. If you only need an agent to draft SQL that a human reviews line by line, a plain coding agent with a good rules file may be enough. And if your policy requires that no tooling run outside a specific network boundary, you will want to look at the VPC and on-prem options before anything else. Data stays in your infrastructure either way.
For the broader argument, our thesis page explains why we think the move from data platforms to agentic platforms depends on this context layer, and the product pages describe each agent in more detail.
A short checklist before you give an agent write access
- •Can the agent see the current schema and recent changes, not a cached copy?
- •Can it answer what depends on an asset before changing it?
- •Does every asset have a named owner the agent can route to?
- •Are PII columns classified, and is access enforced below the agent?
- •Does the agent see a cost estimate before it runs something large?
- •Are writes behind approval, with an audit trail you can read afterwards?
If you can answer yes to the first five, you are ready for read-only agents that diagnose and propose. If you also answer yes to the last, you can start turning the autonomy dial up one domain at a time.
Frequently Asked Questions
What is the minimum context an agent needs before it can write to a warehouse? We would say schema state, downstream lineage and an enforced access policy. Ownership and cost are strongly recommended, but without the first three an agent cannot know what its change breaks or what data it is allowed to touch.
Is a rules file or CLAUDE.md enough to give an agent warehouse context? It helps with conventions such as naming and style, and we use one ourselves. It cannot reflect live schema, lineage or policy, and it cannot enforce anything, so we treat it as a supplement to served context rather than a replacement.
Why should agents be read-only by default? Because the cost of a wrong read is a wrong answer, while the cost of a wrong write can be a broken pipeline or a leaked column. Starting read-only lets a team observe what the agent would do, then grant writes per domain with approval and audit.
Does this work with Claude Code and Cursor? Yes. Every Data Workers agent is an MCP server, so any MCP-compatible client can call it, including Claude Code, Cursor, Windsurf, VS Code and GitHub Copilot. Your engineers stay in the tools they already use.
Does warehouse data leave our infrastructure? No. Data Workers runs in the customer's infrastructure, and the framework applies SSO, RBAC, encryption, PII redaction and tamper-evident audit trails across every agent and tool action.