What Makes an AI Agent a Data Agent

Ask data teams what they are building with AI, and one answer keeps coming back: a chat box on top of the warehouse. You type “what was revenue last week?” and a number comes back. Impressive for a minute. But this picture of AI for data is far too small.

I’ve spent the last two years building AI agents that work on company data, and the conversations usually start with the same request: “we want our people to ask questions in natural language.” That’s real value — but it is only the beginning. An agent that truly knows your data can do much more than answer questions. It can investigate an anomaly, build a dashboard, watch a metric and speak up when something breaks — and, eventually, take action on what it finds.

What separates the chat box from all of that? Not a better model. It is an agent that thinks for itself instead of following a fixed workflow. It is the tools the agent can act with. And it is everything the agent does not yet know about your business.

The first post of this series covered the thinking part: what an agent is and how it works. This post covers the rest. The missing knowledge splits into two things — the context the agent must know, and the data it works on. Add the tools it works with, and you have the three parts of a data agent: context, data, and tools. By the end you’ll know exactly what each one demands, and why the hardest parts are already in your hands.

The Machinery Is Brilliant. The Knowledge Is Missing.

In the first post, we imagined the best analyst in the world joining your team. Brilliant SQL, sharp analytical instincts, endless patience. We also defined the machinery she runs on: an agent is an LLM with tools, running in a loop. That definition covers every agent there is — and it says nothing about your company.

So what is missing? Everything that is specific to you. She has never seen your warehouse. She doesn’t know what “active user” means in your company — and it means something different in every company. She doesn’t know which of your tables to trust, or that finance always excludes test accounts from revenue.

The machinery doesn’t change. What changes is what you give her:

• Context — what she must know. The meaning side of your business: definitions, rules, tribal knowledge.
• Data — what she works on. The structure side: shaped so she never has to guess.
• Tools — what she works with. Built for data at scale, not for a demo.

Context: Teaching the Agent Your Business

Start with what she must know.

Think about how a new analyst actually learns your company. Someone walks her through the business model. Someone explains that “active user” here means activity in the last seven days, not thirty. Someone warns her that the events table double-counts sessions from the mobile app. None of this is in any textbook. It is tribal knowledge — the knowledge that exists only inside your company.

A data agent needs the same education. What does that education contain?

• The business. What the company does, who the customers are, how the money is made.
• The domains. What marketing cares about, what finance cares about, and the different questions each of them asks.
• The entities and what they mean. What a customer is here, what an order is, how a game session connects to a player.
• The metrics. What you measure, how each metric is calculated, and which definition is the official one.
• The glossary. The words that mean something specific in your company — a “whale,” a “power user,” “the weekly.”

Almost none of this is written down in one place. It lives in people’s heads. The rest is scattered across tools — a dbt description here, an old wiki page there, a Slack thread from two years ago. Collecting it is real work — and it is still the easy part.

Keeping it useful is harder. The four biggest reasons why:

1. It changes. The business ships a new pricing plan, and “revenue” means something new. Context has a shelf life — it must stay fresh as the business moves.
2. It must live in one shared place. When two documents define churn differently, the agent picks one. You don’t know which. Duplicated or ambiguous context does not just add zero value — it pushes the agent toward wrong answers.
3. It must be organized for retrieval. The agent doesn’t read everything you wrote on every question; it loads what it needs, when it needs it. For a question about last week’s revenue, it should load the revenue definition and finance’s rules — not your entire glossary. How the context is structured decides what the agent can find, and how much you pay for every answer.
4. Some of it must be deterministic. Some decisions should not be re-reasoned from scratch on every question. The official churn definition should resolve the same way every single time. For those, you build fixed flows the agent follows, not suggestions it considers.

This is why “just write a good prompt” is not a context strategy. Context is an asset. It gets built, maintained, and versioned — like code.

Context is an asset. It gets built, maintained, and versioned — like code.

What does that look like in practice? A context repository, organized so the agent can navigate it:

context/
├── BUSINESS.md            # who the business is
├── GLOSSARY.yml           # the company vocabulary
└── domains/
    ├── finance/
    │   ├── DOMAIN.md      # what finance cares about, its rules
    │   └── GLOSSARY.yml   # finance's own terms
    └── marketing/
        ├── DOMAIN.md
        ├── entities/
        │   └── campaign/
        │       ├── ENTITY.md     # prose: what a campaign is
        │       └── schema.yml    # structure: features, metrics
        └── skills/
            └── attribution-analysis/
                └── SKILL.md

And inside those files, plain language. Two entries from a GLOSSARY.yml:

# GLOSSARY.yml
whale:
  name: Whale
  description: A player whose total deposits crossed $10,000.
the_weekly:
  name: The Weekly
  description: The Monday revenue dashboard sent to management.

