What Your AI Agents Actually Need to Know

Picture a 120-person software company. Leadership wants to get serious about AI, so they give the customer success team an agent. Every Monday morning it reviews every account and flags the ones most likely to churn.

Maria runs customer success. The first Monday, she gets a list of twelve accounts. It looks reasonable. Her team spends the week on check-in calls and renewal conversations, and she tells the CEO the program is working.

Six weeks later, one of their biggest customers doesn't renew. They were never on the list.

It takes someone about ten minutes to find out why. The warehouse has two account tables. Two years ago the company changed how it counts active users, and the engineer who built the new table kept the old one running so nothing downstream would break. Everyone on the data team knew to use the new one. Nobody had written that down anywhere the agent could read, so it pulled usage from the old table, and the old table said that customer was doing fine.

There was no error and no alert. The agent did what it was asked with what it was given, and for six weeks it was confidently wrong.

That company is made up. The problem underneath it, context that only lives in one person's head, is one I've run into firsthand. I'll get to that below.

I've been thinking about this since listening to a recent Y Combinator podcast on AI adoption. Their argument was that every part of your business needs to be queryable: sales, support, ops, finance, product. If all of it is accessible, you can point an agent at it and have it do real work.

I agree, and I think most companies will need to get there. The hard part is how. "Make everything queryable" describes the finish line, and nobody can start working on a finish line Monday morning. For most companies the gap is years of work, and longer for large ones.

In my experience, teams facing that either freeze because nobody wants to own something that big, or they buy a platform, move some data into it, and call it progress. Neither gives an agent anything it can reliably use. A smaller question does.

Start with one decision

That question gives you a short list. Most companies have a handful of decisions that really move the needle and a long tail of things that are nice to know. Making the handful queryable is a project you can finish in a quarter. Making everything queryable turns into a roadmap item that never closes.

It also gives you a way to tell whether the work paid off. Think about how many high-visibility data projects get launched and then forgotten a month later. AI-assisted development has made building cheaper, so picking the right thing to build matters more than it used to. If you can't point to a decision that got better, the next round of investment is a hard sell.

Maria's company got this part right. Churn is a decision that matters. Where they went wrong came next, when someone had to decide what the agent needed to know.

There's no such thing as generally AI ready

When people say "AI can do this," they usually mean an agent, and the difference matters. A model answers a question you put in front of it. An agent goes and does a task on its own. It finds its own context and acts on it without someone checking each step. That's a much higher bar for the data underneath.

My read is that a lot of companies are adopting AI because it's clearly important and planning to figure out the use case later. I think that order is backwards and expensive, because readiness depends entirely on the job you're giving the agent.

So the business question comes first. What do you want the agent to do, and what would it need to know to do it well? A churn agent needs usage data, support history, billing status, and a definition of "at risk" your team agrees on. It also needs to know which usage table is the real one. A finance agent needs something completely different. You don't have to prepare for both at once.

Once the task has a name, the data requirements get specific. You can see what has to be accessible and what can wait. You can also see what the agent has no way of knowing unless someone tells it, which is exactly where Maria's company got burned.

Why nobody noticed

When a pipeline breaks, someone finds out fast. Ideally it's the data team. More often a stakeholder notices a number looks off, pings someone, and the ticket gets fixed quickly because people are upset.

An agent with missing context doesn't break. It answers anyway. Language models are good at producing something that reads like a confident answer, and nothing in that output tells you whether the context underneath was right. There's no alert for a plausible wrong answer.

That's why the boring work matters more now. Clean data and written definitions were always good advice, and AI raised the price of skipping them. In most companies, the missing context does exist somewhere. Usually it's in one person's head.

The person who knows

At a company I worked with recently, there were a ton of tables and almost no documentation about which ones mattered. It all lived in tribal knowledge. The person who understood the data model best was the engineer who had set it up about five years earlier.

As a newcomer to that environment, I couldn't be confident a query did what it was supposed to do until I'd checked with him. The queries themselves were simple. What I was missing was context that only existed in his head.

I've seen this in more than one place, and it doesn't reflect badly on anyone. It's what happens when a company's data grows faster than its documentation. Someone builds the first working version, and writing down how it works never beats the next urgent request for numbers.

That person becomes a bottleneck. Every question goes through them on top of their actual job. In Maria's story, the engineer knew which table to use and would have caught the problem in thirty seconds if anyone had asked him. The agent couldn't ask.

The same gap shows up across tools. Different teams pick different systems, and those systems don't always talk to each other. Maria's agent needed support history to judge churn risk. If the support tickets live in a tool nobody connected to the warehouse, the agent never sees that a customer filed six complaints last month. Someone on the support team would know. The agent has no way to find out.

Whether the context is in a person's head or a disconnected tool, the agent can't reach it. Here's the order I'd tackle that in at a company like Maria's.

The first 90 days

For a company in the 50 to 200 person range, this is roughly how I'd sequence it. By day 90, you should have one decision your team trusts the data behind, written down well enough that an agent could use it.

1. Find the champions

In each part of the business, find the person who knows what that function needs to work. Look for whoever people go to when something needs figuring out or a fire needs putting out. That's often not the most senior person on the org chart.

2. Ask them about decisions

Ask someone what data they need and you'll get a wish list. These questions get better answers:

• What decision did you make in the last month where you weren't confident in the numbers?
• What question does your team get asked regularly that takes more than a day to answer?
• What do you currently take someone's word for because you can't check it yourself?
• What do you track in a personal spreadsheet because the real system doesn't do it?
• Where were you surprised in the last year? Something that turned out worse, or later, than you expected.

The last two are the most useful. A hand-built spreadsheet means someone needed something badly enough to make it themselves, which shows you where the system falls short. A surprise shows you where missing visibility already cost money.

3. Write down what the bottleneck person knows

Before any new tools, get the tribal knowledge out of one person's head. What the core tables mean, how they connect, and which ones to trust. In Maria's case, that's one line in a doc: use the new accounts table, not the old one. It's the least exciting item on this list and probably has the best return. It's also exactly what an agent needs to read.

4. Pick the smallest platform that does the job

When companies get serious about data, the default is Snowflake or Databricks. Both are excellent and will handle whatever you throw at them for years. However, they're also expensive, and since the return on data work is hard to measure, you see the cost long before you see the value.

For a lot of companies this size, well-supported open source tooling would cover the first eighteen months fine. Before you sign anything, ask what the ideal setup would let you do that you can't do today. If the answer is vague, the platform decision can wait.

None of these four steps requires an agent to exist yet.

Queryable, in plain terms

Take the jargon out and "queryable" means one thing: can someone, or something, get an answer out of your data without needing to ask a person?

Maria's agent had all the data it asked for. The one thing it needed was in an engineer's head. Getting it written down would have helped her team before the agent existed, and it's the same work that makes the agent worth having now.

If you want somewhere to start this week, pick one decision your team makes every month and run the five questions above against it. You'll find out quickly whether the data behind it is ready for an agent or still living with one person.

Start using data to empower the decisions that move the needle.