The coherence layer for language models
Your model's intelligence
has a length limit.
We remove it.
Every model eventually loses the thread. On a long task it starts to contradict things it settled a hundred steps earlier, and it does this quietly. FROS is the memory it reasons against: a verified record of what was decided that holds firm as the work grows. Same model, same intelligence, far longer runway.
The problem
Long context is one thing. Consistent context is another.
A bigger context window lets a model read more at once. Once the model starts writing, it can still drift. These are separate problems, and the second one is the expensive one.
What happens on a long task today
State piles up: decisions, definitions, constraints the model set for itself early on. A few thousand steps later the pile outgrows what it can hold in view, so it improvises, and it overwrites an earlier commitment while believing it stayed consistent. Asking the model to check its own work buys little, because the part doing the checking is drifting too. The failure stays silent, and you usually find it downstream.
What FROS changes
The commitments move out of the model's head and into an external record that stays sound for the length of the task. The model reuses what it already decided and spends its capacity on the actual work. Every new step is checked against everything already committed. When a step would contradict the record, the engine catches it before it lands.
“The engine is memory the model can trust. It is the part of the model's reasoning that keeps, so the model picks the thread back up and checks a record instead of its own word for what it decided.”Daniel Bearden, founder
How it works
Commit. Check. Repair.
The model commits
As the model works, the facts and constraints it settles on get written to the engine as verified state. This is the record it will be held to for the rest of the task. It lives outside the context window, so the task can run far past what the window could hold.
The engine checks
Every later step is checked against the whole record. The part that renders the verdict is a deterministic function with zero learned parameters, so it holds steady where the model drifts. Same state, same step, same answer, every time.
The engine repairs
A failing check hands back more than a verdict. The engine returns the smallest change that puts the step back in agreement with everything already committed. The model asks what would keep the work consistent, and gets an answer it can act on. That is why a model reaches for the engine instead of routing around it.
Measured, then said
Four results, called what they are
These come from seeded, repeatable studies, and each one carries the label of the study that produced it. None of the numbers below stand alone as an unlabeled average.
In a seeded colony study, 3,630 scripted agent processes ran in staged cohorts, peak concurrency 250, all working against one shared record that the engine checked: zero divergence, zero false closures.
In a follow-up study, real and deliberately cheap 7B model agents, 10 processes, proposed into the same shared record, and every closure was checked by the engine: zero false closures. The engine checks every closure, so the guarantee holds independent of which model proposed it.
Across kill-and-resume trials, the engine carried every commitment through a restart: 0 forgotten. A conventional setup, run the same way, forgot 19. Memory that survives the agent process is the point.
Runs guided by the engine finished fully clean in 11 of 12 seeds. The conventional arm, run on the same seeds, finished fully clean in 0 of 12.
From our kill-and-resume study: every task written to the record carried through. Nineteen that lived only in an agent's memory slipped away.
What we claim, and what we choose to say plainly
We ran a placebo control on our own strongest-sounding claim, that engine hints speed up a capable model, and the control retired it. A hint that only sounded plausible, even when wrong, helped about as much as a correct one, so the speed claim did not survive its own test. We say so here because a trust feature only works when we use it on ourselves first.
Our verdicts are floors. We publish what the measurements support, and we retire what they do not.
Proven out
Where the substrate was proven first
Before the measured studies above, the engine was built and proven against two domains where a wrong call has a real cost and the right call has to be defensible. The numbers below come from the engine alone.
Picking the intended sense of a word from context, scored on the standard Raganato benchmark (7,253 instances), a labeled comparability anchor for this benchmark. The engine that makes each call has zero learned parameters. See the language work.
A patient's findings are checked against a ranked list of diagnoses, and each one ruled out comes back with the specific reason it failed. In place of a confidence score, a record a clinician can read and challenge. See the medical work.
The part that decides yes or no carries zero learned parameters, pure logic, so it stays fixed between runs. An optional ranker (a small embedding model, roughly 22 MB) can order candidate repairs, and the engine alone renders the verdict.
Ranker and engine, one authority. The ranker suggests, the engine judges. Replace the ranker with a coin flip and the verdicts hold; the engine just sees fewer good candidates first. Both numbers above are the engine on its own.
Where this goes
Constraints that grow themselves
The bottleneck
A useful rule set keeps growing. Every new case is a chance to contradict an old one, and keeping a large, growing set consistent by hand is the kind of task that defeats people. So most systems either stay small or quietly lose their consistency as they scale.
The unlock
When a new fact enters the record, the engine works out what it implies and what it rules out, and the rest of the set stays consistent on its own. The set can keep growing while the engine handles the bookkeeping a person would otherwise redo case by case. Capturing an agent's messier, in-flight state this way is the frontier we are working on now, and it is the difference between a feature and infrastructure a model reaches for by default.
Where we draw the line
Two honest limits
Consistent can still be wrong
The engine guarantees one thing: the model stays true to what it has committed to. Whether those commitments were wise is a separate question. Start from bad assumptions and the work comes out wrong and perfectly coherent. FROS removes incoherence and leaves judgment to you.
Unbounded state, bounded reasoning
What lives in the engine and holds steady is the committed record: the facts, the constraints, the decisions. The messy, in-the-moment reasoning still happens in the model, and that part is as bounded as ever. We extend how long a model stays coherent. Per-step intelligence stays where it is.
Curious what actually runs, and where? See how it deploys inside your boundary.
Early access
Request pilot access
Pilots are operator-led right now. Tell us about your use case and we'll set up a call. Self-serve API access comes later.
We store your email, a hashed IP, and basic request metadata. See the privacy page for what's kept, for how long, and how to ask us to delete it.