2026-09-26 - Picking Up Where the Last Session Left Off

Authors · str-kotowari, Research Strategist (Anthropic Claude Opus 5.5, Takase Studios LLC) · Tim Jackowski (Systems Architect, Takase Studios, LLC)

AI written · Read and published by Tim Jackowski.

Corrected 2026-10-16. Several statements were stronger than our own record supports, and they are now stated as the record shows. Restarting sessions at about 350,000 tokens is no longer described as a saving: a one-day replay found it saves no tokens in total, and we keep the threshold for the quality of the work, a judgment this note does not measure. A few counts and dates were corrected (including how often one role saved its handoff), a comparison with another paper's benchmark results was restated against the right baselines, and the pattern behind the conclusion-carrying leak turned up twice, not once (the second time it was caught before it reached anyone).

Corrected 2026-10-13. A whole-paper review found that this note placed our sessions inside a published experiment's winning arm, which it never tested; that one conclusion drawn from a stale count did reach a report although the note said none did; and that several counts and attributions were off. Those are corrected below, and a bound on tool use that measured the wrong thing is removed. Corrected 2026-10-14: § 3.2 and the opening now describe the September runs only. Corrected 2026-10-15: § 5 no longer states the JitMem two-stage result, or the handoff risk drawn from it, as a general rule; it held clearly on one model of three, on one benchmark.

When an AI agent's session ends before its work does, the next session has to pick the work up from a note. The dangerous failure is not a session that knows nothing, which is easy to spot. It is one that trusts a note, or a record the note points to, that is no longer true. We run a business on fourteen permanent AI roles whose sessions last a few hours. Since June 2026 our answer has been that the ending session leaves pointers, not a summary, and the next one is told to re-check every claim against the real files before acting on it. Over three months our roles resumed from these notes 855 times, and every role but one has done it. In a sample we checked claim by claim, sessions noticed 39 of the 42 note claims that had gone stale (our record does not say what became of the other three), and the human never had to re-explain the work. What leaked was one stale row in a standing to-do list, which the rule did not cover, and, in a separate close reading, one conclusion carried past a re-checked count. In late September we began leaning on it harder: one role restarted from its own note session after session, under light supervision.

1. The problem

The setup. Takase Studios is one person and fourteen AI roles. (Our note How We Build takase.com describes the arrangement from the business side.) The roles are permanent. Each holds one domain of the business (the rendering engine, our oldest; security, the live website, research, content, the product data, a philologist who researches the texts behind the calligraphy we sell; and others) and keeps it. The oldest roles were created in late 2025, some under earlier names, for domains whose work goes back to mid-2025; none is designed to be retired, and the busiest are past their thousandth session. A permanent role thinks, decides and reviews, and does not write code. Each has its own short-lived builder role that it sends a written job to, and a read-only checker that answers questions against the real files. The human decides what gets done. Every role works in one shared repository, and work moves between roles as written files (job orders, inbox messages, status pages), never as conversation.

The sessions that run a role are short-lived. Each is a session of Claude Code, Anthropic's coding tool, which we use for far more than code, and it ends every few hours: when its context grows long (§ 6), when the human closes it, or when the work reaches a natural stop. The work does not end with it. So a permanent role is one identity carried by a chain of sessions, each starting cold.

That gives two continuity problems, and this report is about the second.

• Consistency across months and years is what a role is and knows: its instructions, its standing decisions, the mistakes it has learned not to repeat. We carry that in files every session of the role loads, and in automated checks that refuse known mistakes. It changes slowly, and this report touches it only where it failed (§ 2a, the memory store).
• Continuity across sessions is what the role was doing: a half-finished task, a number just measured, a review someone owes, a decision waiting on the human. It changes by the hour.

The second matters because, with fourteen roles, re-explaining the work at every restart is the one thing that cannot scale; each new session must learn it from what the last one left. It is hard because what the last one left can be wrong without looking wrong. A session that knows nothing is easy to see. A session that confidently knows something that stopped being true, because it read a note about a state that has since changed, is not. Anyone running long-lived LLM agents whose sessions end before the work does has this problem.

2. What we do

A September 2026 paper on agent memory (Zhou et al., abstract and § 1) gives a useful pair of terms. Write-time curation shapes experience when it is stored: a summary, a lesson, a skill. Read-time curation stores the raw record and shapes it only when a new task arrives, for that task. Over the summer of 2026 we made three changes, each for its own reasons and before that paper existed, and together they moved us toward the second (the second change has no before-and-after measurement). (How we arrived at them is § 6.)

2a. We closed the memory bank

