Platform
A marathoner runs a sprinter's pace.
They just keep going.
A lot of hard work stalls for one reason, and it is rarely raw intelligence. It stalls because the system loses coherence before it can finish. The model is smart enough at any single step; it just loses track of some of a thousand steps of its own decisions. FROS takes that load off the model and puts it somewhere that remembers. The intelligence stays fixed. The distance it can carry that intelligence stops being the limit.
The mechanism
One loop, five beats
Commit, check, repair, admit, resume. The agent works above; the record holds below. The fifth beat kills the session mid-task, and the record holds fast. Click a chapter to jump straight to it.
The distinction everyone collapses
“Long context” and “consistent over long context” are different products
A larger window is about how much a model can take in. Coherence is about whether it stays true to what it already concluded while it keeps going. A two-million-token window reads more and still drifts. The tools people reach for solve the first problem and leave the second one open.
Recalls the past, stops there
Memory tools store what happened and fetch it back later. Useful, and a different job from making sure the next step agrees with it. They remember; they leave the model free to ignore it.
Judges after the fact
Observability and eval tools tell you something drifted once it already has, usually by asking another model to grade the output. That is a measurement, taken too late to stop the error.
Orders the flow, skips the truth
Agent frameworks route steps and tools in the right order. They keep the process moving. Step forty goes unchecked against what step three established.
Catches it before it lands
A check that runs on every step, gives the same answer every time, and is sound about what follows from what. Preventive, deterministic, and consistent. That combination is the gap the other three leave.
Why models drift
Drift is a property of the path, not the step
Any single check, on a clean snapshot, a capable model does well. The trouble shows up over a trajectory, where state accumulates faster than the model can keep faith with it.
State accumulates
Step by step, the model commits to more: definitions, constraints, partial results. A term defined in a contract's first clause has to keep that exact meaning nine amendments later, and a growing set of terms like that all need to hold at once. The pile of things it must stay consistent with grows the whole time, while the window that holds it stays the same size.
The checker drifts too
The obvious fix, have the model review its own work, runs into the same wall. The reviewer is the same kind of system, carrying the same overloaded state. It can confidently bless a contradiction that has slipped out of its view.
One thing in the loop holds steady
The engine holds the committed state outside the model and checks against all of it, the same way, regardless of how long the task has run. It is the one part of the loop whose accuracy holds as the trajectory gets longer.
Why a model actually uses it
It returns the fix along with the verdict
A guard that only blocks
A checker that rejects and stops there becomes something the model learns to route around. It adds friction and hands back a dead end, so under pressure the system finds a path that skips it.
A tool that answers
The model can ask a different question: I need this to be true, what target keeps everything else consistent? The engine returns the smallest change that satisfies it. That is a thing worth calling on every step, because it moves the work forward as it enforces.
Evidence
Proven in the hardest domains
We built the engine against domains where a wrong call costs something and the right call has to be defensible: resolving what a word means in context (94.5% on the standard benchmark, the labeled comparability anchor for that page), and checking patient findings against 30,981 diagnoses with a written reason for each one ruled out. Both results are the engine on its own, zero learned parameters in the part that renders the verdict.
Running it
What runs, and where
Inside your boundary
It runs inside your boundary. The engine is a compiled native library loaded in-process by a thin client. Nothing calls home and no data leaves your machines.
Plain files, on your disk
The record lives in plain files on disk you control. It is append-only, and a restart rebuilds working state from it. That is the property the kill-and-resume study measured.
Deterministic
It is deterministic. The same committed rules and the same state produce the same verdict, every run.
Fast enough for the loop
It is fast enough to sit inside the loop. Single checks return in milliseconds on our demo workloads.
Gated and audited
Rules are written in a small declarative form and committed through a gated channel with an audit trail. Every verdict carries its evidence.
Pilots run on your code
Pilots run on your codebase, deployed inside your boundary. Start with the recorded replay, then ask for a live run.
Where we draw the line
Two honest limits
The guarantee is narrow: it holds the model to what it already committed to. Whether the commitment was wise stays a separate question. It extends how long the model stays coherent, and per-step intelligence stays exactly where it was.