The test
Kill your session, mid-task, right now.
Can the work resume from what is on disk and in the issue trail? Or does resuming require someone who remembers the conversation?
If it's the second one, you were running on chat-as-state and merely hadn't crashed yet.
That is the whole subject of this piece, and everything below follows from it.
Why resume cannot be the continuity plan
The documentation quietly tells you this if you read it as an operator rather than a user.
Transcripts expire — thirty days by default. Their format changes between versions, so anything you build to parse them is temporary. Resuming a long session confronts lossy summarisation, which is exactly when you needed the detail. And agent teammates are not restored on resume at all.
Meanwhile the vendor's own production systems persist their plans outside the context window, because the window will be truncated. Their cloud workflow hands work between machines via a committed plan file. Their context-engineering guidance canonises writing notes to disk.
The people who built it don't run on the transcript either.
It records everything, which is why it answers nothing — undifferentiated tool noise wrapped around undated decisions, in a format documented as unstable.
A record is curated at the moment of writing: a plan, a decision note, a gate output, a pull request description. Export exists for salvage, not as a system of record.
Records as state, stated flat
The conversation is a cache. The record is the truth.
Anything that must survive — intent, plan, decision, status, evidence — gets written to a persistent artifact at the moment it becomes true. Not at the end of the session. Not when you remember. When it becomes true.
And every session must be startable from records alone.
This is not one team's preference. The field converged on it independently from four directions — spec-and-todo files, plans in a repo directory, everything-in-the-repo loops, issue graphs — and the vendor's own systems arrived at the same place under production pressure.
This site is produced by an operation built on exactly that doctrine. Every decision lands as a numbered ruling in a git repository. Every stream of work files a statement of work with a ledger of claims, and each claim carries the commit it landed in and the check that proves it.
The three incidents below are real, drawn from this operation's own practice — offered here as illustrative first-party examples of the pattern, not as an externally auditable case study with a public repo link, since the underlying ruling history is internal:
A design that had never rendered. A CSS plugin was installed and never registered, so seventeen carefully-written style rules had never once applied. Every build passed the whole time — an inert class is not an error.
Two workers editing the same file. Both were correct, both were assigned, neither could see the other. The record showed the collision; one reverted.
A day spent re-deciding something already decided. Three participants reasoned about an acquisition mechanic that a ruling on disk had settled weeks earlier. Nobody had looked, because the question felt new.
That last one is the honest lesson: the record is only an advantage if it is read before it is added to.
Parallelism is free. Integration is not.
Every tutorial demos three worktrees humming along. None shows the afternoon after — three branches touching adjacent code, each green in isolation, that have to land on main in some order, and the second and third arrive on a base they were not written against.
Parallel streams are only as parallel as the decomposition was, and decomposition is an up-front management act rather than something the agents work out.
The merge order is a decision the operator owns, because no agent in any stream has the cross-stream context to make it.
The mature field answer on task selection: give parallel streams research and disposable work. Not entangled production changes.
The bottleneck moved into you
Multi-stream operation does not multiply the operator. It multiplies the inflow to the operator.
Two mitigations have receipts, and both are about records:
Review against a spec you wrote. Code that started from your own specification is far less effort to review, because you are checking conformance rather than reconstructing intent.
Make each stream carry its own evidence. The best-practice phrasing is exact: have it show the test output, the command it ran and what came back — rather than asserting success.
A stream whose output is "done" costs you a full re-derivation. A stream whose output is a diff, a gate run and a conformance note costs you a read. That difference is the entire economics of running more than one.
History is for the operator
Agent-heavy repositories drift the same way every time: enormous unreviewable commits, or commit spray from "commit frequently" obeyed mindlessly, messages that narrate rather than justify, and force-pushes that destroy the only audit trail you had.
The counter-doctrine, assembled:
Built into worktree creation. One stream, one branch, no exceptions — this is what makes merge order a decision you can make rather than a mess you discover.
They mark which commits an agent authored. In an agent-heavy repo that is management data — it tells the reviewer, meaning you in three weeks, which commits had human attention and which need gate-level scrutiny. The setting exists to customise, not to launder.
Frequently, and as a standing instruction. The harness has its own checkpointing and the documentation says plainly that it is not a git replacement.
Because that person is you. The operator is the only reader who was absent when the work happened, so "fixed the bug" is a note to nobody.
What this actually is
Assemble what an operated harness has forced into existence.
Multiple concurrent workers, each stateless beyond its window. A doctrine file every worker loads. A permission boundary. Verification gates that define done. Dispatch patterns. A metered budget. And a durable record system that is the real state of the enterprise, plus a history that functions as its audit trail.
That is not "like" an organisation. It satisfies the functional definition of one: persistent structure coordinating work by multiple actors toward ends, surviving the replacement of any individual actor.
The session is replaceable by design. Kill it, spawn another, it reads the records and continues — which is precisely the property that lets firms outlive employees.
Nothing in this structure signs contracts, bears liability, or decides which ends to pursue. Those never leave the operator and no tooling changes that.
And none of this is a throughput claim. It asserts a structure, not a speedup — the two get conflated constantly, and controlled studies of experienced developers using AI coding tools have found the same split more than once: developers estimating they were faster while measured completion time was slower. That gap between felt speed and measured speed is the standing reason to keep "structure" and "speedup" apart as claims.
A Zero-Employee Organization removes employees. It does not remove accountability.
What smart people get wrong
What to do this week
Run the kill test on your current work. Not hypothetically — close the session and try to resume from disk. Whatever you find missing is your first record to start writing.
Then pick one thing that must survive — the plan, the decision, the definition of done — and write it to a file at the moment it becomes true, for one week.
That is the whole transition. Not tooling. A habit about when things get written down.
Rot register
Verified 2026-08-05.
| Claim | Re-check at |
|---|---|
| Transcript retention and format stability | code.claude.com/docs/en/sessions |
| Worktree branch naming and isolation | code.claude.com/docs/en/worktrees |
| Attribution trailer settings | code.claude.com/docs/en/settings |
| Agent team resume limitations | code.claude.com/docs/en/agent-teams |
One month, for operators who already run something real and want to run it without hiring. We build the record system and the gates against your actual operations.