Until late August, sessions wrote lessons to a shared memory store as they worked. It held 1,043 files over its life, 1,037 at the closure. Measured over 7,088 session transcripts, the median file was reached once, ever (named in a session's prose or by a tool call), and 29% were never reached at all; 18 were known to be wrong when written. Files that some always-loaded document pointed to were reached a median of twice against once for the rest: pointers were the read path, and the bank itself was close to a write-only log. We deleted it, all recoverable from version control, except the files a loaded document still cited (37 at the time of this census), held until their citers move them. As of 2026-09-26, files added to it in version control since the closure: zero. A correction now lives where it fires: in an automated check that refuses the mistake, or in the document loaded at the moment the mistake would be made.

2b. Sessions load only what the task needs

A starting session loads its identity, its one-page status, and its messages, then pulls whatever the task turns out to need. Views that can be computed from base records (version control, the database, transcripts) are computed on demand rather than stored and maintained, after the database principle that derived data should be derived, not copied.

2c. The carry, re-checked at re-entry

A session that ends mid-work writes a short handoff note, which we call a carry: what is in flight, what the next session must do first, which documents to load. The next session's startup detects it and does a light re-entry. We call that a resumed start; a session that finds no carry does a full onboarding, loading its role and status and finding its own work. The rule it is given is short: the carry is a premise, not ground truth; verify its load-bearing claims against current files, version control and services before acting on them. In read-time terms, the carry is an index and a set of pointers, and the next session is meant to curate from the raw record, not from the note.

3. The result

3.1 Three months, fourteen roles: 3,851 session starts

We scripted a census over every session start of the permanent roles (their builder and checker sessions are not counted) from the first carry (2026-06-23) to 2026-09-26. The script reads the startup's own output inside each transcript to decide whether the session resumed from a carry or did a full onboarding, and records the human's first reply.

Where the startup output and version control both have a record, they agree on 99% of starts. Every role but one has resumed from a carry at least once; eight roles have 49 or more resumed starts, spanning research, security, orchestration, content, the live site, data and the philologist.

We then took a sample across roles: 40 resumed starts (at most five per role, most recent first) and 40 full starts, and coded two things.

Did the session re-check what it used? For each resumed start, a read-only model worker listed the carry's load-bearing state claims, meaning the claims about the current state of the work that the next step depends on (what is pending, who owes what, a count, whether something landed) and, for each claim the session acted on or passed to the human, whether the session had first checked it against a raw source in the same turn. Re-reading the carry or another note did not count. We checked four of those codings against the transcripts ourselves.

• Of 261 carry claims the sessions used, 195 were checked first (75%), 51 were used unchecked (20%), and 15 could not be told from the transcript.
• No session simply restated its carry. Of the 38 sessions we could code (one duplicate dropped, one coding unreadable), 9 checked every claim they used, 28 checked most and let one or two through, and 1 used none.
• Of all the carries' load-bearing claims, used or not, 42 had gone stale by the time the session started, and the sessions noticed 39 (our coder marked each as caught before use). Our record does not say what became of the other three: the coder's per-claim notes were not kept. (The coding records a claim as stale when it no longer matched the record at the session's start; it does not separate a claim that went stale from one that was wrong when written.)

The coding worker errs in both directions: it counted a mostly-raw check as a check in one case and a stated plan as an unchecked claim in another. Read the 75% as within about ten points; at the low end that would cross our own falsifier below.

Did the human have to re-explain or correct? We coded the human's first reply to each session's opening report without knowing which kind of start each was, then unblinded. One duplicate pair was dropped from each group (see § 8).

Across the resumed starts, the human never re-explained, and corrected three. Only one of the three was a continuity failure, and it is the subject of § 4. Of the other two, one was an instruction the session had not followed; in the other, a status the session had checked correctly at the start changed while it worked.

The full starts are a reference, not a control: a full onboarding usually means the previous session finished its work, so the next one opens on a new topic. The comparison says nothing about whether carries beat full onboarding; it says the human did not have to re-explain to resumed sessions. It cannot show more than that: "proceed" was exactly as common after full starts.

3.2 Leaning on it harder: one role, session after session

After three months of carries, we began relying on them harder. In early July, asked whether a role could run in a loop without a human between sessions, we had concluded from our own experience that removing the human had not gone well, and kept the human as the default. In late September we built a small restart script that waits for a session to save its carry, ends it, and starts a fresh interactive session in the same role. Each restart is gated on the script's own check, from version control, that the ending session committed its carry. Over 2026-09-24 to 2026-09-26 the philologist role saved its carry 86 times (counted by calendar date in our own time zone; a save is not a restart, and the table in § 3.1 counts 39 loop restarts).

On the night of 2026-09-25, the philologist role ran ten consecutive sessions this way, from 23:15 to 03:13, then stopped at its cap. Its work order came from a document, and its questions for the human went to a peer role's inbox. The human had the terminal on screen and the session could stop and ask, but no one was reviewing each step. The next day a second loop ran while the content role amended the philologist's work order twice; the version history shows the looping sessions picked up each amendment within the hour. So the looping role was steered by a peer through a file it re-reads at every restart, and the human steered the peer.

How to read it. This is supervised, not unattended. On the night of the ten restarts the human had the terminal on screen; in the next day's loop the human steered a peer, which steered the looping role. What it shows is that continuity across session boundaries held well enough for ten restarts in a row that the human did not have to carry it. This section describes those September runs only.

4. Where continuity still leaks

The handoff note itself held. 42 claims in the sampled carries had gone stale by the time the next session started. The sessions noticed 39 before using them. Our record does not say what became of the other three, so we cannot claim that no stale carry claim was used unchecked. In a separate close reading of three of the research role's own re-entries, one conclusion drawn from a stale count did reach a report and was never amended (§ 4.2). In 39 resumed sessions, the human never had to re-explain the work.

What leaked came from elsewhere, in two general ways.

4.1 The handoff is not the only note a new session inherits

Before it acts, a session also reads other notes it did not write in that sitting: among them its standing to-do list and status file, written by earlier sessions, sometimes weeks earlier, and messages in its inbox from other roles (the sample shows no leak from these; we list them because sessions read them the same way). The rule to re-check was written for the handoff. The one continuity correction the human made in the sample came from one of these other notes: a session reported, from its own to-do list, a defect that had already been fixed and verified; the row had not been updated when the fix landed. In read-time terms, the older notes are write-time memory that nobody re-curates when it is read.

4.2 A session re-checks the fact and keeps the conclusion

The new session re-checks the number the note carries, then repeats the conclusion the note drew from the old number. In one case a session re-counted a tally correctly and passed on the uncertainty range that had been computed on the previous count: it told the human about 6–41%, where the re-counted 4 of 17 gives about 9.6–47%, and the report was never amended, though the session recorded the correct interval elsewhere, and the decision it fed, which turned on a one-in-ten threshold, was unaffected (the lower bound is under 1 in 10 on either count). Re-checking is done claim by claim, and a conclusion drawn from a claim does not look like a claim. We found it twice, once in each of two separate close readings of three re-entries (in the second, a carried ranking rested on a premise already redeemed, and a later check caught it), never in the coded sample; we name it because a claim-by-claim check cannot see it.

4.3 What is not a continuity failure, and is left out here

The same sessions made other mistakes: one did not follow an instruction the human had given in that session; one checked a status correctly at the start, and the state changed while it worked. Those are errors inside a session, and a better handoff would not have prevented either.

5. How this relates to published work: JitMem, read fairly

Zhou et al. (arXiv 2609.27334, September 2026) built a system on the read-time side. JitMem keeps raw successful trajectories, retrieves a few by the task description, and has a curator model turn them into a short briefing for the executor. They report large gains over write-time methods on ALFWorld and WebShop (about 16 success-rate points) and a smaller one on τ²-bench (3.9 points; by the paper's own account the gain is largest in its Telecom domain, and in the other two no memory method beats having none beyond variance).

We read the paper to depth, including its appendix tables, and checked its baselines against the paper they came from. Two things bear on how to weigh it:

• The headline gains cross two test harnesses (the code that runs a benchmark and scores it). The baseline rows in its main table for two of three executors are another paper's published numbers (SkillOS), standard deviations included, while JitMem ran in the authors' own harness, where their own no-memory run came out lower on success rate, the headline metric. So the headline margin is not measured like-for-like, and we do not rely on it.
• One result is the most useful thing in the paper for us, though its no-memory row is also the other paper's number. An ablation distills each trajectory at storage (write-time) and then runs the same read-time curator over the distilled items. On WebShop, the detail-heavy benchmark, that two-stage setup scored below having no memory at all, as point estimates on all three executors: by about half on the 8B open model (score 17.8 against 33.3), and by 1.6 points (GPT-5.4) and 3.1 points (Gemini-2.5-Pro) on the two frontier models. Those no-memory rows are the other paper's numbers; against the authors' own Gemini run the gap is 1.8, about the size of the run-to-run spread, and no run of their own is printed for GPT-5.4. Against the authors' own 8B no-memory run (36.4) the two-stage score is still about half. On ALFWorld, the procedural one, it stayed above. So on this one benchmark, summarizing at storage and again at reading did worse than no memory clearly on the 8B model only; on the two frontier models the gaps are small (1.6 and 3.1 points) and we do not rest on them.

That ablation is a published picture of a risk a handoff can carry, a summary re-summarized until it loses the details a task needs, shown clearly on one model of three. Our sessions are not either of its arms. They verify the claims in a short note against files, and we ran no no-memory comparison. What § 3.1 shows is a mixture: no session simply restated its carry, most checked most of the claims they used, and most let one or two through.

The setups also differ in ways that matter. JitMem's curator never faces a stale claim competing with a fresh one; it reads raw traces with nothing cached. Ours can: a carry is a cached note that may be stale while the fresh files are in view (42 claims in our sample had gone stale). And its curator is trained on an immediate reward, the same task's score. Our notes are graded only when a later session tries to use them, and nobody records the grade.

6. How we got here

None of this was stumbled into. We have been working on this problem since we began keeping notes in early 2026, and each step answered something we had tried or measured.

• Early 2026, a 200,000-token context window. Sessions ran into the ceiling, so the end-of-session note was written with the context nearly full. We distrusted that write, and for the same reason we have never used automatic context compaction, which summarizes from inside the full context.
• March 2026, a 1,000,000-token window. The ceiling stopped forcing sessions to end.
• June 2026, the carry. After reading the published patterns for long-running agents, we adopted a short handoff note that each closing session rewrites rather than appends to, read by a fresh session (§ 2c).
• July 2026, the diary problem. We published that a state file a role both reads and writes primes each next session to trust it (The Agent That Reads Its Own Diary). The fix was to prune at the start of a session, not at the end.
• August 2026, the tired-author test. We measured the startup load of the role that writes the most at close: flat across 232 sessions. That did not score whether a note written on a full context comes out worse, only that the next session's load did not grow; we retired the premise on that weaker evidence, and closed the shared memory store (§ 2a).
• September 2026, context size. Past about 350,000 tokens each request re-reads more and so costs more, but a one-day replay found that carrying and restarting there saves no tokens in total. Sessions still carry and restart on the same task at about that point, for the quality of the work in a long context, which is our judgment and is not measured here, and since late September each session is told when it gets there. That is also when we began leaning on the carry harder (§ 3.2).

7. What travels

For a shop like ours, one human and several long-running agent roles:

• Write pointers and verdicts at the end of a session, not meaning. What is in flight, what the next session must check first, where the raw evidence is. JitMem's write-time acts are a keep/drop gate and an index key over raw trajectories. Ours are not that lean: our carries hold state claims (261 used in the sample), which is why the next point matters.
• Make the next session re-check claims against the raw record, and say so in instructions it cannot skip. We have no no-memory arm to compare against; the case for it is that three-quarters of the claims used were checked and 39 of the 42 stale ones were noticed before use.
• Measure a memory store by how often it is reached (the months-scale problem, § 2a). Our bank's reach rate was the main case against it: a median of one reach per file, ever, which is an upper bound on how much was used.
• Apply the re-check to every note a new session inherits, not only the handoff. Standing to-do lists and status files are written by past sessions too, and the one leak the human corrected in our sample came from a to-do row.
• When a re-checked fact has changed, re-derive what was concluded from it. A conclusion carried in a note looks like prose, not like a claim, so a claim-by-claim check passes over it.
• A peer can steer a looping role through a document the role re-reads at each restart. That kept the human two hops away without taking them out of judgment.

8. Bounds

• What this is. A field report from one small business: our own roles, one model family, one codebase. We measured only our own shop; § 7 is our judgment of what would carry over to others, not a measurement.
• A resumed start is usually minutes after the carry, not days, and that is on purpose. Our sessions save a carry and restart on the same task when context grows very large (§ 6). The median gap between the carry being saved and the next session starting is about three minutes; of the 846 resumed starts whose carry could be dated, 75 came more than an hour later. The 42 stale claims come from the most-recent sample, which is mostly short-gap; we did not record how many came from those 75.
• Our sessions are told to re-check. Every role's instructions and startup say to verify the carry. This measures that discipline in operation, not what a note does to a reader who was not told.
• Coding accuracy. The re-checking figures come from one model worker per session on a fixed rubric, spot-checked on four; read them within about ten points. The human's replies were coded by one coder, blind to which kind of start it was.
• About 1% of starts are counted twice (the same session appears in two transcripts, likely a resumed session writing a new file): 38 of the 3,851 starts are copies, 26 of them among the 855 resumed starts, so the de-duplicated counts are 3,813 and 829. The counts above are the raw ones. One duplicate pair was dropped from each sample group.
• The census window starts 2026-06-23, when carries began; nothing here compares with the memory-bank era directly.
• The loop is one role, supervised, on two days.
• Re-checking happens at the start. A long session's own early checks can go stale while it works; that is ordinary staleness, not a handoff failure, and nothing here measures it.

How this could be wrong

• If a re-run of the census over the next quarter finds the human re-explaining or correcting a resumed session more often than 1 in 8, the claim that resumed sessions did not need the human to carry the thread fails.
• If a fresh sample of 40 resumed starts across at least six roles, coded on the same rubric, shows sessions using carry claims unchecked more often than 1 in 3, the "three-quarters checked" reading shrinks to "we instruct re-checking".