Introduction
Knowledge bases used to be built for people.
They stored documentation, FAQs, internal wikis, support articles, policy pages, the kind of thing a person opens, skims, and decides how to apply. The entire design assumes a human reader on the other end: someone who can interpret ambiguity, judge relevance, and translate a paragraph of text into an action.
Data agents don’t read that way. An agent doesn’t open a wiki page and decide what it means for the question in front of it. It needs governed knowledge it can use in the middle of reasoning, before it writes a query and before anything touches enterprise data.
So the term “Knowledge Base” needs a different definition for a different kind of reader. Not a place to look something up, but a governed record of what an organization has already approved, structured so an agent can retrieve it and use it the moment a similar question arrives.
That is why Timbr is introducing Knowledge Base for Data Agents, a new Timbr Core capability that gives enterprise data agents governed memory over approved examples, business rules, query patterns, and analyst guidance. It’s built directly on top of Timbr’s ontology-based semantic layer, so the agent isn’t just recalling disconnected examples. It’s using approved knowledge in the context of the same business concepts, relationships, and governance rules that already define how enterprise data should be accessed.
Why Memory Matters for Data Agents
Most data agents today can already handle the first part of the job: generating SQL that runs. But production readiness depends on something more specific: whether the answer reflects what the business has already agreed is correct.
A query can be technically valid and still be wrong, if revenue here means completed orders only, if the approved date field isn’t the one the agent picked, if a finance team already signed off on a specific metric definition, or if an analyst corrected this exact join path last month because the obvious version double-counted customers.
None of that lives in a table schema. It lives in the way the organization actually uses its data, and in most companies, that knowledge is scattered across Slack threads, wiki pages, dashboard filters, saved queries, and analyst experience that walks out the door when someone changes roles. When a new question arrives, the agent either has to rediscover that logic from raw tables, or the answer quietly drifts from what the business actually meant.
Timbr’s Knowledge Base changes where that knowledge lives.
Meaning and Usage Are Not the Same Thing
Timbr’s ontology-based semantic layer already defines what the data means. It models business concepts like Customer, Order, Invoice, and Revenue, how they relate to each other, which measures are valid, and how access should be governed. That gives an agent a structured business model to reason over, instead of forcing it to guess from tables and column names.
But meaning and usage aren’t the same thing. The ontology answers what the data means. The Knowledge Base answers how the organization actually uses that meaning, the approved way teams ask about revenue, the SQL patterns analysts have already validated, the default filters and rules that clarify a measure beyond its structural definition.
The ontology gives an agent structural truth. The Knowledge Base gives it interpretive memory, built from real, approved work rather than reconstructed from scratch every time a similar question comes up.
What It Stores
Timbr’s Knowledge Base isn’t a general-purpose document store. It’s a governed memory layer for the specific kinds of knowledge a data agent needs before generating SQL.
That includes approved question-to-SQL examples, real business questions paired with SQL that’s already been reviewed and validated. These aren’t just saved queries. Each one carries the reasoning behind it, which filter mattered, which join was preferred, and why a particular version was the one the business signed off on rather than an equally plausible alternative.
It includes preferred query patterns, the joins, filters, groupings, and metric logic an organization wants reused whenever a similar type of question comes up, even when there’s more than one technically valid way to write the query.
It includes business rules and analyst guidance, the practical instructions that usually live in someone’s head: revenue means completed orders only, default to the last twelve months unless specified, use the finance-approved version of this metric rather than the operational one. This is often the most valuable and hardest to formalize category, because it’s rarely written down anywhere until it’s captured this way.
And it can include guidance attached directly to ontology objects, concepts, measures, relationships, or views, so a piece of the ontology can carry its own usage notes rather than relying on the agent to infer them fresh each time.
None of this floats free of the data model. Every entry is scoped to the ontology it belongs to, so what an agent retrieves stays connected to the same governed business context it’s meant to support, not a loose pool of examples with no relationship to the concepts they’re supposed to inform.
How It Fits Into the Agent's Workflow
Timbr’s Knowledge Base sits before SQL generation, not after it. When a question comes in, the agent checks the Knowledge Base for relevant approved context, a similar question that’s already been validated, a business rule that applies, guidance attached to a concept the question touches, and that context shapes how the agent approaches the question before it writes anything.
From there, the request still gets grounded in Timbr’s ontology. The Knowledge Base can guide the agent, but it doesn’t bypass governance, the concepts, relationships, and permissions involved still have to align with the ontology before any SQL executes. That’s the core design principle behind the whole system:
The Knowledge Base suggests. The ontology decides. Timbr executes with governance.
This lets the agent stay flexible in how it interprets a question, while keeping what actually runs against enterprise data controlled by the same semantic layer every other query goes through. And because approved outcomes can flow back into the Knowledge Base after the fact, the system doesn’t just apply memory, it accumulates it, so the next similar question has slightly more validated context to draw on than the last one did.
A Simple Example
Take a question like “how did we perform in Q4?”
Without organizational memory, an agent is guessing at your conventions. It might interpret “performance” as raw revenue, use whatever date field looks closest to a quarter boundary, and return a number that’s plausible but not the one your organization actually reports on.
With Timbr’s Knowledge Base, the agent isn’t guessing. It retrieves the approved example for this kind of question, the definition that performance means completed-order revenue, not raw revenue, and the selection rule that defaults to your fiscal calendar rather than the standard calendar year. The agent generates SQL that encodes how your organization actually answers this question, and Timbr validates and executes it through the governed ontology layer. Same question, same agent, a different and more trustworthy answer, because this version is built on what the organization already knows instead of what the agent had to guess.
What This Changes for Enterprise Teams
The value shows up most in the situations data teams deal with constantly, not in a single clever demo question.
An analyst’s correction or approved query pattern usually lives and dies in one conversation. With a Knowledge Base, it becomes reusable context the next time someone asks something similar, whether that’s the same analyst next quarter or a different team entirely.
Terms like revenue, active customer, or churn often carry meaning specific to one organization, interpreted slightly differently across teams. A Knowledge Base gives those definitions one governed home, so an agent applies the same interpretation regardless of who’s asking.
And for governance teams, the appeal is control as much as speed. Approved examples and rules can move through a lifecycle: reviewed, approved, updated, or deprecated, giving teams a structured way to let agents reuse institutional knowledge without losing oversight of what it actually says.
Memory Still Needs Governance
Memory only helps if it’s governed. An agent that reuses old logic without checking it will reuse a bad answer exactly as confidently as a good one, so Timbr’s Knowledge Base is built inside the same governed environment as the ontology, not as a loose store of examples or disconnected chat memory.
Those entries remain governed over time, and any SQL generated using Knowledge Base context still runs through Timbr’s governed execution layer before it touches live data. Trust here doesn’t come from the agent sounding confident. It comes from knowing that business meaning, approved usage, and access controls are all enforced before a query runs, not after.
A Product Milestone for Timbr
Production data agents need three things to be trusted with real enterprise work: they need to know what the data means, they need to operate inside real governance, and they need to remember what the organization has already validated.
Timbr’s ontology already delivered the first two, meaning through the semantic layer, governance through the execution boundary every query runs through. Knowledge Base for Data Agents adds the third. With this release, Timbr Core brings meaning, governance, and memory together in one governed system, so a data agent isn’t just answering a question correctly once. It’s building on what the business already trusts, every time it’s asked again.
Because enterprise data agents shouldn’t start from zero every time. They should build on what the business already knows.
