What Is a Knowledge Base
for Data Agents?
Definition, ontology context, and enterprise use cases
What Is a Knowledge Base for Data Agents?
A Knowledge Base for data agents is a governed memory layer that captures an organization’s approved SQL examples, query patterns, and business rules. Built on top of an ontology-based semantic layer, it acts as institutional memory for AI agents, helping natural-language-to-SQL (NL2SQL) tools generate more accurate, policy-compliant queries instead of starting from scratch every time.
In a traditional knowledge base, information is stored for people to search and read. A Knowledge Base for data agents is different. It is designed for AI systems that need to turn questions into governed data actions, including SQL generation, metric interpretation, join selection, validation, and answer generation.
The ontology-based semantic layer defines the structural meaning of the data: concepts, relationships, measures, and governance rules. The Knowledge Base adds the interpretive layer: how analysts actually ask questions, which SQL patterns have been approved, which filters or joins are preferred, and which business rules should guide the agent in context.
In simple terms: the ontology tells the agent what the data means. The Knowledge Base tells the agent how your organization uses it.
That distinction matters because most data agents fail when they rely only on schemas, generic LLM reasoning, or disconnected documentation. They may generate valid SQL, but still miss the organization’s approved definitions, preferred logic, access rules, or past corrections. A Knowledge Base is designed to close that gap by giving agents governed institutional memory scoped to the ontology, so every new question can draw on what the organization already knows.
Why Every Query Starts From Zero
Without a Knowledge Base, every natural-language question is answered as if it were the first one ever asked. A data agent may reason correctly over the ontology’s structure, but it has no memory of what already worked.
This creates a familiar pattern for data teams. An analyst asks a question, refines the SQL until it is correct, and shares the answer. A few weeks later, someone else asks a similar question, and the agent starts over. The approved logic, the preferred join, the exception that made last month’s number reconcile with finance: none of it carries forward.
Instead, that knowledge stays scattered across Slack threads, wiki pages, tribal habits, and the heads of a handful of analysts. When those people are unavailable, or when the question is phrased slightly differently, the organization pays the same cost again. A Knowledge Base for data agents exists to stop this cycle, so approved reasoning becomes something the agent can retrieve rather than something the organization has to reproduce.
Ontology vs. Knowledge Base
The ontology and the Knowledge Base solve two different problems, and confusing them is one of the most common mistakes when evaluating context layers for AI agents.
The ontology-based semantic layer defines what the data means. It models business concepts, the relationships between them, the measures that matter, and the governance rules that apply, all independent of how any one person happens to phrase a question.
The Knowledge Base defines how the organization uses that meaning. It captures the specific questions analysts have asked, the SQL patterns that were reviewed and approved, the joins and filters that are preferred in practice, and the rules that should guide an agent when a term is ambiguous or a metric has more than one valid interpretation.
| Layer | Main question | Role |
|---|---|---|
| Ontology-based semantic layer | What does the data mean? | Defines business concepts, relationships, measures, and governance rules |
| Knowledge Base | How does the organization use that meaning? | Stores approved examples, rules, query patterns, and ontology-level guidance |
| Data agent | What should I answer? | Retrieves context, generates SQL, and returns governed answers |
The ontology gives an agent structural truth. The Knowledge Base gives it interpretive memory. Together, they let a data agent move from a natural-language question to a governed, accurate answer without starting from zero each time.
What a Knowledge Base Stores
A Knowledge Base for data agents generally holds two kinds of memory, both scoped to the ontology rather than floating free of it.
The first is approved question-to-SQL examples. These are reusable patterns pairing a real natural-language question with SQL that has already been reviewed and validated. For example, if a business user asks “Show total revenue by month,” the approved example captures not just the correct SQL, but the right revenue definition, the required status filter, and any instructions explaining why the query should be written that way. When a similar question comes in later, the agent does not need to rediscover that logic. It can retrieve the approved example and reuse it directly, or use it as guidance for generating a new query.
The second is ontology-level guidance. This includes instructions, validation rules, and selection rules attached directly to ontology objects, such as concepts, properties, measures, relationships, cubes, or views. A revenue measure, for instance, might include guidance that revenue should include only completed orders unless the user asks otherwise. A customer relationship might include a selection rule telling the agent which join to prefer in a specific context. This kind of guidance tells the agent how a piece of the ontology should actually be used in practice, beyond what its structural definition alone can convey.
Together, these two forms of memory make the Knowledge Base concrete rather than abstract. It is not a general-purpose store of documents or conversations. It is a targeted memory of what has already been asked, approved, and refined, tied to the same business concepts the ontology defines.
How It Works
A Knowledge Base sits in the data agent’s pipeline before SQL generation, not after it.
The flow begins with a natural-language question. Before generating SQL, the agent consults the Knowledge Base to retrieve relevant organizational context, such as approved examples, preferred patterns, business rules, and prior guidance. This gives the agent access to the organization’s “how we use the ontology” knowledge before it attempts to answer.
From there, the question is mapped to the ontology. The agent grounds the request in governed concepts, relationships, metrics, and rules from the ontology-based semantic layer. This step ensures the answer is based not only on language similarity or past examples, but on the approved business structure of the data.
Once the question is grounded in the ontology, the agent can generate governed SQL using approved patterns and business rules. That SQL is then executed against the data source through Timbr’s governed layer, so access control, semantic validity, and execution rules remain intact.
Finally, approved interactions can flow back into the Knowledge Base. Over time, the Knowledge Base becomes stronger because successful examples, corrections, and usage patterns become reusable context for future questions.
In short: natural-language question, consult Knowledge Base, map to ontology, generate governed SQL, execute and learn. The Knowledge Base shapes the answer before SQL is generated, and the ontology keeps that answer grounded in governed business meaning.
Governance and Trust
A Knowledge Base should never let an agent blindly reuse old SQL just because it resembles the current question. Reused logic still has to pass through the same governance the ontology enforces for every other query.
This means proposed answers are checked against the ontology’s structure, validated against parameter schemas, and filtered by role-based access before they ever touch live data. The Knowledge Base suggests; the ontology decides. Queries only ever run through Timbr’s governed layer.
That distinction matters because a memory layer without governance is a liability, not an asset. An ungoverned Knowledge Base can just as easily reinforce a mistake as it can save time. A governed one stays reasoning-flexible at the input while remaining strict at execution, so nothing reaches enterprise data until it clears the ontology’s rules.
How a Knowledge Base Differs from Wikis, RAG, and the Semantic Layer
It helps to be precise about what a Knowledge Base for data agents is not, since several adjacent tools get described in similar language.
Wikis and documentation hubs store information for people to read and search. They are built around human comprehension, not machine retrieval scoped to a data model.
RAG document stores retrieve text chunks to help a language model generate a response. They are useful for unstructured text, but they are not built around approved, governed data logic or ontology-scoped concepts.
The ontology-based semantic layer defines governed business meaning: concepts, relationships, measures, and rules. It is the foundation, not a competing memory layer.
The Knowledge Base sits on top of that semantic layer. It captures how the organization actually uses that meaning in practice, through approved examples, preferred patterns, and usage guidance. It extends the semantic layer rather than replacing it, and it is built for data agents rather than for human readers or generic text retrieval.
Enterprise Use Cases
A Knowledge Base becomes valuable when data agents are expected to support real enterprise workflows, not just demos.
Governed NL2SQL. A Knowledge Base helps agents reuse approved SQL patterns and ontology-level guidance instead of generating every query from scratch, which reduces repeated mistakes and keeps generated SQL closer to logic the organization already trusts.
Analyst knowledge capture. When a senior analyst approves a query pattern or corrects a metric definition, that knowledge becomes reusable context instead of disappearing into a one-off conversation or Slack thread.
Consistent metric and KPI usage. Terms like revenue, active customer, or Q4 performance often carry local meaning. A Knowledge Base helps make that meaning retrievable and consistent across teams, rather than reinterpreted each time.
Governed reuse for governance teams. Approved examples and instructions can be reviewed, deprecated, and governed over time, giving governance teams a controlled way to let agents reuse organizational memory.
Broader agentic analytics. The same governed memory layer supports GraphRAG and BI copilots, giving them a more reliable foundation than generic model reasoning alone.
How Timbr’s Knowledge Base Works with the Ontology
In Timbr, a Knowledge Base is scoped to an ontology, so its memory stays connected to a specific business context rather than floating free of any data model. A single Knowledge Base can also be shared across multiple ontologies that use the same concepts, letting them reuse the same approved knowledge rather than duplicating it.
The ontology provides the structural layer: what entities exist, how they relate, which metrics are valid, and what access rules apply. The Knowledge Base provides the interpretive layer: which questions have been approved, which SQL patterns worked, which definitions need extra guidance, and how the organization expects its data to actually be used.
Concretely, a Timbr Knowledge Base can store approved question-to-SQL examples tied to specific ontology concepts, along with instructions, validation rules, and selection rules attached to properties, measures, relationships, cubes, or views. That keeps the memory grounded in the same model the ontology already governs, rather than floating free of it.
Knowledge Base is a capability built on Timbr’s ontology-based semantic layer. It is not a replacement category for Timbr.
With Timbr, the ontology-based semantic layer defines the business meaning, and the Knowledge Base captures how that meaning is used in practice. Together, they give data agents governed institutional memory, so approved examples, rules, and organizational context can improve every future question.
The result is a data agent that does not just understand the data model. It learns from the organization’s approved way of using it.
To see how a Knowledge Base is created, populated with approved examples and rules, and consulted by a data agent before SQL generation, explore Timbr’s Ontology-Based Knowledge Base for data agents.
