Earlier this year, we announced TextQL’s Ontology to bring a file-system approach to business knowledge. Today, it is generally available to all TextQL customers.
Business knowledge is moving into code
Over the past decade, some of the most important layers of the technology stack have moved into code.
Terraform made infrastructure declarative and version-controlled. dbt turned data transformation from a collection of stored procedures and one-off SQL scripts into a modular, documented, and reusable codebase. In each case, knowledge scattered across manual configuration, documents, and individual experts became structured, reviewable, and executable.
What dbt did for data transformation, TextQL’s Ontology does for business knowledge.
The knowledge a schema cannot capture
Every organization has knowledge that its agents need but cannot discover from a database schema alone: how the company defines revenue, which records should be excluded from a report, how customer data should be joined across systems, and which analytical method should answer a recurring question.
That knowledge is fragmented across documentation, source code, dashboards, conversations, and the minds of individual employees. Even when it is documented, it is frequently disconnected from the analytical logic that puts it into practice. Without that context, an agent has to reconstruct how the business works each time someone asks a question.
The Ontology gives that knowledge a durable home. It brings business definitions, data documentation, analytical methods, reusable queries, operating procedures, and institutional knowledge into a system that agents can read and use.
Over the past four months, we’ve expanded the Ontology’s capabilities, put it to work across TextQL’s own internal workflows, and measured its performance in production. Here’s how it works and what we’ve learned.
Built as a file tree
An ontology’s structure determines how easily a team can add the next piece of business knowledge.
Entity-based ontologies organize knowledge around typed objects, properties, and relationships. Those objects can be represented as JSON. Declarative semantic layers define metrics, dimensions, and join keys, often in YAML. They can carry descriptions and metadata, but their modeling schema determines how that context is structured and used.
An agent also needs knowledge that does not fit neatly into a metric or an object property: a reconciliation procedure, an exception explained over several pages, or a Python utility that implements an established method. Files are a straightforward way to preserve that knowledge in its useful form.
TextQL makes the file tree the agent’s working environment. Definitions, executable code, and the dashboards built from them live together. Adding a new procedure or tool means adding a file, not designing a new entity type or fitting it into a metric’s metadata.
For a revenue question, Ana can open net-revenue.md to read the exclusions, run the approved calculation in net-revenue.tql, and use reconcile.py to check the result against the ledger. A spreadsheet with fiscal periods or a reference PDF can sit beside those files. The definition explains the work; the query and utility carry it out.
Like a coding agent in a repository, Ana can start with an index, find the relevant domain, and open only the files the task requires. It does not need to load the entire knowledge base or reconstruct a calculation that already exists.
Teams can maintain focused files for each domain and review changes like code. The same definitions and methods can then support chats, scheduled playbooks, agents, dashboards, and applications.
Your knowledge stays yours
Because the Ontology is a file tree, that knowledge is not trapped inside TextQL. It can live in your own Git repository and sync bidirectionally with the platform.
Your definitions, .tql queries, documentation, and operating procedures remain ordinary, version-controlled files. Your team can read, edit, review, and use them with other tools.
Claude
ChatGPT
CursorTextQL makes that knowledge operational, but the knowledge itself is your intellectual property to keep. Every definition your team clarifies, every method it documents, and every reusable query it creates adds to a knowledge base your organization owns, with the freedom to use it wherever it is needed.
A shorter path to execution
In our work with Fortune 20 enterprises, we’re hearing a consistent theme: shorter project timelines, analyst hours saved, and more output for the same investment.
The value extends beyond a single analysis. As teams capture their business context in the Ontology, agents need less re-teaching, reducing repeated work and the cost of answering the next question.
We’ve also been measuring the Ontology’s impact on TextQL’s own recurring work.
We evaluated 45 scheduled playbooks with at least five runs on both sides of our internal cutover. The pre-cutover period ran from April 9 through May 6, and the post-cutover period ran from May 21 through June 17.
The scheduled workflows remained comparable across the two windows. There was no change in the model used by each playbook or in the underlying ACU rate card.
After our internal workflows moved onto the new Ontology and reusable .tql queries, median per-playbook run duration fell by 12%, and median tool calls per run fell by 7%. Of the 45 playbooks, 28 ran faster; 23 used fewer tool calls, and another six completed with the same number.
We then examined the 30 playbooks that used the new Ontology or .tql queries in at least half of their post-cutover runs. In that group, median duration fell by 12% and median tool calls fell by 9%. Seventy percent of playbooks ran faster, and 57% completed with fewer tool calls.
The model stayed the same. What changed was how the playbooks could access organizational context and reusable analytical logic.
Instead of repeatedly searching for definitions, rediscovering join paths, or reconstructing the same queries, an agent could find the appropriate files and use the knowledge the organization had already captured.
What this means for customers: reusing context and approved queries can make recurring analysis cheaper and more token-efficient, because Ana has less to rediscover on each run.
Benchmark methodology: Internal before-and-after comparison reporting median per-playbook changes. The full cohort includes 45 scheduled playbooks with at least five runs in each comparison window. The 30-playbook adoption cohort used the new Ontology or .tql queries in at least 50% of post-cutover runs. Models and the ACU rate card were unchanged. These results do not isolate the Ontology’s effect or quantify cost or token savings. Improvements vary with the task, context quality, and adoption.
Connect your systems. Build knowledge through use.
Getting started does not require your organization to model every entity, define every metric, or document the entire business in advance. The Ontology can begin with the systems and knowledge you already have, then develop as your team uses it.
1. Connect your systems
Connect the databases, warehouses, APIs, documents, and business applications that agents need to work across. These sources provide the initial foundation: schemas, records, documentation, relationships, and existing analytical logic.
2. Discover and organize knowledge
TextQL examines the available sources and begins organizing relevant knowledge into a file tree. Start with the domains and workflows that matter most, bringing together the definitions, documentation, and analytical methods your team already trusts.
3. Start asking questions
Users can begin analyzing data and building workflows without waiting for a lengthy modeling project to finish. When the Ontology contains an established definition or method, the agent can use it. When context is incomplete, the interaction reveals what the organization still needs to clarify or document.
4. Capture what the organization learns
A correction made during one analysis can inform future analyses. A useful query can become a reusable .tql query. A procedure explained to an agent can become a documented workflow.
Ana proposes the change as a patch for review. A data admin, or an editor with access to the target folder, can inspect the diff and approve it. Once approved, that knowledge becomes available to other people, agents, and workflows across the organization.
5. Build on what you’ve established
Each new definition, relationship, query, and procedure gives future agents more to work with. Your team can extend what it has already established instead of starting from zero with every request.
To get started, connect your organization’s data sources and APIs in TextQL or contact our team. We can help identify the best initial domain, connect the relevant systems, and establish the foundation for a knowledge base that grows with your organization.
Already using an earlier TextQL ontology?
Customers with an existing entity-based ontology or semantic configuration have a supported migration path.
Our team can help translate existing definitions, relationships, and business logic into the file-tree model, preserve trusted analytical methods, convert recurring logic into reusable queries, and validate important workflows before cutover.
