For a long time, data stacks were built for questions companies already knew they wanted to ask.
Revenue by segment. Activation by cohort. Usage by plan. Pipeline by stage.
Those questions deserved pipelines, models, dashboards, and recurring reviews. The stack was built for repetition.
AI changes the shape of demand.
The next wave will not be ten more dashboards. It will be thousands of smaller, messier questions asked by humans, applications, and agents as work happens:
- Why did this account go quiet after onboarding?
- Which customers look ready to expand?
- What changed after the latest release?
- Where does product usage disagree with the CRM?
These questions cut across systems. They need live data, definitions, product knowledge, account history, permissions, and relationships between objects. They need context.
That is why the lakehouse is evolving from an analytical destination into a context store.
Data is abundant. Context is scarce.
Most companies already have the data. The problem is that meaning is scattered across tools.
The same customer may appear in product events, application tables, billing, CRM notes, support tickets, logs, and docs. One table can show usage dropping. Another system can explain that the champion left. A ticket can reveal an unresolved integration issue. A feature flag can explain why this customer behaves differently.
Individually, each source contains a fragment. Together, they explain what happened.
Today, people assemble that story manually. They open tabs, remember relationships, reconcile definitions, and paste the answer into Slack. AI can automate more of that work, but only if the context exists somewhere durable and governed.
An agent does not just need table access. It needs to know what the tables mean.
The lakehouse becomes the context layer
A context lakehouse brings operational data, analytical data, product events, telemetry, documents, definitions, and business relationships into one governed foundation.
That does not mean copying everything into one physical database. Some data should be stored directly. Some should stay where it is and be queried through federation. Some context comes from docs, runbooks, semantic definitions, lineage, or previous investigations.
The important thing is that relationships are represented somewhere durable:
- Users belong to organizations.
- Organizations have plans, contracts, limits, and feature flags.
- Events map to product concepts.
- Support issues connect to accounts, releases, and usage changes.
- Metrics have definitions, owners, and exceptions.
These relationships turn records into explanations. Without them, an AI system can generate SQL and still miss the business point. With them, the agent starts with a map.
The market is quietly moving here
The language across the market is starting to converge.
PostHog, long known for product analytics, now talks about a “context warehouse”: a place to combine product and business data, model it, query it, and give agents the context they need. The shift is telling. The category is moving beyond analytics as a product surface toward context as a foundation for AI.
Google Cloud is approaching the same idea from the enterprise side with its “borderless lakehouse”: data across clouds, operational systems, SaaS applications, catalogs, and governance layers, made accessible to agents without forcing everything through another copy pipeline.
SAP’s acquisition of Dremio may be the clearest enterprise signal. SAP framed the deal around unifying SAP and non-SAP data for agentic AI, with an Iceberg-native lakehouse, federated analytical reach, no required data movement or format conversion, and a shared layer for business context, meaning, access rights, and lineage.
Databricks Lakebase points in from another angle: the lakehouse is no longer only an analytical destination, but is expanding toward operational applications, transactional data, and agent memory.
Different products. Different buyers. Different architectures. Same direction.
The market is moving from analytics as a destination to context as infrastructure.
That reinforces Altertable’s original bet: the AI-native data platform is a federated, governed context foundation where operational data, analytical data, and business meaning come together.
- Federation matters because context does not live in one place.
- Governance matters because agents need safe paths to evidence.
- Lakehouse economics matter because the number of questions will keep growing.
- Business meaning matters because access to data is not the same as understanding it.
AI turns context into infrastructure
In the dashboard era, missing context was painful but survivable. A human analyst could compensate with memory, meetings, and institutional knowledge.
In the AI era, missing context becomes a platform problem.
If an agent is expected to investigate revenue movement, prioritize accounts, explain product behavior, or monitor operational changes, it cannot depend on tribal knowledge. It needs access to the same definitions, relationships, and evidence the business trusts.
This is why context cannot live only in prompts, notebooks, dashboards, or one-off agent memory. Those layers help, but they are too fragmented and too far from the source of truth.
The foundation has to sit closer to the data.
From data stack to context stack
The first wave of AI data products focused on natural language to SQL. Useful, but incomplete.
The hard part is rarely writing a query. It is knowing what should be queried, which definitions apply, what surrounding evidence matters, and whether the answer is trustworthy enough to act on.
A sales leader does not need “SQL in English.” They need to know which accounts deserve attention. A product leader does not need another chart. They need to understand why behavior changed. A CEO does not need more dashboards. They need the company to share one operating picture.
That is the context lakehouse: not a dashboard layer, not a prompt layer, not agent memory, and not another copy of the warehouse.
It is a governed foundation where company data and company meaning come together, so people, applications, and agents can ask better questions.
Why Altertable is built for this
Altertable started from federation and context, not from a legacy warehouse, BI surface, or agent wrapper. The platform is designed to bring operational data, analytical data, and business meaning into one governed runtime.
Teams can keep data closer to where it lives, query it with lakehouse economics, and give both people and agents the shared context they need to act with confidence. We have written before about using the lakehouse as a working context store and about how the warehouse vs lakehouse boundary is shifting under AI workloads. This post is the category thesis behind those pieces.
The future of data infrastructure will not be defined only by who stores the most data or runs the fastest benchmark. It will be defined by who gives the business the clearest context for action.
AI does not just need access to data.
It needs to understand what the data means.
