Introduction
Ask an enterprise data agent a simple question, “show me last quarter’s pipeline from AmEx accounts”, and watch three things go wrong at once. The agent searches for “AmEx” in the account name column and finds nothing, because the data stores “AMERICAN EXPRESS COMPANY” and there’s no substring overlap. It interprets “last quarter” relative to the system clock instead of the actual date range in the data. And “pipeline”, a term every salesperson uses daily, doesn’t map to any single column, because it’s a set of stage codes that no one thought to enumerate in the schema.
None of these are model failures. The LLM is reasoning correctly over what it can see. The problem is that what it can see, schema, column names, maybe some metric definitions, isn’t enough to bridge the gap between how people talk about their business and how the data actually stores it.
This is the context problem. And it’s why the emerging category of “context layers” for data agents matters far more than most enterprise teams realize.
The Market is Converging,
but on Different Ideas of "Context"
The data infrastructure landscape has been reorganizing around a central question: what do AI agents need to reason correctly over enterprise data? The answers are splitting into three camps.
The first camp focuses on metric governance, standardizing how measures and dimensions are defined so that agents generate consistent SQL. This is the world of dbt metrics, Cube, AtScale, and increasingly Snowflake’s semantic views. It solves an important problem: two agents asking the same question should get the same number. But governed metrics tell the agent what to calculate, not what the values mean, what the organization already knows about them, or how a conversation is evolving.
The second camp focuses on metadata curation, cataloging, tagging, surfacing lineage and trust signals so agents can find the right data. Atlan’s Context Engineering Studio and Promethium sit here. This helps agents discover data, but discovery isn’t reasoning. Knowing that a table exists and has a freshness score doesn’t help the agent resolve “AmEx” to a canonical name.
The third camp, where Timbr operates, starts from ontology: a formal model of what things are, how they relate, and how they inherit properties from one another. An ontology doesn’t just define metrics; it defines that a High-Value Customer is a Customer, that Customers have Accounts, that Accounts have Transactions, and that the agent can traverse that hierarchy in standard SQL. It provides the grammar of reasoning, not just the vocabulary.
But here’s the honest admission that makes Timbr’s latest release interesting: even a well-built ontology isn’t the complete picture. It gets the agent thinking in the right concepts, but three gaps remain between thinking and answering correctly.
The Three Missing Layers
Timbr has long provided two foundational capabilities: an SQL-native ontology that virtualizes business concepts across any data warehouse, and LLM-agnostic data agents that generate governed SQL over that ontology. What’s new is the recognition that these foundations, while necessary, leave three specific kinds of context unaddressed.
Value context, what concepts look like in the actual data. The ontology says “Account.” The data stores “AMERICAN EXPRESS COMPANY.” Without grounding the former to the latter, natural language stays disconnected from stored values.
Organizational context, what the team has already figured out. The vetted query an analyst perfected last week lives in a Slack thread. The next agent that encounters the same question regenerates the SQL from scratch, often differently, sometimes with a different result.
Conversational context, what the user just said. Each follow-up forces the user to restate context. Most multi-turn implementations dump raw chat history into a single LLM call and hope for the best. Quality drops as the conversation grows.
Timbr’s new release adds a dedicated capability for each.
Technical Context:
Not Every Column Deserves the Same Prompt
The first addition, Technical Context, tackles value grounding. Most systems treat all columns uniformly, whether by surfacing everything or hiding everything behind metadata. This is the root cause of most grounding failures.
Timbr automatically analyzes the ontology and determines, per column, what the agent should see, how it should interpret it, and what should be kept out of the prompt entirely. The result is prompt construction that’s intelligent at the column level: the agent sees exactly what it needs to ground its reasoning, nothing that would mislead it, and nothing that would bloat the context window with irrelevant data.
Knowledge Base: A System that Compounds What the Organization Already Knows
The second addition addresses a problem that gets worse as data teams mature. Vetted queries, KPI definitions, and edge-case resolutions accumulate in notebooks, wikis, Slack threads, and institutional memory that walks out the door when someone changes roles.
Native warehouse agents have recognized this need. Databricks Genie supports verified examples and instructions; Snowflake Cortex Analyst offers a verified query repository. Both are meaningful capabilities for single-platform environments.
Timbr’s Knowledge Base is scoped per ontology rather than per warehouse, so a single knowledge base serves teams whose data spans multiple platforms. It’s also portable across LLM providers, the same organizational knowledge works regardless of which model powers the agent.
The key design principle: the system gets smarter with use. Every question answered strengthens its ability to handle the next one. Organizational intelligence compounds into a durable asset rather than remaining an ephemeral byproduct. And every response is gated by validation, access control, and a full audit trail.
Conversational Memory:
Separating Classification from Generation
The third addition confronts a problem anyone who’s tested data agents beyond a demo has encountered. Multi-turn conversations degrade. The first question works. The follow-up usually works. By the third or fourth turn, the agent starts losing context, conflating threads, or contradicting itself.
This happens because most implementations ask a single LLM call to do too many things at once: determine intent, generate SQL, and formulate the answer. That works for two or three turns, then breaks down.
Timbr decomposes multi-turn reasoning into specialized stages, each with access to the ontology’s semantic structure and each receiving only the context relevant to its task. The result: users can interleave topics freely, follow-ups extend prior queries rather than regenerating them, and the full dialogue remains auditable.
An Honest Comparison with Warehouse-Native Agents
Databricks AI/BI Genie and Snowflake Cortex Analyst are strong products. They require zero additional deployment if you already live on their respective platforms. For a handful of tables, a few KPIs, and one team’s questions, they work well, and the fact that they’re embedded in the platform is a genuine advantage.
But they get harder as scope grows. Past roughly five or six tables, join complexity multiplies and semantic-file rewrites start to compound. Their verified-query mechanisms are flat exemplar lists, useful, but they don’t compose across teams or topics. The semantic surface is locked to the vendor’s format and the vendor’s hosted LLM. And they’re single-platform by design: Genie reasons over Databricks, Cortex Analyst reasons over Snowflake. Neither reasons over both at once, let alone across SAP or Oracle.
Timbr’s tradeoff is real and should be stated clearly: it’s an additional layer to deploy and govern. It’s not free. It requires investment in ontology modeling (now automatically generated) and knowledge base curation. These are not trivial costs, and for teams with simple, single-platform needs, the native agent is likely the right starting point.
The payoff is that Timbr doesn’t cap out. An ontology with inheritance and transitive reasoning handles hundreds of concepts without the per-table scaling pain. One model spans analytics, operations, and supply chain without per-YAML or per-cube rewrites. The knowledge base compounds across teams. And the entire stack is portable, across warehouses, across LLM providers, across the organizational changes that enterprise environments inevitably undergo.
The Question that Matters
Most enterprises will encounter data agents through their warehouse vendor first. That’s natural, and for many use cases it’s sufficient. The question that distinguishes a tactical deployment from a strategic one is: what happens when the scope expands?
When the second warehouse arrives. When the fifth team onboards. When an agent needs to reason across SAP and Snowflake in the same query. When the analyst’s vetted query from six months ago needs to surface automatically instead of being reinvented. When a conversation that started with revenue needs to pivot to customer segmentation and back without losing the thread.
That’s when the context layer stops being an add-on and becomes the architecture. And that’s the layer Timbr is building, ontology as the foundation, with value grounding, organizational knowledge, and conversational memory completing the picture.
The context isn’t optional. It’s the difference between a data agent that demos well and one that an enterprise can actually trust.
See It in Practice
Explore how Timbr’s ontology-based semantic and context layer give data agents a governed understanding of your business across Databricks, Snowflake, SAP, and beyond.
