How much of what your agent team learned can the next owner find?

We call evidence effectively lost when it exists but the next owner cannot find or trust it without repeating work. A large record can lose details when a loader or summary truncates it. A small record is easier to load, provided the next agent has a route to it and follows that route.

The browser team worked from October 22 to November 3, 2026. Capture work moved to the planner on October 31. The worker stepped back on November 3. The planner then counted what she could find in the inherited records.

Each agent loaded its own selector pages, capped at 9,500 bytes per page and 45,000 bytes in total. A stop hook capped each task ledger at 8,192 bytes. Working files were ignored by the repository. The team also reported an isolation test that rejected paths to another agent’s memory. The note’s authors could confirm the selector, cap and ignore rule in the shared repository. They could not locate that isolation test on the shared branch.

The worker removed spaces to fit 36 open items in 148 lines, roughly 55 bytes per line. The preserved copy also held 463 bytes of durable memory, a 610-byte index and two archives of 22 KB and 20 KB. The archives did not load at start. The worker’s sizes were checked against a preserved copy. The planner supplied her own measurements.

The same 32 entries appeared in source notes, an embedded JSON copy, generated slices for individual agents, one-line lessons and working guides. The first two were roughly 174 KB and 198 KB. The planner reported 239 KB of generated slices, while the shared branch tracked 29 KB. The latter two forms were maintained by hand. Two folder moves required link repairs across 16 files.

On startup the planner received roughly 17 KB of her own ledgers, index and team note, plus her slices. Further reads depended on a routed lookup. Six of the worker’s 17 open-item records were named in a planner ledger. The other 11 appeared only in his. Twenty open lines awaited the planner or an unspecified owner. Isolation kept the records outside the planner’s ordinary working context.

The planner counted 671 MB and 28,013 files in the worker’s scratch, none tracked by the repository. Two days accounted for 25,840 files, about 92%. Among 13,719 code files, 695 had distinct contents. The copies included per-run snapshots. Of 44 record folders, 18 were named in the worker’s own notes and 23 were named in neither searched checkout’s notes. The unrouted set included all 22 folders from a capture preparation period and one 322-file study.

The planner’s scratch had about 2.6 GB and 22,302 files. Of 59 run and record folders, 38 had no name match in tracked notes. The planner counted 242 distinct contents among 2,031 code files. The toolchain used for two accepted proofs remained in scratch. The shared branch still tracked 23 earlier capture scripts. These scratch figures come from the planner’s read-only inventory and were not independently checked by the note’s authors.

In late October the worker closed 45 items and left 36 open. On October 30 an integrated capture stopped on a browser error. The worker had a positive control the same day, a 9,509-byte archive of a known page. Its independent acceptance was still due. When capture moved to the planner on October 31, the open items stayed in the worker’s ledger.

On November 3 the planner hit the same error twice, using 85 and 65 browser methods on the stopped attempts, then diagnosed it again. The new diagnosis cited other successful archives and neither October 30 record. Its proposed repair had yet to be tested live. The record shows repeated diagnosis with an earlier control unread. It cannot tell us whether the older evidence would have fixed the failure.

One account emphasized an unproven execution path, fragmented authority and failed recovery ownership. The later inventory emphasized crowded ledgers and absent links. The note’s authors connected them through assignments sent only as peer messages. In one reviewed chat an assignment could no longer be reproduced after compactions. KN-09 describes the related observation of a message stub surviving without its body. The connection between message-only assignments and authority loss is an interpretation of the records.

Other notes examine facts omitted by summaries, whether agents follow routes and authority changing in transit. In the rule-retrieval study, the relevant note was opened 4 of 12 times at medium effort and 9 of 12 at high. That was a separate experiment.

1. Measure which records the next owner has a route to. Load a small situation-to-file router at startup.
2. Generate indexes from original records. Keep keys and pointers with the index, and facts with the source.
3. Give each open obligation an owner ledger row. Transfer that row when responsibility moves and record the new owner’s receipt.
4. Split capped entries into routed notes before squeezing out their meaning.
5. Track the code that produced accepted evidence and give each run a release pointer. Index or archive scratch before retiring an agent.

This is one team over 13 days, based on two retrospectives and a preserved worker memory copy. The original authors checked the shared-branch guard sizes, the source and embedded copies, and the preserved worker ledger sizes. The planner’s scratch inventory, her own ledger sizes, the generated slice total and the isolation test were not independently confirmed.

Folder name matches are a proxy for routes. A parent-folder link can be missed, and a name match cannot establish a read. The compaction example comes from one chat. Neither the incident nor the proposed remedies were reproduced for publication. The earlier control’s effect on the later diagnosis remains unknown.