Notice the shape: every concept has exactly one home — one place where it is defined. That structure is not cosmetic — it is what makes retrieval work. And no tool ships with these files filled in: the knowledge inside them lives only in your company.

Data: Modeled for BI, Not for AI

But context alone is not enough. Even perfect context sits on top of a warehouse — and the warehouse was built for a different consumer. Here we meet a problem that has been growing for four decades.

Since the first data warehouses, we have modeled data for BI. Star schemas, wide tables, aggregated marts — all designed for one kind of consumer: dashboards, and the human analysts behind them. That worked, because a human consumer is forgiving. An analyst carries the missing context in her head. She knows revenue_v2 is the current table. She knows the marketing team’s “active user” is not the product team’s “active user.”

The data could stay messy, because the human filled the gaps.

Count them: how many definitions of “active user” live in your warehouse right now? You might find not two or three, but a dozen or more. Every one of them made sense to someone, once. Nobody planned the mess. The industry grew it over four decades, one reasonable decision at a time.

Now put an agent on top of that warehouse. An agent is not a forgiving consumer. It sees a dozen similar definitions, and it has no tribal knowledge to choose between them. So it works hard — loading candidates, comparing them, burning tokens on every question.

And in the end it picks one definition and answers with full confidence. When it picks wrong, we call it a “hallucination.” But the model didn’t fail. The data was ambiguous, and the agent had to guess.

So do we need a new way to model data? Yes. If the consumer is an AI agent, the data must be modeled for AI:

• Each business definition exists exactly once. One “active user.” One “churn.” One official revenue metric. Not enforced by a style guide — enforced by the data model itself: each definition has exactly one home, the agent’s retrieval starts there, and there is no second place where a competing definition can live.
• Entities are the levels of granularity in your data. A customer. An order. A game session. Each entity is defined once, with a clear meaning.
• Each entity carries its features, metrics, and relationships. Features are its columns. Metrics declare how numbers get aggregated — so the agent doesn’t have to invent a calculation. Relationships declare how entities connect — so the agent doesn’t have to infer a join.

This is the structured semantic layer the first post promised: one layer of meaning between the agent and the raw tables.

Here is what a customer entity looks like — two files in one folder. The prose file describes what the entity is, and its rules:

# ENTITY.md
A customer is a person with a registered account. One row per person.
Note: rows before 2024 may be duplicated — always deduplicate by id.
Finance excludes test accounts (is_test = true)
from every revenue number.

And the schema file holds its structure:

# schema.yml
identity: warehouse.prod.customers
keys:
  - id

features:
  - name: country
    description: The customer's billing country
  - name: plan
    description: Current plan. Values are free, premium_v2.
  - name: last_activity
    description: Timestamp of the customer's most recent activity

metrics:
  - name: active_customers
    description: Customers with activity in the last 7 days
    sql: COUNT(DISTINCT CASE WHEN last_activity
         >= CURRENT_DATE - 7 THEN id END)

relationships:
  - name: orders
    description: One customer has many orders
    join: customer.id = orders.customer_id

Every question about customers now starts from this folder — not from a pile of near-matches.

And no, this does not mean rebuilding forty years of BI models. The entity model is built alongside your existing marts, on the same warehouse — not instead of them. Your dashboards keep running. The real work is agreement: collapsing those competing definitions into one official version means finance and marketing sit at the same table. That work is real — but you do it once, and every question after that inherits it.

Model the data this way, and the agent no longer has to guess at definitions and joins. When it joins two entities, the path is declared, not discovered.

The Ontology: A Virtual Brain

Put the two ingredients together, and something bigger appears.

The context holds what your business means — the knowledge, the definitions, the rules. The data model holds what your business is — the entities, their features, their metrics, their relationships. Connect them and you get an ontology: one connected map of your business that an agent can navigate.

The ontology is a virtual brain that resembles your business. The warehouse alone is not that brain — it’s just rows. The documents alone are not it either — they’re just words. The ontology is the structure that ties meaning to data: this entity is a customer, this is what a customer means here, this is how customers connect to orders, and this is exactly how we count the active ones.

Give an agent that brain, and it stops being a tourist in your warehouse. It becomes the analyst who has worked with you for years.

Tools: What the Best Analyst Works With

The brain is built. Now she needs her hands.

But hands don’t move on their own. She reasons first: she looks at the task and makes a plan. Based on that plan, she decides which tool to use, when, and how — then she looks at the result and reasons again. The agent is the one who decides what comes next.

That is why every task might take a different flow, one nobody predicted in advance. A revenue question might take one query; an anomaly investigation might take twenty, each one chosen because of what the last one returned. So the tools below are not steps in a pipeline — they are capabilities the agent picks up when its own reasoning calls for them. The core five:

