TextQL Ontology GA: Context, Not Capability

TextQL published a vendor benchmark on its own product — same model, same rate card, and a 12 per cent fall in median run duration. The number is about persistent context, not model capability.

What Happened

TextQL published a post on its own blog announcing that its Ontology is now generally available to all customers. The post is a vendor announcement about the vendor’s own product, and the benchmark data inside it was run by TextQL on TextQL’s own systems. No third party audited it. That context belongs at the top of any reading of the numbers.

The company evaluated 45 scheduled playbooks, requiring at least five runs on each side of an internal cutover. The pre-cutover window ran 9 April to 6 May. The post-cutover window ran 21 May to 17 June. TextQL states there was no change in the model used by each playbook and no change in the underlying ACU rate card.

The reported results: median per-playbook run duration fell by 12 per cent and median tool calls per run fell by 7 per cent. Of the 45 playbooks, 28 ran faster, 23 used fewer tool calls, and six completed with the same number. For the 30-playbook adoption cohort — those using the new Ontology or new .tql queries in at least half their post-cutover runs — median duration fell 12 per cent and median tool calls fell 9 per cent, with 70 per cent running faster and 57 per cent completing with fewer tool calls.

The Structural Read

TextQL’s benchmark methodology note is the most important text in the post. The company published it itself, which is more disclosure than most vendor benchmarks carry. It reads directly:

That caveat matters for a specific reason. Elsewhere in the same post, TextQL writes that reusing context and approved queries can make recurring analysis cheaper and more token-efficient. The methodology note says the benchmark does not quantify that. The efficiency statement is a stated expectation — not a measured result. The piece you are reading treats it as exactly that.

The benchmark is also an internal before-and-after comparison. It reports medians. The full cohort is 45 playbooks; the adoption cohort is 30. Those are the limits of what the data can carry.

Within those limits, the design logic is legible. With the model fixed, the variable being tested is whether the agent had to rediscover definitions and join paths on each run. Fewer tool calls suggest it did less of that. Shorter duration suggests the same. That is a measurement about persistent context. It says nothing general about agent design, and nothing about other products.

The design choice the company made is worth understanding on its own terms. TextQL contrasts three shapes of business knowledge system. Entity-based ontologies organise knowledge around typed objects, properties, and relationships, representable as JSON. Declarative semantic layers define metrics, dimensions, and join keys, often in YAML. TextQL instead makes a file tree the agent Ana’s working environment.

In its example, a finance folder holds net-revenue.md explaining the exclusions, net-revenue.tql running the approved calculation, and reconcile.py checking the result against the ledger. A fiscal-calendar spreadsheet and a reporting-policy PDF sit alongside. The company’s stated advantage: adding a new procedure means adding a file, not designing a new entity type or fitting it into a metric’s metadata schema.

The portability claim follows from the same choice. Because the knowledge lives in a file tree, the company says it can live in the customer’s own Git repository and sync bidirectionally — remaining ordinary version-controlled files that the team can read, edit, and use with other tools. The post names Claude, ChatGPT, and Cursor as examples of those other tools.

Three Implications

IMPLICATION 1 — THE MARGINAL COST OF KNOWLEDGE TextQL’s stated design advantage is about the cost of adding the next piece of knowledge. A file-tree approach means adding a file. An entity-based approach means designing a new type. That difference compounds as a knowledge base grows. Whether it holds at scale is not something this benchmark measures — but the design logic is coherent on its own terms.

IMPLICATION 2 — PORTABILITY AS A POSITIONING ARGUMENT Storing business knowledge in a customer-owned Git repository — readable by Claude, ChatGPT, Cursor, and other tools — is a specific positioning move. It reduces switching costs for the customer and frames the Ontology as infrastructure rather than proprietary lock-in. That framing matters more than any single benchmark number.

IMPLICATION 3 — WHAT THE BENCHMARK CANNOT SAY The methodology note is explicit: the results do not isolate the Ontology’s effect and do not quantify cost or token savings. The cohort is 45 playbooks. The comparison is internal. That is a reasonable start for a product launch disclosure — and it is the boundary of what can be concluded from it. Any reading that goes further than duration and tool-call medians goes beyond what the data supports.

The Bottom Line

TextQL ran a vendor benchmark on its own product, published its own methodology caveats, and reported two numbers that held the model constant: median run duration down 12 per cent, median tool calls down 7 per cent. The caveat the company printed alongside — that the results do not isolate the Ontology’s effect and do not quantify cost or token savings — is the correct frame for everything else in the post.

The design argument, a file-tree approach that makes the next piece of knowledge as cheap as a new file, is the part worth watching. The benchmark supports a hypothesis about persistent context. It does not prove one about the Ontology alone.

Source: TextQL — Ontology Generally Available (textql.com). All benchmark figures, methodology notes, and product descriptions are drawn directly from that post. This article is published on Friday, 2 October 2026. Nothing here is investment advice.