Lakehouse as Context Store

Most teams adopt a lakehouse to store and query analytical data. We found a second role for ours: it became the shared context layer behind Altertable’s agentic features.

Our production Postgres database is connected to Altertable. Logs and traces are ingested into it. Product events land there too. We also upload company knowledge: product documentation, internal definitions, runbooks, and the context our team uses to interpret what the data means.

This gives the agent two things that are usually kept separate: live evidence of what happened and company-specific knowledge about how to interpret it.

The agent is accessible through our "Ask Agent" feature and a Slack bot, but the chat surface is the least interesting part. What matters is that the agent does not begin with a collection of disconnected tools. It begins with a shared, queryable picture of the business.

Many useful questions are cheap to state and expensive to answer.

Did this customer ever use the feature they asked about? Are other users seeing the same error? Is the problem isolated to one organization, browser, deployment, or account plan? What happened immediately before this account churned?

Answering one of these questions may require customer records from Postgres, product events, logs, traces, billing data, feature definitions, deployment history, internal documentation, and someone’s memory of what a feature is called internally.

A typical bug investigation might look like this:

1. Find the user and organization in the production database.
2. Locate the relevant product events and session.
3. Use a request or trace ID to find the backend execution.
4. Inspect the associated logs and error.
5. Compare the result with browser, deployment, plan, and feature configuration.
6. Check the documentation or runbook to understand the expected behavior.

None of these steps is especially difficult. The cost comes from moving between systems, translating identifiers, aligning timestamps, and keeping the developing explanation in your head.

For a serious incident, that work is justified. For everyday product curiosity, it is often too much friction.

So the questions die before being asked.

A tempting solution is to connect every system directly to an agent through MCP. Give Claude or Codex tools for Postgres, logs, product analytics, support tickets, issue trackers, dashboards, and internal documentation.

We use MCP, and it is a useful standard. It answers an important question:

How can an agent call this system?

It does not answer a different question:

How do the systems relate to one another?

An MCP server for Postgres and an MCP server for logs expose two sets of capabilities. They do not create a shared identity model between users in Postgres and sessions in the logs. They do not establish that an internal feature name corresponds to three product events and a particular backend service. They do not reconcile timestamps, permissions, deployment versions, or conflicting definitions.

When a question crosses several systems, the agent still has to discover which tools to call, understand different schemas and APIs, move identifiers between them, paginate through results, retry failed requests, and reconstruct relationships that were never represented explicitly.

At that point, the model is not primarily reasoning about the business. It is rebuilding data integration at inference time.

That can work for occasional tasks. It becomes slow, expensive, and brittle when the same relationships must be rediscovered for every investigation.

Tools remain useful for taking actions and reaching systems that should not be centralized. But recurring analytical relationships should not have to be reconstructed from scratch inside the model’s tool loop.

The integration belongs beneath the agent.

A useful context store has two parts.

The first is a map: business definitions, internal terminology, entity relationships, event taxonomies, product documentation, runbooks, and known failure modes.

The second is evidence: customer records, product events, logs, traces, deployments, billing data, and the other live records of what actually happened.

A warehouse is good at querying evidence, but it may know very little about what a feature means, which metrics the company trusts, or how internal terminology maps to tables and events.

A vector database can retrieve relevant documents, but it is a weak foundation for joining users to organizations, correlating requests with traces, filtering by deployment, or aggregating behavior across millions of events.

An agent needs both.

Consider the question:

Did this customer use the new export feature before reporting that it was broken?

The agent may first need to retrieve documentation explaining that the feature is called “bulk export” externally but export_v2 internally. It may need to learn that successful usage produces one event, failed attempts produce another, and both include a request ID.

It can then resolve the customer to an organization, query the relevant events, correlate the request IDs with traces and logs, and check which deployment and browser were involved.

Retrieval helps the agent form the right query. Structured data lets it verify the answer.

Without the map, the agent may query the wrong events or misunderstand what “use” means. Without the evidence, it can only repeat what the documentation says should have happened.

In our implementation, uploaded company knowledge provides the map through retrieval and a knowledge graph. The operational lakehouse provides the evidence. The agent can move from a vague business question to the relevant concepts, records, and relationships, then show the data behind its answer.

Traditional analytics infrastructure assumes a relatively bounded workload: dashboards execute known queries, analysts investigate higher-value questions manually, and observability tools serve human operators through specialized interfaces.

Agents change that workload.

A single investigation may involve several retrieval steps, schema inspections, SQL queries, comparisons, and follow-up questions. Monitoring agents may repeat similar work continuously across customers, deployments, or product areas.

Software can now generate and pursue questions at a much higher frequency than humans. If every new question requires another integration, search index, prompt instruction, tool call, or human handoff, the cost of assembling context grows with the number of questions.

Better models do not fix missing relationships between identifiers. They do not resolve conflicting business definitions or make stale copies current. They may become better at navigating fragmented systems, but the fragmentation remains part of every request.

At that scale, the bottleneck moves from generating a query to determining what should be queried and how the result fits together.

The goal is not to put every system into one physical database or replace every specialized tool.

It is to stop rebuilding the same context for every question.

Operational data can remain in source systems and be queried through federation. Events, logs, and traces can be ingested when repeated analysis makes local storage useful. Documents and definitions can be retrieved alongside structured data. Sensitive actions can remain behind narrow, permissioned tools.

What matters is that the important relationships between these systems are represented somewhere durable:

• users belong to organizations
• organizations have plans and feature configurations
• product events correspond to product concepts
• requests connect to traces and deployments
• customer-facing terminology maps to internal names

These relationships are what turn a collection of records into an explanation.

Once they exist in a shared context layer, an agent no longer needs to reconstruct the business from scratch every time someone asks a question. It can use company knowledge to determine where to look, query the live evidence, and show how it reached its answer.

That is how we now use Altertable internally. The lakehouse is still where we query operational and analytical data. But it has also become the place where data, definitions, and operational history meet.

The practical result is simple: more questions get asked.

Not because every question suddenly matters more, but because finding the answer no longer requires opening six tools and assembling the story by hand.

The infrastructure challenge is making those questions cheap enough to ask; and the answers grounded enough to trust.