2026-09-26 - Read-Time Curation in a One-Human, Many-Role Shop

What this is and is not. A field report from one small business run by one person and fourteen AI roles, on how a session picks up work another session left. Everything here is our own record: our 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. We report what happened and how we read it.

In short. We run a business on permanent AI roles. Each is responsible for one domain of the business, the oldest since late 2025, and none is meant to be retired; the sessions that do a role's work last a few hours. That makes two continuity problems: keeping a role consistent across months and years, and keeping its work continuous across the break between one session and the next. This report is about the second, and about how we arrived at our answer over seven months of trying and measuring. The ending session writes a short handoff note of pointers, and the next session re-checks it against the real record before acting: the record is shaped when it is read, not when it is written, which a recent paper calls read-time curation. We counted 3,851 session starts across fourteen roles and coded a sample of the sessions that picked up from a handoff note: they re-checked about three-quarters of the note claims they used, caught 39 of the 42 claims that had gone stale, and in those 39 sessions the human never had to re-explain the work. One role now runs session after session under light supervision. What leaked came from older notes a session inherits, such as its standing to-do list, which the re-check rule did not cover.

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 (security, the live website, research, content, the product data, a philologist who researches the texts 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 has been retired and none is meant to be, 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 coding-agent session, and it ends every few hours: when its context fills (past about 350,000 tokens every request costs more for the same work), 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 is hard for a simple reason. With fourteen roles, re-explaining the work at every restart is the one thing that cannot scale, so each new session must learn it from what the last one left. The failure we fear is not a session that knows nothing, which is easy to see. It is a session that confidently knows something that stopped being true, because it read a note about a state that has since changed. Anyone running long-lived LLM agents whose sessions end before the work does has this second problem.

2. What we did

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 tested whether a note written with a nearly full context comes out worse. It did not: the role that writes the most at close showed a flat startup load across 232 sessions. We retired that premise, and closed the shared memory store (§ 2a).
• September 2026, cost. What remains is economics. Past about 350,000 tokens every request costs more for the same work, so sessions carry and restart on the same task at about that point, and since late September each session is told when it gets there.

A September 2026 paper on agent memory (Zhou et al., § 5) 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 from the first to the second.

(a) We closed the memory bank. Until late August, sessions wrote lessons to a shared memory store as they worked. By its closure it held 1,043 files. Measured over 7,088 session transcripts, the median file was read once, ever, and 29% were never read at all; 18 were known to be wrong when written. Files that some always-loaded document pointed to were read about twice as often as the rest: pointers were the read path, and the bank was a write-only log. We deleted it (all of it recoverable from version control). Since the closure, new files in that store: 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.

(b) Onboarding, what a session loads when it starts, became just-in-time. 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.

(c) The carry, re-grounded 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 One role now runs session after session under light supervision

In early July, asked whether a role could run in a loop without a human between sessions, we 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 new session reporting that it verified its carry.

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: a human was watching, two hops away. It is one role, one working night and one day. 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. We do not run loops unattended.

3.2 The roster census: 3,851 session starts, 14 roles

To see whether this is one role or the whole roster, we scripted a census over every role session start 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 caught 39. The other three were never used.

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.

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 § 6).

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 the next section. 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 resumed sessions did not need the human to carry the thread.

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 caught 39 before using them, and the other three were never used: no stale carry claim reached an action or a report in the sample. In 39 resumed sessions, the human never had to re-explain the work.

What leaked came from elsewhere, in two general ways.

1. The handoff is not the only note a new session inherits. A session also reads its standing to-do list and status file, written by earlier sessions, sometimes weeks earlier. The rule to re-check covered the handoff; those older notes were read as current. The one continuity correction the human made in the sample was of this kind: 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.

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. Re-checking is done claim by claim, and a conclusion drawn from a claim does not look like a claim.

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; and the author of this report searched our archive by keyword instead of with the meaning-based search we built for the purpose, and passed on an outdated answer. Those are errors inside a session, and a better handoff would not have prevented any of them. The last one is its own finding: tools we built are not always the ones sessions reach for (§ 6).

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, WebShop and τ²-bench.

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. So the headline margin is not measured like-for-like, and we do not rely on it.
• One result measured within a single harness is the most useful thing in the paper for us. 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, on all three executors. On ALFWorld, the procedural one, it stayed above. Summarize-then-re-summarize loses the details a detail-heavy task needs.

That ablation is the published form of the risk in any handoff. A session that writes a handoff note and a successor that reads it is a two-stage curation. If the successor restates the note, it runs the setup that fell below no memory; if it goes back to the raw record the note points at, it runs JitMem's own setup. § 3.2 shows which ours do: no session simply restated its carry, and three-quarters of the claims used were checked against the raw record first.

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 does, every time. 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. Bounds

• A resumed start is usually minutes after the carry, not days, and that is on purpose. Past about 350,000 tokens of context, every request costs more for the same work, so our sessions save a carry and restart on the same task at about that point; since late September the session is told when it gets there. 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. Claims about stale carries rest on those 75 and on the stale-at-start claims coded above, not on the typical case.
• 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). 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.
• Built is not used. Our search tool is mostly a startup ritual. Over the last month, outside the two roles that build and maintain it, nine of the other twelve roles ran 74–98% of their searches in a session's first 15 minutes; three of the four roles with the most sessions averaged under one search per session. So the reader's best tool is mostly not in hand when a question comes up mid-session. That is a finding about tool adoption, not about handoffs, and it gets its own measurement.

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 only write-time acts are a keep/drop gate and an index key; ours converged on nearly the same.
• Make the next session re-check claims against the raw record, and say so in instructions it cannot skip. In our record this is what separates the setup that works from the setup that fell below no memory.
• Measure a memory store by what gets read (the months-scale problem, § 2a). Our bank's read rate was the whole case against it: a median of one read per file, ever.
• 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 they are the notes that leaked in our sample.
• 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.

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".