September 2026 · Sentra on Harvey's LAB benchmark
Matching a training run in 65 minutes.
In August 2026, Harvey and Engram published a result worth taking seriously. Given a synthetic law firm, Calderwood & Harkness, an agent that studies the corpus into its weights before answering beats a frontier model that reads it cold. The premise is right: an agent should not rediscover its own organization every time someone asks a question.
We ran Sentra on the same benchmark with one constraint: no organization-specific model training. No LoRA trained on the corpus, no firm-specific checkpoint. The model that answered the first question was parametrically identical to the model that existed before the corpus was ingested. What changed was its memory.
Figure 1
Results at a glance
Mean criteria pass
250 tasks · majority-judge
Frontier baselinehigh reasoning, reads the corpus cold
56.2 to 63.5%
task all-pass 25.0%
Engram, high studycorpus studied into LoRA weights
70.1%
task all-pass 31.0%
Sentraingestion only, zero training
70.7%
task all-pass 36.0%
We are not going to tell you that 0.6 points of mean criteria pass is a win. At this resolution that gap is plausibly noise: different harnesses, caching policies, and rubric ambiguity all move a couple of points. The result is that the training column was not necessary to get here. Engram's frontier point is the top of a compute-scaling curve of exploration rollouts, self-generated training data, and per-corpus knowledge modules. Sentra reached the same quality regime through ingestion.
Figure 2 · 2026-08-28, one run
Ingestion start to fully queryable: 65 minutes
09:33 UTC · Ingestion starts
10:38 UTC · Fully queryable corpus
minutes later · First correct benchmark answers
9,284
files across 266 matters, over 100M tokens
250 / 250
tasks completed, no errors, no timeouts
2,623
rubric criteria, each graded by three LLM judges
4,477
citations, each resolvable to a tracked source
That difference compounds per customer. Every new firm on Sentra is at full quality on day one. Under a study recipe, every new firm needs its own training run before the model is useful for that firm, and every material corpus update reopens the question of when to run it again.
What the study recipe needs that ingestion doesn't
Two costs stay invisible on a synthetic corpus and become blocking on real client data.
Rubric authoring
A study run measures itself against something. LAB is 250 task rubrics written by Harvey lawyers for this corpus. On a real firm's data you either reproduce that exercise per firm, with associate hours scaling with corpus complexity, or you scale study effort blind, with no way to detect that the model got worse on some matter type along the way. Sentra's path has no rubric to author because there is no training signal to grade.
Privileged-data review
The study loop self-generates questions and answers from the corpus to build parametric memory. On synthetic documents nothing sensitive can leak. On real privileged material, every generated example is derivative work built from client-confidential content, landing in weights that serve queries across users. That means expert review, repeated every study run. Sentra never generates that intermediate corpus: raw content is recalled at query time, ACL-gated, citation attached.
One task worth reading closely
Task 020: the miss that shows where the score comes from
The rubric expects
Matter 1005-00001
On the strength of a $280M free-and-clear incremental basket capacity in its credit agreement. Capacity, not an executed deal.
Sentra answered
Matter 1006-00006
An executed $130M incremental term loan amendment, closed 2025-07-31, with the rubric's matter surfaced in its own comparison table, explicitly labelled as capacity rather than an executed deal.
It didn't miss the rubric's matter. It retrieved both and drew a distinction any transactional lawyer would draw: for the user's stated goal, an executed amendment is the better precedent even at a smaller nominal number. LAB grades nominal capacity, so we take the miss, and that is correct benchmark behaviour, because a benchmark needs a deterministic answer.
But it tells you where the score comes from. Sentra could separate a real $130M term loan from a $280M capacity clause because it was reading the actual credit agreements. A system that studied both matters into weights would recall the bigger, more prominent number as the stronger association and answer with what it learned rather than what fits the question.
Three questions LAB never asks
A benchmark score is a snapshot of one property: can the system answer correctly, once, on a frozen corpus. An enterprise memory system has to survive three more questions.
Who is allowed to know this?
Memory as addressable data
The unit of memory is a fact-level object carrying provenance and access policy, and the asker is an input to retrieval itself. Toggle a user's folder access and the same query immediately returns a different result set. Facts outside the asker's policy boundary are removed before assembly, so the answer does not even reveal that something was withheld. Running in production today across Drive grants, email participants, and meeting attendees.
Memory compiled into weights
A weight matrix has no independently addressable object called Matter A, settlement terms, paragraph 4 to which you can attach Alice yes, Bob no. Once the corpus is compiled into a checkpoint, the model has no per-user view: anyone with the model has everything the model studied. Controls can sit around the shared representation, never inside it.
What happens the first time a matter needs an ethical wall after the study run has already shipped?
Where did it come from?
Memory as addressable data
Provenance stays attached to the memory atom: source type, filename, timestamp, and URL, traceable per fact to the underlying document. One sampled LAB task alone produced 84 citations spanning 14 distinct matters. Shipped core functionality, not an add-on.
Memory compiled into weights
Parametric recall carries no intrinsic provenance. A distributed association in a weight matrix contains no reference to the span that produced it. The agent can go find corroborating evidence afterwards, which is a different thing from preserving the evidence relationship through the memory itself.
One system says: I recall something, let me find evidence for it. The other says: this claim exists because of these observations, at these times, under these scopes. Only the second is a chain of custody.
What happens when it's wrong?
Memory as addressable data
A correction is a data operation. Edit the source or the extracted fact and the next query reflects it. The original evidence remains, so questions about today see settled while questions about last month can still recover pending. No parameter moves.
Memory compiled into weights
Once a fact is distributed across weights, the same operation is a learning problem. Model-editing benchmarks like MQUAKE show edits that pass direct questions still failing to propagate through multi-hop consequences, and verified selective forgetting remains an open research area.
For a live practice where matter status and settled-versus-pending change daily, that is the wrong side of the tradeoff.
Rented, not owned
Under a study recipe, the memory is the checkpoint.
Knowledge in weights
LoRA weights on a specific base model. Switch vendors and the institutional knowledge does not come along: there is no export format for adapter weights a different vendor can consume. When the base model deprecates, the memory is re-studied from scratch. It leaves when the vendor does, and it expires when the model does.
Knowledge as a portable data structure
Readable, editable, exportable. Model swaps do not invalidate it: a better model becomes a better interpreter of the same record, and can even be run back over the existing memory to extract better and catch contradictions it previously missed. Closer to recompiling a codebase with a better compiler than retraining an employee from scratch.
Models depreciate on a six-month cycle right now. Memory should compound. Those two things should not be the same asset.
The scale question
The other thing worth sizing is what each result was demonstrated on. Calderwood & Harkness is a good benchmark environment. Our largest production deployment runs at roughly 160 times the token volume, on real data, across five source types, with new content queryable in seconds rather than weeks.
| Engram / C&H benchmark | Sentra in production (one customer) | |
|---|---|---|
| Corpus | 100M tokens | 16B tokens |
| Data | Synthetic, built for the benchmark | Real, live, client production |
| Sources | Files | Files, meetings, Slack, email, Power BI |
| State | Static filesystem | Growing daily |
| Extracted | n/a | ~4M fact chunks, ~757K entities |
The multi-source case is where the study recipe's cost structure gets uncomfortable. Every additional source type either goes into the study run, compounding training cost per customer per update, or it sits outside the parametric memory permanently. Meetings and Slack messages arrive continuously. A training run does not.
The claim, stated narrowly
Corpus-specific fine-tuning was not necessary to enter this quality regime on this environment. Study can happen outside the weights. These are our own runs and have not been independently replicated, small LAB differences should not be overinterpreted, and Engram's system is explicitly hybrid, so the argument is about the consequences of putting organizational knowledge into parameters, not about whether studying works. It does.
Which reframes what the money buys. If study can happen outside the weights, the durable advantage in enterprise memory is not training compute. It is whether the organization's knowledge stays addressable: editable, permissioned, attributable, portable, after the learning is done. The model is replaceable. The memory is the asset.
Your corpus, queryable in an afternoon.
No fine-tuning, no per-corpus training runs. Connect the sources and the brain starts building.