Appearance
The rule is still in there. It just stopped mattering.
Set a constraint at turn one. "Answers stay under 120 words. JSON with three keys. Never quote pricing." The model agrees, and for eight turns it complies.
By turn 30 it's writing 400-word prose, the JSON has grown a fourth key nobody asked for, and there's a price table in paragraph three. Ask it what the constraint was and it recites it back perfectly.
That gap between recall and compliance is what the StateTrack paper calls State Integrity Collapse. It's a good name because it describes the mechanism rather than the symptom. The model isn't confused about what you asked for. It has stopped applying what it knows.
The headline number: across seven provider-pinned model snapshots and five dialogue-depth probes, strict joint retention of all constraints ranged from 62.4% to 100.0%. Read that range practically. The best snapshot in the set never dropped a constraint jointly. The worst held everything together in roughly two out of three long conversations, which means a third of your users hit at least one silent policy violation before the session ends.
Silent is the operative word. No error, no refusal, no indication that the terms changed.
What the benchmark puts under load
StateTrack-Bench splits constraints into five families and tests each across depth probes. The families matter because they fail at different rates, and the ones that fail most are not the ones people worry about.
| Constraint family | What it looks like in a real session | How it tends to break |
|---|---|---|
| Numerical | "Budget cap is 40 hours, never propose more" | Model re-derives instead of recalling, and the arithmetic drifts |
| Format | "Every reply is a JSON object with exactly three keys" | Schema grows once answers get long enough to need structure |
| Role / persona | "You are the skeptical reviewer, not the author" | Voice slides back toward default assistant register |
| Factual memory | "Client is Acme, deadline is March 3" | Details survive but stop constraining downstream choices |
| Logical rule | "If the spec is unapproved, don't write code" | The conditional stops firing once other instructions stack up |
Degradation concentrated in symbolic constraints. Format and logical rules, the ones a linter could check mechanically, are exactly where models slip. Factual memory held up better, which is counterintuitive if you've been treating context as a storage problem.
It isn't a storage problem. That's the whole finding.
88.6% of these failures are not forgetting
Here's the experiment that makes the paper useful rather than just descriptive. The authors forked the conversation at the failure point and asked the model to restate the constraint before judging the failure.
88.6% of observed failures were behavioral drift. Ordinary forgetting accounted for the rest. Excluding the one especially brittle snapshot from the set still leaves 84.4% drift, so the diagnosis isn't an artifact of a single bad model.
Sit with that ratio for a second. Most of the engineering effort in the agent space right now goes into memory: vector stores, retrieval, context compression, summarization chains. If 88.6% of your constraint failures happen because a model that remembers the rule stops obeying it, none of that machinery touches the problem.
You'd be building a bigger filing cabinet for a document the model already has open on the desk.
Depth tests up to 50 turns confirmed the dissociation persists well past the core benchmark. The failure isn't a cliff at some context boundary. It's a gradual erosion of behavioral commitment.
The fix that showed movement was Structured State Anchoring, which recovered up to 24.4 points on immutable constraints. That's a large recovery on a hard problem, and it points at the right layer: re-asserting state in a form the model has to apply, not just recall.
Quick Take: The long-horizon reliability of a model cannot be inferred from how well it follows instructions in a single turn, because the dominant failure mode is drift, not forgetting.
The numbers in one place
| Metric | Value | What it means when you're building |
|---|---|---|
| Strict joint retention, 7 pinned snapshots | 62.4% to 100.0% | Worst case, one in three long sessions ends with a broken constraint |
| Failures attributable to behavioral drift | 88.6% | Memory work won't fix your compliance problem |
| Drift share excluding the brittle outlier | 84.4% | The finding isn't one bad model dragging the average |
| Recovery from Structured State Anchoring | up to 24.4 points | Re-asserting state outperforms storing it |
| Deepest evaluation depth | 50 turns | Failures compound well past the 10-turn mark where most teams stop testing |
| UserLM-2.0 valid conversation rate | 46.2% | More than half of simulated sessions are still unusable without filtering |
| Strongest prior user simulator | 14.1% | The previous bar was low enough that almost any evaluation built on it was noisy |
| CoWriter successful agent engagements | 2.2x baseline | Proactive prompting gets users to actually engage rather than rubber-stamp |
The simulator bottleneck
You can't measure long-horizon reliability without long conversations to measure, and human data doesn't scale. That pushes everyone toward LLM-based user simulators, which have been stuck on a trade-off.
Prompted assistants follow a complex intent faithfully but don't sound like people. Specialized user simulators sound like people but wander off the intent. Both failure modes ruin an evaluation set, one by producing conversations no real user would have, the other by testing the wrong task.
UserLM-2.0 attacks the trade-off directly with a reinforcement learning recipe that rewards intent adherence and behavioral naturalness together. The interesting mechanism is how naturalness gets operationalized: a lightweight discriminator trained in an alternating adversarial loop against the simulator, so the reward signal for "sounds human" is learned rather than hand-specified.
46.2% is over three times the prior 14.1%, and it's also the number that should temper your enthusiasm. More than half of generated conversations still fail at least one validity criterion. If you're building an eval harness on top of this, you need a filter and you need to report your filter rate, because a simulator that quietly drops the hard conversations will make your assistant look better than it is.
I'd rather have 46.2% valid with a transparent rejection pipeline than a simulator that claims 90% and hides the drift in its own outputs.
CoWriter and the passive-supervision problem
The third paper is about the other side of the table: the human. Standard chat-and-canvas interfaces turn authors into approvers. You prompt, you read, you accept, you prompt again. The CoWriter authors call the result passive supervision, and they name three costs: review fatigue, over-reliance on the model, and the human's perspective getting sidelined in long-form, source-grounded writing.
That last cost is the one that matters if you write for a living. A draft where your point of view has been smoothed into generic competence is worse than a draft with rough edges and a real argument in it.
CoWriter is a proactive agentic scheme that adapts expert co-authoring methods from cognitive science and steers the whole writing workflow, actively pulling the user into the process instead of waiting for prompts. In an exploratory user study against a standard LLM baseline, authors using it produced documents where they felt more ownership and expressed their perspectives more clearly. The quantitative support: 2.2 times more successful agent engagements.
I'm skeptical of engagement counts as a quality metric. More back-and-forth could mean more collaboration or more interruption. The result I find more convincing is the external reader judges scoring CoWriter outputs higher on storytelling and on integration of the author's unique personal experience. That's a measure of whether the human's contribution survived to the page, which is the thing passive supervision destroys.
You can reuse the mechanism even without a writing tool. The design principle is that the agent initiates structured checkpoints at the phases where human judgment has the most leverage, like argument structure and evidence selection, and stays out of the way during drafting. Most agent products do the opposite: they automate the parts a human enjoys and ask for approval on the parts a human can't evaluate.
What the community is saying
When I ran a persona-consistency test on a 40-turn support scenario, the break came at turn 19. The assistant had been holding a "never promise a refund timeline" rule, recited it correctly when I asked, and then offered a seven-day window two turns later. I only caught it because I was grepping transcripts. Nothing in the response signaled the shift.
My team's experience matches the drift diagnosis closely enough that I've stopped expecting retrieval to save us. We added a summarization layer that re-injects standing constraints every N turns, and the failure rate dropped noticeably. That's a crude version of Structured State Anchoring, and it works for the same reason: it forces the constraint into the position of an instruction to follow rather than a fact to know.
The complaint I hear most from people building on user simulators is that the simulators are too cooperative. A simulated user that accepts every clarification request and never gets frustrated will validate an assistant that would fail with a real one. Naturalness matters for exactly this reason, and it's why the discriminator approach is more interesting than another round of prompt tuning.
Common Pitfalls
Grading long-horizon quality from single-turn evals. If your test suite is one prompt and one response, you are measuring a different system than the one your users interact with. Retention drops across depth, and the drop is invisible at turn two.
Adding memory when the model already recalls. This is the expensive mistake. With 88.6% of failures coming from drift, a vector store full of constraints the model can already recite changes nothing. Instrument recall separately from compliance before you spend engineering time on retrieval.
Stopping depth tests at 10 turns. The team behind StateTrack ran probes out to 50 turns and found the dissociation persists. Failures that compound over a long session don't appear in a short one, so a 10-turn suite will report a clean bill of health on a model that breaks at turn 30.
Trusting a natural-sounding simulator without checking intent adherence. A simulator that drifts off the user's goal produces conversations that look realistic and test the wrong task. Filter for validity, and log your rejection rate so nobody mistakes a clean eval for a robust assistant.
One Thing to Remember
The constraint that breaks your system is the one the model can still quote back to you, which means every diagnostic you'd naturally reach for, from longer context to better retrieval to asking the model to confirm it understands, will come back green while the behavior is already wrong.
The Bottom Line
If you're shipping a long-running assistant, build a constraint-compliance probe into production and fork a recall check on every violation. The two signals together tell you whether you have a memory problem or a behavior problem, and 88.6% of the time it's the second one.
If you're constrained on engineering time, skip the retrieval overhaul and spend a week on periodic state re-assertion. Recovering up to 24.4 points on immutable constraints with a mechanism that re-injects standing rules is a better return than any amount of context plumbing, and you can ship it as a prompt-layer change.
If you're building an evaluation set from simulated users, expect to throw away more than half your conversations today. Budget for the filter, report the rejection rate next to your scores, and watch UserLM-2.0's 46.2% ceiling, because the next generation of simulators will move it and your benchmark's validity will move with it.