Here are the questions that should be on every data leader’s mind as they figure out their role in an AI-first world: what is data, what does analytics mean, and what are data teams actually for?

For decades, the answers were shaped by a single constraint. SQL was the only scalable way to reason over information, so we defined “data” as whatever SQL could reach and built everything around that. AI agents just removed the constraint. None of those answers hold anymore.

Agents don’t need SQL. They speak any language, write any code, interact with any system. The warehouse is one stop of many, and the number of stops is growing every day.

We never defined data based on what was valuable. We defined it based on what SQL could reach. That constraint is gone now. A data asset is anything an AI agent can query, retrieve, and reason over. Structured tables, documents, Slack threads, customer emails, call transcripts. If an agent can access it and draw conclusions from it, it counts.

The broader AI world is already converging around this idea under the banner of context engineering: curating and delivering the right information to AI agents so they can reason effectively. Data teams should be the natural owners of this discipline. Instead, most are still scoped to the warehouse, answering questions like “what were my top five products last month?” That’s valuable work. But the potential sitting in front of data teams right now is so much bigger, and most aren’t seeing it yet.

This is existential. If data teams don’t claim this expanded scope, engineering, product, and ops will. They’ll build the context layers, own the AI strategy, and the data team will be left behind while the most important work in the organization happens without them.

I’ve spent over a decade in this industry, from Periscope Data to building Push.ai. The gap between where data teams are and where they could be has never been wider. Here’s the longer version of why I think that, and what needs to change.

The Constraint We Inherited

We never defined data based on what was valuable. We defined it based on what our tools could handle.

SQL gave us a consistent, scalable way to store and query information. Because it worked so well, everything got built around it. Warehouses, BI tools, transformation layers, metric definitions. The entire modern data stack is an expression of one assumption: data is what fits in rows and columns.

The Big Data era didn’t challenge this. It doubled down. Bigger tables, faster compute, more parallelism. The philosophy stayed the same. If SQL could query it, it was data. Everything else was noise.

I run into this in my own work all the time. A company loads their Salesforce opportunities into the warehouse to track pipeline, forecast revenue, measure conversion rates. All structured fields. But sitting right next to that pipeline data are fields like “Next Steps” and “Closed Lost Reason.” Rich text that people have been typing into Salesforce for years. Context about why deals stalled, what the competitor offered, what the champion was worried about.

That context has been landing alongside the structured data all along. Nobody touched it because the tools couldn’t reason over free text at scale. And this is just one example. Every organization has years of context buried in support tickets, Slack threads, call transcripts, CRM notes, documents that have been invisible to the data team because they didn’t fit the definition.

The unstructured data was never absent. It was invisible to the tools we built our entire philosophy around.

The Barrier Is Gone

Before AI, working with unstructured data meant machine learning pipelines, NLP models, or basic string matching. You could search for a keyword in a support ticket. You couldn’t ask “why are enterprise customers churning?” and get a synthesized answer from support conversations, CRM notes, and product usage data at the same time.

That’s over. I’ve watched agents compile product usage data, customer feedback, and CRM notes into a customer 360 with a depth that wasn’t possible before. Not because the data was new. Because no human could hold that much context from that many sources at once, and no tool before this could either.

The infrastructure vendors see it too. Snowflake is embedding Cortex AI into SQL workflows. BigQuery added native AI functions to process text and images alongside structured data. Databricks is repositioning as the unified lakehouse for structured and unstructured at scale. These are real moves, but they’re capability additions, not a philosophical rethink. The warehouse is still the center of gravity. Unstructured data is being treated as an add-on, not a reason to reconsider the paradigm.

The paradigm needs reconsidering.

A data asset is anything an AI agent can query, retrieve, and reason over. Structured tables, documents, Slack threads, customer emails, call transcripts. If an agent can access it and draw conclusions from it, it counts. And the scope of what agents can access is expanding faster than most data leaders realize.

What Data Teams Are Actually For

This is the question that matters most, and I don’t think the data industry is taking it seriously enough.

The broader AI world is already converging on a concept called context engineering: the discipline of curating, structuring, and delivering the right information to AI agents so they can reason effectively. It’s becoming central to how AI systems get built. And the data industry, the people who should be best positioned to own this, hasn’t connected the dots yet.

The old question for data teams was “how do we model and structure this?” The new question is “what context do our agents need, and where does it live?” That’s a fundamentally different job. And it’s the job that will determine whether data teams stay relevant or get sidelined.

The data professionals who step into context engineering become context owners, the people who decide what intelligence the organization’s AI agents actually operate on. Not just maintaining the warehouse and building dbt models, but owning the full landscape of information that AI draws from. That’s not a narrowing of the role. It’s the biggest expansion the data team has ever had.

But here’s what makes this existential: if data teams don’t claim this scope, someone else will. Engineering, product, ops. They’ll build the context layers, own the AI strategy, and the data team will stay behind answering “what were my top five products last month?” while the most important work in the organization happens without them.

The risk isn’t moving too fast. It’s holding onto a definition of data that was built for a constraint that no longer exists.

I don’t think the industry has much time to figure this out. The teams that are redefining their scope right now are the ones that will matter in two years. The ones that aren’t will be wondering what happened.

How is your team thinking about what counts as a data asset now? I’d genuinely like to hear where you’re drawing the line, and why.