Native has released a research preview that wraps Markdown context in SQLite, reporting 40× fewer tokens per fully correct answer than a Markdown-grep baseline. Its research post also claims roughly 20× lower modeled token bills, 97% fewer failed trials under a fixed one-million-input-token budget, and a median answer time one-sixth as long. Those are Native’s results, not independent measurements. (Native research)
The useful part of this announcement is the testable proposition behind those numbers: an agent can waste substantial context reading documents simply to discover relationships that a database could return directly. Native has open-sourced its core engine and benchmark materials so others can investigate that proposition.
For anyone maintaining a growing Markdown vault, the practical question is how much retrieval work can move out of the model’s context window and into a query engine.
What Native Has Opened
Native describes the release as a research preview for a context-engineering architecture. Markdown remains the familiar source material, while SQLite provides a structured way for agents to retrieve relevant information.
The research post connects this work to Native’s broader goal of “context sovereignty”: keeping working knowledge accessible and usable independently of a particular AI provider. The company says its core engine is already open source, with more planned after the preview.
The product itself remains an early-access offering. Native’s homepage asks readers to join a list and advertises one-line setup once admitted. Access to source code and immediate access to the packaged product are therefore separate things. (Native homepage)
I’d treat the open engine and benchmark materials as the most consequential part of this release. A large efficiency number is hard to evaluate in isolation; a runnable comparison creates a route to checking whether the benefit survives different notes, questions and agent configurations.
How SQL Can Avoid Repeated File Reading
Native’s homepage illustrates the mechanism with a question about a blocked deal.
In the file-based version, an agent searches for the deal, opens its note, follows a link to a pricing review, opens a decision, discovers that the decision has been superseded, and continues until it reaches a pending finance sign-off. Each document supplies the next pointer. The model repeatedly receives note text to determine where to look next.
The SQL version asks for the connected records together. Its illustrative recursive query starts from the deal, follows links to a maximum depth of five, and returns fields describing each record’s type, name and lifecycle status. The agent receives the relationship chain without reading every note’s body. (Native homepage)
That changes where the work happens:
| Retrieval task | File-walking approach | Structured-query approach |
|---|---|---|
| Find the next relationship | Read a note and interpret its links | Follow stored links |
| Check a decision’s state | Inspect document text | Return a status field |
| Traverse several connected records | Make successive retrieval calls | Express the traversal in one query |
| Control returned context | Select files or text excerpts | Select particular rows and columns |
The example is explicitly illustrative. Its displayed timings are not another benchmark result, and the example query should not be treated as documentation of the complete production schema.
The underlying mechanism is still useful. A database can handle joins, filtering and graph-like traversal before the result reaches the model. That can reduce both the amount of text returned and the number of tool exchanges needed to gather it.
My read is that the strongest opportunity lies in questions whose answers depend on relationships: which decision superseded another, which approval remains pending, or which project owns a dependency. Questions requiring a careful reading of an entire proposal will still need document content. SQL helps select and connect evidence; the model still has to interpret it.
What the 40× Benchmark Measures
Native’s homepage describes 40 questions, run three times each, over one company’s notes. That produces 120 attempts per approach. The comparison is between Native’s structured retrieval and a Markdown-based grep workflow. (Native homepage)
The reported results use several different denominators:
| Reported result | What Native says it measures |
|---|---|
| 40× fewer tokens | Token expenditure per fully correct answer |
| About 20× lower modeled bills | Modeled token cost per fully correct answer |
| 97% fewer failed trials | Failures under a fixed one-million-input-token budget |
| One-sixth the median response time | Time to answer compared with the Markdown-grep baseline |
| 30.5 steps versus 5 | Median attempt length for Markdown and Native, respectively |
The first four figures come from the research report; the step counts appear on the homepage.
“Per fully correct answer” matters. It connects resource use to successful output, rather than merely reporting how cheaply an agent can finish an attempt. A system that stops quickly with an incorrect answer may look economical per attempt while delivering poor value.
It also means readers should keep two questions separate:
- How many tokens does an attempt consume?
- How often does that attempt produce a fully correct answer?
An efficiency-per-success result can improve through either route, or both. The 40× headline should therefore not be read as a promise that every individual query becomes 40× smaller.
The workload boundary matters too. Three runs of 40 questions offer evidence about repeated performance on that question set. They do not provide the same coverage as tests across many organizations, document structures and task types. The published figures are vendor-generated, workload-specific results; the available evidence here contains no independent reproduction.
Why the Homepage Says 98% and the Report Says 97%
Native’s homepage advertises “98% fewer mistakes,” while its research summary reports 97% fewer failed trials. The accompanying conditions explain why readers should keep those figures separate.
The research summary attaches 97% to a fixed one-million-input-token budget. The homepage’s 98% presentation instead shows attempts with no right answer within five minutes: one out of 120 for Native, compared with 46 out of 120 for the Markdown workflow. (Research report, homepage)
Using those homepage counts, the relative reduction is:
(46 − 1) ÷ 46 ≈ 97.8%, which rounds to 98%.
That is a reduction in attempts missing the stated deadline. It is different from a 98-percentage-point increase in answer accuracy, and different from measuring failures at a token-budget cutoff.
This distinction has a practical consequence. An agent that eventually reaches a correct answer can still be unusable if it takes too long or consumes too much context. Budget-limited and time-limited success rates capture those operational constraints, but neither should be silently relabeled as general accuracy.
I’d give the explicit counts more weight than the homepage slogan. “One versus 46 attempts without a correct answer in five minutes” tells a reader what happened under a particular condition. “Fewer mistakes” leaves more room for interpretation.
Why 40× Fewer Tokens Becomes About 20× Lower Cost
Native labels the billing result as modeled, and reports roughly 20× lower token bills per fully correct answer alongside the 40× token-efficiency claim. (Native research)
Those ratios need not match. A token bill applies prices to token categories. Depending on the provider and model, new input, cached input and output can carry different rates. A reduction concentrated in relatively inexpensive tokens will not reduce the bill by the same proportion as the total token count.
For evaluation, that means preserving the token breakdown and the pricing assumptions used in the calculation. A modeled bill is useful for comparing retrieval methods under a declared price schedule; it is not an observed invoice for every deployment.
The same accounting boundary applies to infrastructure. A token-cost comparison alone cannot establish the total cost of operating a system that imports, structures and maintains a vault. Those costs belong in a deployment assessment alongside model spending.
Frequently Asked Questions
3 questions
1Is Native’s Preview Available to Everyone?
Native’s core engine is open source. The packaged product is presented as an early-access research preview with a signup list.
