Timbr Data Agents now run natively on Databricks. The ontology is surfaced through Unity Catalog as standard catalogs and schemas, browsable in the Databricks UI alongside native tables and queryable from any Databricks-connected tool. Execution stays on Databricks SQL warehouses, there’s no separate compute footprint to provision or govern. Unity Catalog permissions, row-level security, and SSO are honored end-to-end, so the agent inherits the user’s clearance rather than brokering around it.
The integration is additive, not replacement. Timbr concepts and governed measures can be exposed to Genie as semantic context, or consumed by the Mosaic AI Agent Framework as a tool, so the Databricks-native agents get ontology-grounded context instead of reasoning from schema alone. For organizations already invested in the Databricks agent stack, Timbr extends what those agents can answer reliably. For organizations whose scope extends beyond Databricks, the same agent can reason across the broader business ecosystem through the same ontology.
Introduction
Databricks has established itself as one of the most capable data platforms available today. Built on Apache Spark, powered by Delta Lake, and governed through Unity Catalog, it gives organizations the infrastructure to store, process, and manage data at enterprise scale. Teams use it to run pipelines, power analytics, and increasingly, to serve as the foundation for AI initiatives.
That last use case is where things get complicated.
As organizations move toward AI agents, natural language querying, graph-based retrieval, and digital twin modeling, Databricks is becoming the foundation these systems run on. The question is no longer whether you can run AI on your data. It’s whether the data carries enough meaning for that AI to work correctly.
That gap matters more than most organizations realize until they are already deep into an AI project.
The Problem with Tables and AI
In a typical Databricks environment, data is well-organized but not well-understood. Tables represent systems, not business concepts. Relationships between entities exist as JOIN logic written into queries, not as reusable definitions that carry meaning across the organization. Business rules are embedded in pipelines. Metric definitions still fragment when scope crosses warehouses, teams, or non-Databricks systems.
For an analyst who knows the data well, this works. The knowledge lives in their head and in the SQL they write. For an AI system, it is a fundamental obstacle.
When a large language model or an AI agent attempts to interact with Databricks data directly, it has no access to that implicit knowledge. It sees column names and table schemas. It tries to guess relationships from naming conventions. It generates SQL that may execute without errors but does not reflect the intended business logic. The result is SQL that runs but doesn’t answer the question.
The problem is not Databricks. The problem is that the data layer alone does not carry enough meaning for AI to reason over reliably.
What AI Actually Requires
To answer even a straightforward question like “What is total revenue by customer segment this quarter?”, an AI system needs more than access to the right tables. It needs to know what revenue means in this organization, how customers relate to transactions, which joins are valid, which filters define a segment, and which metric definition is the authoritative one.
In most Databricks environments, all of that exists somewhere. It is in views, in pipeline code, in dashboard definitions, and in documentation that may or may not be updated. It is distributed, inconsistent, and entirely implicit. There is no single layer where business logic is formally defined and consistently available to every consumer, whether human or AI.
That is the gap. And it is not a gap that more data or faster processing closes. It is a semantic gap, and it requires a semantic solution.
What Databricks Already Offers, and Where the Gap Remains
Databricks has made major investments in AI capabilities, including Genie (NL2SQL over governed metrics), Unity Catalog Metric Views (governed measures/dimensions), Verified Queries (pinned trusted SQL), Instructions (model guidance), Mosaic AI Agent Framework (custom agents), AI/BI Spaces. Together, these capabilities give organizations a powerful platform for building and scaling AI agents on top of Databricks.
For a single team, a handful of well-modeled tables, and a Databricks-only stack, this works. The question is what happens when scope crosses that line.
Every agent, regardless of how advanced the orchestration, ultimately queries the underlying data. And that data is still stored as tables, with implicit relationships, scattered metric definitions, and business logic buried in pipelines or tribal knowledge.
When an agent is asked something like “revenue by customer segment this quarter,” it still has to interpret what “revenue” means, reconstruct which joins are valid, and decide which definition to use.
That is the gap. And it is not one that Databricks’ agentic tools, powerful as they are, are designed to fill.
Grounding Concepts to Actual Values
Even a perfectly defined semantic concept doesn’t help if the agent can’t map a user’s phrase to the literal stored in the data.
A question about “AmEx” needs to resolve to “AMERICAN EXPRESS COMPANY”, not a substring search that returns nothing. “Last quarter” needs to become an explicit date range based on the actual min and max dates in the column, not a guess against the system clock. “Pipeline” needs to expand into the specific set of stage codes that define it, not a single string match.
Timbr’s Technical Context engine handles this by classifying every column from statistical evidence – cardinality, length, pattern, distribution – and assigning a semantic type: categorical text, code-like, business key, surrogate ID, numeric measure, date, or free text.
Each type gets a matching grounding strategy. Codes are matched strictly. Free text is guarded to prevent context flood. Surrogate IDs are hidden from the model entirely so it can’t invent joins on them. Dates resolve against real ranges in the column. This is the layer that turns the agent’s guess into a sourced answer, and it’s the layer that governed metrics alone don’t provide.
Adding Ontology-Based Context to Databricks
That semantic foundation is what Timbr provides, by embedding an ontology-based semantic layer directly into the Databricks Lakehouse. Rather than replacing Databricks or duplicating data, Timbr sits above the existing infrastructure, connecting to Unity Catalog, executing queries on Databricks clusters, and exposing a governed, queryable model of business concepts, relationships, and metrics. And critically, that model is not limited to Databricks. Timbr can connect business meaning across the broader business ecosystem, giving AI agents a unified view of concepts, relationships, and measures instead of an isolated view of one platform.
That portability runs in both directions. The same ontology spans Databricks alongside Snowflake, SAP, and on-prem systems through virtualization – no ETL, no duplicated semantics per warehouse. And the agent itself isn’t bound to any single model provider. Teams can run it on OpenAI, Anthropic, Google, Databricks-hosted models, or Cortex, and switch as the model landscape shifts. The semantic foundation stays stable while the stack underneath, both data and model, can change without rebuilding it.
The shift this creates is significant. Instead of tables with implicit relationships, data engineers define explicit business concepts such as Customer, Product, Transaction, and Contract, and connect them through formal relationships that replace JOIN statements entirely. Instead of metrics scattered across notebooks, measures are defined once in the semantic model and inherited across concept hierarchies, ensuring consistency whether the data is being accessed from a Databricks notebook, a BI tool, or an AI interface.
The difference becomes meaningful as scope grows. Metric Views and verified queries work well for a handful of tables and a single team’s KPIs. Past five or six entities, joins multiply and definitions start to fragment – the same logic gets restated in multiple metric views, and there’s no mechanism to factor what’s shared.
Timbr ontologies inherit. A measure defined on Customer is automatically available on EnterpriseCustomer and RetailCustomer. A relationship defined once is traversed by name, not redeclared. Multi-hop paths – customer to order to product to supplier – are walked natively instead of hand-coded into every prompt. This is what lets a single semantic model cover hundreds of concepts across analytics, operations, and supply chain without per-domain rewrites.
Getting there does not require a manual migration. Timbr uses LLM-powered auto-mapping to scan existing Unity Catalog tables, generate ontology definitions, and establish data source connections automatically. What would otherwise be weeks of modeling work becomes a starting point that teams can refine rather than build from scratch.
Once the semantic model is in place, Timbr queries it through virtualization by default. This means data stays in its original location inside the Lakehouse, queries are executed live against Databricks clusters, and there is no risk of working from a stale copy. The semantic layer reflects the current state of the data at all times.
For workloads where live querying is not fast enough, Timbr also includes a four-tier caching engine that allows specific semantic views to be materialized, stored in memory, on SSD, in a data lake, or in a local database, depending on performance requirements. The important distinction is that this is not a forced trade-off. Teams are not required to choose between keeping data fresh and keeping queries fast. Virtualization handles accuracy. Materialization handles performance. Both operate within the same governed semantic model, and teams decide where each workload sits based on what it actually needs.
What This Enables for AI
A governed semantic layer makes the difference between AI use cases that work reliably and ones that don’t, and it directly affects the outcomes that matter most to enterprise data teams right now.
Databricks supports verified queries — trusted SQL pinned to the semantic model as exemplars. Timbr extends that pattern into a three-tier cascade. Tier one is direct reuse: if a vetted, approved answer already exists for this question, the agent returns the SQL the organisation has already trusted, with no regeneration. Tier two is exemplar guidance: closely related prior work is injected as few-shot context, guiding generation toward proven patterns instead of inventing new ones. Tier three is cold generation: no precedent exists, so the agent reasons over the ontology alone – still governed, still validated – and the new answer enters the knowledge base for next time.
Every tier is gated by the same four checks: ontology path validation, parameter schema match, RBAC clearance, and audit trail. The knowledge base grows the more it’s used. Approved answers become tomorrow’s context. Reviewer corrections become signal. What today lives in Slack threads and individual analyst heads becomes operational memory the agent can actually find.
Conversational Memory: Most multi-turn implementations pass the conversation history into a single LLM call alongside SQL generation. It works for two or three turns. Past that, one prompt has to hold three reasoning loops at once – is this a follow-up, what’s the SQL, how do I phrase the answer – and quality degrades on all three. Topic pivots (“orders” to “products”) blur with genuine follow-ups (“now in 2022”).
Timbr separates the concerns. A dedicated classifier runs first. It sees the ontology’s concepts, so it can distinguish a topic pivot from a genuine follow-up — something text matching alone routinely misses. It returns three things: whether this is a follow-up, which prior message is the direct parent, and a ranked list of relevant prior turns.
The downstream chains then receive what they actually need. SQL generation gets the structural ancestor chain via parent_query_id – so “now in 2022” is built from the parent query’s structure with the new filter swapped in, not regenerated from scratch. Answer phrasing gets the classifier-ranked Q&A pairs, so the agent doesn’t repeat itself or contradict its earlier framing. The full conversation graph is persisted to disk, so every follow-up is auditable.
Natural language querying becomes reliable when AI systems have access to explicit business concepts and defined relationships. Instead of attempting to infer meaning from schema, a language model can query the semantic model with confidence that the concepts it references, such as revenue, customer, and segment, are consistently defined and correctly connected. Hallucinated joins and inconsistent metric calculations stop being an accepted risk. Timbr exposes the semantic model through standard interfaces, including LangChain, LangGraph, LlamaIndex, and MCP, allowing AI agents to interact with governed business data directly rather than working against raw tables and schema.
GraphRAG and graph-based retrieval benefit from the same foundation. When data is organized into a formal ontology with typed relationships and inherited properties, retrieval systems can navigate the knowledge graph with precision, following relationships rather than guessing connections. The structure that Timbr creates is not incidental to AI retrieval. It is the structure that makes retrieval meaningful.
Digital twin use cases, which require an accurate model of how real-world systems relate to one another, depend on exactly the kind of formal relationship modeling that an ontology-based semantic layer provides. Timbr allows organizations to model complex domains such as assets, processes, organizational structures, and supply chains as interconnected business concepts that mirror real-world relationships rather than database schemas.
LLM benchmarking gives organizations a way to validate how well their AI is actually performing. Timbr’s benchmarking framework allows teams to test different language models against their specific business ontology, comparing how accurately each one interprets enterprise logic, generates correct queries, and returns consistent answers. Instead of assuming an AI agent is working correctly, organizations can measure it against a defined semantic standard and make informed decisions about which models are fit for production use.
The common thread across all of these is simple. AI does not fail because of insufficient data. It fails because the data it has access to does not carry enough explicit meaning to reason over consistently. The semantic layer is what changes that.
Governance That Scales with the Model
One of the practical advantages of embedding the semantic layer within the Databricks ecosystem is that governance does not have to be rebuilt from scratch. Timbr integrates natively with Unity Catalog, exposing semantic concepts as Databricks catalogs and schemas, applying row-level security and permissions harmoniously with existing governance policies, and enabling SSO so that access controls remain aligned across both environments.
This matters for AI use cases in particular. As AI agents and automated systems gain access to enterprise data, the question of what they can access and under what conditions becomes critical. A semantic layer that enforces governance at the model level, rather than relying on downstream enforcement alone, provides a much stronger foundation for responsible AI deployment.
Conclusion
Databricks gives organizations a powerful platform for processing data, governing it, and increasingly, running AI on top of it. But running AI and running AI correctly are two different things. As AI becomes central to how enterprises operate, that distinction becomes the difference between an AI strategy that works and one that keeps falling short.
Timbr provides that meaning. By transforming Databricks and related business data into governed concepts with explicit relationships, measures, and reusable logic, Timbr gives AI agents a stable business model they can reason over accurately, consistently, and at scale.
Want to see what this looks like in practice? Explore how Timbr integrates with the Databricks Lakehouse, how ontologies are surfaced through Unity Catalog, or the Databricks Semantic Layer use case.
