Answer
How should an agent recover context after a session ends?
Read the written state, then check it against reality. A record can be right about the past and wrong about now.
Read the written state first, then verify it against what is actually there before acting. A record describes the moment it was written, and anything may have changed since, including by a person who was not part of the work.
Recovery is usually treated as a reading problem: supply the handover, resume. That is the first half. The second half is that the handover is a claim about a past moment, and the gap between then and now can contain anything — a colleague's change, a failed job, a deployment, a rolled-back branch, a record someone corrected. A session that reads and acts without checking is treating a description as the thing described.
So the sequence is read, verify, then act. Verification does not need to be exhaustive; it needs to cover the specific claims the next action depends on. If the handover says a file was written, open it. If it says a record was updated, query it. If it says a branch exists at a point, check. Three or four reads at the start of a session is a small cost against building an hour of work on a false premise.
There is a second recovery problem beyond state, and it is the one people notice: the reasoning is gone. The receiving session has the conclusions and not the deliberation, which means it can continue the work and cannot fully evaluate it. This is a real limitation and it argues for the handover carrying decisions with reasons, since those are the only part of the deliberation worth reconstructing.
The material also needs re-establishing, and the temptation is to re-supply everything the first session had. That reintroduces the volume problem for no benefit, because most of what the first session read was navigation. The right approach is to supply the state and the material the next action needs, and to let the session fetch anything else, which is both cheaper and produces a sharper run than an attempt to reconstitute the previous one.
A specific failure worth naming: partial recovery that looks complete. A session that read a handover will proceed confidently whether or not the handover covered what it needed, because there is no signal for absent context. Requiring the resuming session to state what it understands the situation and the next action to be, before doing anything, is a cheap turn that catches this. Reading that statement takes seconds and it is the only point where a misunderstanding is still free.
Recovery is two operations and teams do one of them, which is why the second session so often starts by confidently building on a fact that stopped being true overnight.
Siddharth Sharma, Context Theory
Related questions
Should the new session re-read everything the previous one did?
No, and the attempt usually degrades the run. Most of what a working session reads is navigation to find the few things that matter, and the handover should already name those. Re-supplying the whole set reintroduces dilution and buys nothing that the state file and targeted fetching do not.
What if the state file is out of date?
Then it should be corrected before work continues, and the correction is more valuable than the work. A stale state file is worse than none, because it produces confident action on false premises rather than the visible uncertainty that an absent file produces. This is the argument for verification at the start rather than as an occasional precaution.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A handover is a claim about a past moment, so the interval between writing and reading may contain unrelated changes, and a session that reads and acts without checking is treating a description as the thing described. | Comparing the assertions in a state file against the current state of the systems it names, at the start of a resumed session. |
| Response | Verification at resumption should cover only the claims the next action depends on, which is typically three or four reads, and this is a small cost against building extended work on a false premise. | Listing the assertions the next action relies on and reading each one back before acting. |
| Software | Re-supplying the material the previous session read reintroduces dilution without benefit, because most of what a working session reads is navigation rather than the few items the next action requires. | Comparing outcomes when a resumed session is given the whole previous context against the state file plus targeted material. |
| Constraint | There is no signal for absent context, so a session that read an incomplete handover proceeds with the same confidence as one that read a complete one, which makes a required statement of understanding before acting the only cheap point of detection. | Supplying a deliberately incomplete handover and observing whether the resuming session raises the gap unprompted. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one