Before you plug an agent into your warehouse, ask four quiet questions about the data underneath it.
A team is in a room, about to ship their first internal AI agent. Someone opens a laptop and asks it, "how many active customers do we have?"
It answers in a second. Confidently. Wrong.
Not because the model is bad. Because the warehouse behind it has three different definitions of "active customer", and the agent picked one at random.
Most conversations about AI agents are about the model. Which one is smartest. Which one is cheapest. Which one has the longest context window.
Those are real questions. They are just not the interesting ones for a data engineer.
The interesting question is what the agent sees when it looks at your data. Whether the numbers are fresh. Whether the definitions are agreed. Whether the same question asked twice returns the same answer.
Databricks made this point directly in a recent post: your AI is ready, your data foundation probably isn't. The teams that get value from agents are not the ones with the best model access. They are the ones whose data was already in good shape before the agent arrived.
An agent is a very fast reader of your data. If the data is confused, the agent will confidently repeat the confusion.
Here are four foundations worth checking before any agent touches production data. Each one maps to something you already have in Databricks.
Before an agent can answer "how many active customers", something in your warehouse has to define "active". Once. In one place.
This is the classic job of the medallion architecture. Bronze holds the raw truth. Silver cleans and conforms it. Gold is where business terms live, defined once and reused everywhere.
If your Gold layer is thin, or if every dashboard reinvents the definition, the agent will pick whichever version it stumbles into first.
An agent inherits the permissions of whoever runs it. That is a bigger deal than it sounds.
Unity Catalog is where this gets handled on Databricks. Table grants, row filters, column masks, audit logs. Boring, until the day someone asks the agent for a report that quietly includes a column it should not have seen.
Before you connect an agent, ask a simpler question. If a new intern had this login, what could they read? That is what the agent can read too.
An agent that answers with yesterday's numbers is not wrong exactly. It is just quietly misleading.
Freshness is a pipeline problem, not a model problem. Declarative pipelines, Jobs and Pipelines, and expectations checks are what keep the Gold layer honest. If a pipeline fails at 3am, do you know before the agent does?
The goal is not real-time everything. The goal is that when the agent answers, you know how old the numbers are.
The last foundation is the one people skip. You need to see what the agent actually did.
Which tables did it read. Which queries did it run. Which answers did it give, to whom, at what cost. Debugging and monitoring habits from data engineering apply here almost unchanged. Log the query. Log the response. Sample the outputs. Review a few every week.
Without this loop, you do not have an agent. You have a very expensive black box.
Six questions. Take them into the next meeting where someone proposes an agent.
If any of these have shrugs as answers, the foundation is not ready yet. That is fine. It is much cheaper to fix now than after the agent is live.
This is the same idea we wrote about in Context, Control, Cost, Choice. The model is the visible part. The context around it is what decides whether it is useful.
If you want more of this kind of thinking, platform-independent and longer-form, the Context Advantage hub is where we collect companion reads.
And if you want to get the Databricks foundation itself right, that is what the rest of BricksNotes is for. Start with Medallion Architecture and Unity Catalog. The agent can wait a week.