Context retrieval. Before writing a single line of SQL, a great analyst checks what she knows: what does this metric mean, which entity holds it, what are the rules? The agent does the same through search — it navigates the ontology and loads only the pieces the question needs. For last week’s revenue: the revenue metric and finance’s exclusion rules, nothing else. This tool decides both accuracy and cost.

Text-to-SQL. The famous one: the agent translates the question into a query and runs it against the warehouse. With the ontology behind it, the agent no longer writes SQL from imagination — the definitions, joins, and calculations are already declared. “What was revenue last week?” becomes the declared revenue metric’s SQL, not a fresh guess. The agent assembles; it doesn’t invent.

Working with data at scale. What happens when the answer lives in a billion rows? A warehouse table can hold billions of them, and a context window cannot hold even a million — and should not. The agent needs tools that keep the raw data out of its head: run the heavy work in the warehouse, bring back aggregates, spill large intermediate results to files and read back only what the next step needs.

Resolving values. A user asks for last month’s revenue from an affiliate called “superdupy.” The warehouse only has superduper. The best analyst in the world would not answer “there was no revenue from superdupy” — she would spot the typo, answer for superduper, and say so. A data agent needs the same reflex: look up the real values before filtering. Otherwise the query runs perfectly and returns a confident zero.

Visualizations. Analysis usually ends in a picture. The agent needs a charting tool — and, just like a human analyst, instructions on how your company presents data: no pie charts, trends always as line charts, your brand’s colors.

The tools are what make the brain usable at data scale.

Skills: When You Do Want a Predefined Flow

All this freedom raises a fair question: what if you don’t want the agent to improvise?

Some work should not be reinvented on every run. Your team has a method for churn analysis — five steps, in order, refined over years. The weekly revenue report has a fixed structure. For these, you give the agent skills: packaged playbooks, written by your team, that it loads and follows. We met skills in the first post; for a data agent they are how your best analytical practices become repeatable.

The division of labor is clean. The agent still decides when a skill fits the task — that judgment stays in the loop. But once inside the skill, it follows your steps, in your order, to your standard. Freedom where it helps, discipline where it matters.

Bigger Than a Chat Box

Everything so far has assumed the familiar picture — the chat box from the top of this post, a person asking and an answer coming back. So I want to propose a different perspective. What if the consumer of the data agent is not a person at all? What if it’s another agent? Or no one — the agent runs proactively, looking for hidden opportunities in the data, without anyone asking anything?

The first is already technically simple. A data agent can serve other agents through protocols like MCP — an open standard that lets agents and tools talk to each other. Picture what that enables: a marketing agent notices a campaign is underperforming, asks the data agent which segments stopped converting, and shifts budget between channels. A fraud agent spots a suspicious pattern, asks the data agent for the account’s history, and freezes the account — a person reviews the decision afterward, not before. The agents handle the data, make the decision, and take the action, while people supervise instead of approving every step. And who decides when an agent has earned that much freedom? The team that built its brain and controls it.

The second changes who starts the conversation. Instead of waiting for questions, the agent watches the data itself: it notices a metric drifting, investigates overnight, and shows up in the morning with findings nobody asked for.

Where does the world actually stand? I know of no company that runs this today. Rule-based systems already freeze accounts automatically — but a fixed rule is not an agent deciding for itself. The core technology is ready; the trust is not. Freezing a customer’s account on an agent’s own judgment demands a level of confidence that no agent has earned yet.

Self-driving cars already taught us this lesson. The question moved from “can they drive themselves?” to “what would it take to trust them?” — and trust was earned, mile by mile.

What’s Still Missing Before Production

Everything in this post builds a capable data agent. It does not yet build the trust the last section asks for. There are more missing pieces than one post can cover. The main ones:

• A feedback loop. The agent will get things wrong. Where do corrections go, so the same mistake never happens twice?
• Access control. Not everyone may see every number. The agent must respect who is asking, not just what they asked.
• Memory. What the agent learns in one conversation should survive into the next. Memory is a deep topic — it deserves a post of its own.
• Visibility. When the agent answers hundreds of questions a week, someone has to see what it’s being asked, what it answered, and where it struggled.

This is the trust scaffolding — the pieces that separate a promising agent from a production system.

The Question Is Trust

Notice where the hard work lives. The model improves every year, whether you do anything or not. The tools can be built once, or bought. But the context and the data, the two halves of the virtual brain, cannot be bought anywhere. They exist only inside your company. Nobody can ship them to you, and nobody can take them from you. That is why the hardest parts are already in your hands — and why your data team is the only team that can build them.

The chat box was never the destination. An agent that investigates a drifting metric overnight, serves other agents, and acts on what it finds — that is where this is going. Nobody is fully there yet, and the reason is not technology.

So the question worth asking is not whether AI agents will work on your data. It is what’s required for you to trust them when they do. That is the next post.