The Hard Part of AI Analytics Isn’t the Chat Box

I went into dbt Summit last week expecting to learn something that would fundamentally change my mind about where AI analytics is going. That didn’t really happen. Instead, I had the slightly surreal experience of watching the problems we’ve spent the last two years solving at Gravity take center stage across the entire industry.

If you strip away the category-adjacent infrastructure updates, the checklist dbt put on stage for AI analytics in 2026 was remarkably clear: agents need trustworthy context, governed semantic definitions, and deep awareness of lineage and ownership. Business users need conversational access to data, but the data team must remain in total control of what those agents are allowed to trust.

dbt’s language was strikingly direct: "structured, governed context" is the missing layer between a raw warehouse and an AI agent whose answers you would actually stake a business decision on. Their new Fivetran Context Layer combines structured metadata with un-modeled docs and Slack threads; Agents Schema creates a standard warehouse location (AGENTS.ROOT) for agent-readable context; and Wizard Explore Mode gives users a conversational entry point into a dbt project.

My reaction to all of this was two-fold. First: yes, exactly. And second: you still need more.

Chat is an interface, not an analytics strategy

I talked to a surprising number of data leaders under direct pressure from executives to deliver "AI for our data." A few are already down the road: they’ve given sophisticated users access to advanced LLMs, pointed them at a warehouse, added some baseline documentation, and discovered the model can be astonishingly capable.

They’ve also discovered the jagged edge.

It works incredibly well right up until a user asks a question just outside the area where the agent has explicit context. Then it starts reasoning from incomplete information. The SQL can be 100% syntactically valid, and the business answer can still be completely wrong.

Practitioners kept describing the exact same failure mode: the system has to be taught what "active customer" actually means, which tables are authoritative, and when the available data simply cannot answer the question. Generating the SQL is the easy part. As one data lead put it: AI is particularly terrible at saying "no" when the underlying data doesn't support the user's premise.

That’s why "chat with your data" drastically undersells the problem, and why we’ve built Orion's Warp Drive engine the way we did. Tools like dbt Wizard Explore Mode ground chat in an existing project, which is certainly better than throwing an unconstrained LLM at a raw database. But a chat box is still just an interaction model, not a complete collaborative analytics platform.

The real work happens around it.

Context should be engineered while people work

One of dbt’s most intriguing announcements was Agents Schema: a standard home for agent context inside the warehouse covering models, columns, dependencies, and skills. Context absolutely needs to be durable and inspectable.

Where our perspective differs is that most real-world enterprises don't operate out of one perfectly self-contained analytical system. They have dbt alongside Looker, Power BI, Snowflake, BigQuery, unstructured documentation, tribal knowledge, and legacy systems everyone wishes would disappear. Orion treats context as a unified abstraction layer across that entire messy environment.

More importantly, the solution can't be asking data teams to freeze their day jobs and author the world’s largest, static CONTEXT.md file. Business context doesn't sit still. A metric gets redefined, a product line launches, finance restates a quarter, and the document is wrong a week after it's finished. Most products in this space treat context as something you write down once, which is why the teams using them will never keep up. Context has to move at the pace of the business, and the only way that happens is if the people who hold it and the agent that needs it maintain it together, inside the work.

That is what Orion’s Observatory is for. It continuously identifies context gaps, ambiguous definitions, and unverified assumptions as users interact with the data. It surfaces them in real time: "I noticed this ambiguity while running this analysis. Is this assumption correct?" A domain expert answers it once, and Orion incorporates that verified logic into its context layer.

This is what we call self-healing context. When we described it at dbt Summit, people got it immediately. The appeal wasn't the term. It was the realization: I don't have to launch a massive documentation project. The system simply involves me at the exact moment my expertise is needed.

Analytics is multiplayer

The industry is still trapped in the paradigm of a single human asking a single AI a question. But real analytical work is inherently collaborative.

A finance lead holds one piece of the puzzle. An analytics engineer holds another. Someone from operations casually notes, "Oh, that metric only applies to active production lines," and suddenly a critical piece of business context emerges that was never written down anywhere.

This is why Orion uses Rooms: collaborative spaces where multiple team members and Orion work together. Orion brings its analytical workspace, notebook environment, and governed organizational context to the table. It listens to the team doing their normal work, asks clarifying questions when context is missing, executes analyses, and contributes actionable insights.

That feels much less like a search box and much more like a teammate.

The data team's job is evolving

The biggest insight from dbt Summit wasn't technical; it was organizational.

When generating basic SQL and raw charts becomes cheap, deciding which analyses can be trusted becomes exponentially more valuable. The data team’s highest-value role is shifting away from manually answering every ad-hoc question. Instead, data teams are becoming Context Engineers, defining the trusted surface area of metrics, business logic, constraints, and source-of-truth models that AI systems can safely deploy.

The AI can then instantly handle the routine, governed questions through fast, constrained paths, while reserving broader exploratory capabilities for complex scenarios.

That shift also clarifies what the data team should not be spending its time on: building the platform itself. The teams I described earlier, the ones who pointed an advanced LLM at a warehouse and added some documentation, are effectively doing exactly that. It's impressive work, and it is also a second product, with its own roadmap, maintenance burden, and support queue. Every hour that goes into it is an hour not spent helping someone in the business make a better decision. The data team's job is to produce insights and support the people who need them. Owning the trusted surface is that job. Building and operating the agent platform is not.

I came home from dbt Summit convinced that the market has finally arrived at the exact problem we’ve been obsessing over for two years. The question for 2026 is no longer "Can an AI query my data?" Of course it can. The real question is whether you can turn that capability into something your organization can actually stake its business on.