A model that clears a hard benchmark can still be useless on a Tuesday afternoon. Not because it reasoned badly, but because it had no idea where the work stood.
That gap is the one we keep running into, and it does not look like it is closing on its own as models improve. Capability and operational usefulness are related, but they are not the same axis, and the second one gets far less engineering attention than it deserves.
A demo is a single turn
Most of what gets demonstrated is short. A question arrives with everything it needs already attached, the model answers, and the answer is graded. That shape flatters the model, because it quietly removes the part of the job that operational work is actually made of.
Real work does not arrive that way. It runs for weeks. It stalls halfway while someone waits on a document. It gets picked up by a different person than the one who started it. Facts that were settled in March stop being true in June, and nothing announces the change. By the time a decision is needed, the relevant history is spread across a dozen places and half of it has been superseded.
A benchmark asks whether the answer was right. An operation asks whether the work moved, and whether it moved on a basis that still holds.
State is not context
The common answer to all of this is to give the model more context. Longer windows, the full transcript, every document the team has ever touched. That helps. It is also not the same thing as knowing the state of the work.
A transcript is a record of what was said. State is a claim about what is currently true. The two drift apart constantly, and the transcript is usually the less reliable of the pair, because it preserves every superseded version of the truth and gives them all equal weight.
The state of a piece of work is a smaller and far more opinionated object than its history. It has to be able to answer four questions at any moment:
- What has been decided, and by whom.
- What is still open, and what it is waiting on.
- Which facts are current, and which have been superseded.
- What the system is permitted to do next without asking a person.
Three ways state goes missing
When an agent behaves badly inside a real process, the failure is usually traceable to one of three things, and none of them is the reasoning step.
- It was never written down. The only record of a decision is a sentence in a conversation, so it survives exactly as long as that conversation fits in the window.
- It was written down but never reconciled. Two sources disagree, both are retrievable, and nothing in the system decides which one wins or raises a hand for a person to decide.
- It was reconciled but never enforced. The system knows an action needs approval, and nothing structural prevents it proceeding anyway, because the requirement lives in a prompt rather than in the architecture.
The third gets the least attention and does the most damage. It fails silently, it fails rarely, and it fails specifically in the cases where the stakes were high enough for someone to have written the rule down in the first place.
Designing for the state of the work
If that reading is right, the interesting engineering is not in the prompt. It sits in the system around the model, and it looks a lot more like ordinary software design than like AI work.
A few things follow from taking it seriously.
- State is a first-class artifact. It is stored, versioned and inspectable on its own terms, separately from whatever conversation happened to produce it.
- Every claim carries its source and the moment it was established, so the system can distinguish current from stale instead of treating retrieval rank as a proxy for truth.
- Permission is structural. If an action requires a person, the only path to that action runs through the person, and no phrasing talks its way around it.
- Handing work back to a human is a designed state with its own representation, not an error path and not a refusal.
None of that is exotic. It is the kind of thing any team would build for a system that had to be correct over months rather than impressive over one exchange. The reason it often goes missing in agent projects is that the model is so capable in the demo that the surrounding system never gets designed at all.
Where we are with this
This is the thesis StayX is built on, and it is worth being precise that it is a thesis rather than a result. We are testing it in one place first, with Mano, our product for legal work.
Legal work is a deliberate choice of hard case. A matter runs for months. Several people touch it. It accumulates facts that supersede one another, and it ends in documents where a citation that does not hold is not a rounding error, it is the entire problem. If a system can hold the state of a matter honestly under those conditions, the approach is worth extending. If it cannot, we would rather find that out on the hard case than on an easy one.
We will write up what we learn as we go, including the parts that do not work. That second category tends to be the more useful of the two, and it is the one that almost never gets published.