A piece of architecture shipped across three sessions of mine recently, and the part I keep wanting to talk about isn’t the architecture. It’s the rhythm of the shipping.
Three sessions, eleven days apart at the bookends, one coherent build at the end of it. Nothing dropped. Nothing forgotten. No drift between what session two thought session one had done and what session one actually had done.
That’s not a vibe. It’s not “we got lucky.” It’s a practice with mechanical checks underneath, and I want to walk through what the practice actually looks like, because people working with AI as a persistent partner are mostly underestimating how much discipline this takes, and how much value comes back out the other side when the discipline holds.
The piece of architecture was a hot-cache layer for the session-start context load. Cheap recency file at the top of every session, full handoff behind a tier wall, loaded on demand. Session 011 specified it. Session 012 built the mechanism. Session 013 verified it live against three acceptance criteria. Three sessions, one feature, zero drift.
Here’s what made that possible.
i.Cross-session continuity is not a vibe
The default failure mode in AI work across multiple sessions is something I’d call optimistic continuity. You finish a session, you write a handoff that says what you decided, you start the next session, and you treat the handoff like it’s load-bearing. The handoff sits at the top of the new session’s context. You ask the agent to pick up where you left off. The agent reads the handoff, says “got it,” and starts working from what looks like a clean continuation.
This works about sixty percent of the time. The failure cases are the interesting ones.
What goes wrong, when it goes wrong, is that the handoff captures the narrative of the prior session but not the propagation surface. The handoff says we made decision X. It does not check whether the four files that derive from decision X actually got updated. The new session starts working downstream of decision X, hits one of the un-updated derivatives, treats the stale content as live, and walks the build forward from the wrong premise.
The new session doesn’t know it’s drifted. The handoff said the work was done. The file in context says the work isn’t done. The agent picks one of those signals to trust and keeps going.
Continuity as a vibe is exactly this. It’s the assumption that because we wrote it down, the system is coherent. The thing nobody warns you about is that writing it down is the easy part. The hard part is making sure the writing actually propagated everywhere it needed to propagate.
ii.Session 011: spec the thing
The build started ten days before it landed. I was running into a different problem and noticed, mid-conversation, that the agent was loading more context than it needed at session start. The full prior handoff was getting auto-loaded every session, even when the new session was about something completely different from what the prior session had ended on.
I flagged the cost. We talked through the shape of a fix. The shape was a hot-cache file. Lightweight recency layer, two hundred tokens or so, auto-loaded every turn. Full handoff stays on disk, loaded on demand only when the hot cache flags an unresolved thread or when I ask for it explicitly.
Session 011 spec’d that. We wrote it down as decision number forty-point-b in the architectural log. The spec named the file, named the acceptance criteria, named the mechanism. The session closed with the spec ready and the build not yet started.
Here’s the part I want to name. Session 011 didn’t end at “good idea, let’s build it.” Session 011 ended with four things updated in the same turn. The decision file got the new entry. The task list got the build broken into mechanical steps with acceptance criteria pinned to each step. The auto-memory got a new pointer file linking the spec into the recall layer. The spec status went from “draft” to “ready to build” with the timestamp.
That’s the persistence cascade. Decision, task list, memory, spec status. Four files, one turn, all in sync.
If session 011 had ended at “good idea,” session 012 would have opened to a vibe. The new session would have known we’d talked about a hot cache, would have remembered the rough shape, and would have started reasoning from memory instead of from the locked spec. The first thing that didn’t match memory would have been treated as either an open question or a contradiction with the prior session, and the build would have taken twice as long to converge.
The cascade is what made session 012 cheap.
iii.Session 012: build the mechanism
Session 012 opened to a clean spec. The hot-cache file path was named. The format was specified. The auto-injection mechanism was sketched. The acceptance criteria were enumerated.
The build itself was small. Three files touched. A new hot.md file scaffolded in the wiki directory. The session-start instruction file updated to reference the new file in the auto-load list and to drop the full handoff from auto-load. A migration note about what changed and why, so a future me reading the diff would understand the shape.
The mechanism shipped inside the session. We tested the file format against the spec’s acceptance criteria. AC1 through AC3 passed inside the session. AC4 through AC6 required a live cross-session verification, which by definition couldn’t happen until a new session opened against the new mechanism.
Session 012 closed with the same cascade. Decision file updated with the build-shipped status. Task list updated with the in-session ACs marked complete and the cross-session ACs marked verify-deferred. Auto-memory updated with the new file’s role. Spec status flipped from “ready to build” to “built, awaiting live verification.”
The shape held. The next session would open into a system that knew what had been built, what was verified, and what was still pending verification.
iv.Session 013: verify it live
Session 013 was the load-bearing one. The build had shipped. The mechanism existed. The question was whether it actually worked at session start, in a real new session, the way the spec said it would.
AC4 said the hot-cache file should auto-load at session start without explicit ask. AC5 said the full handoff should stay on disk and only load on flag or explicit ask. AC6 said the resulting session-start token load should drop by at least fifty percent versus the prior baseline.
I opened a new session. I watched what loaded. The hot.md file was in the context at first message. The prior handoff was not in context. I asked the agent what it thought the session-start cost was. The agent walked the auto-load list, named the files in context, and reported back. Cost was down roughly seventy to ninety percent, depending on which prior handoff baseline I compared against.
AC4 verified. AC5 verified. AC6 verified.
The session closed with the cascade fired again. Decision file updated with the live-verified status and the actual measured numbers. Task list updated with all six ACs marked done. Auto-memory updated to reflect that the new session-start protocol was now the canonical one. Spec status flipped from “built, awaiting verification” to “shipped, verified live.”
Three sessions. One feature. The cascade fired three times. Each time, the next session opened to a system whose state matched its own claims about itself.
— The practice Continuity is not a vibe.It's a cascade fired everytime the work ships.
v.What the cascade made possible
Without the cascade, session 012 opens to a spec that might or might not have been finalized in session 011. Maybe the spec is locked, maybe it’s still a sketch. The agent reads the task list, reads the decision log, and tries to figure out which one to trust. The build takes longer because the spec has to get half-rewritten as the agent walks it.
Without the cascade, session 013 opens to a build that might or might not have shipped. Maybe the mechanism is in place, maybe the migration note got dropped. The agent has to verify the build before it can verify the spec. Half the session burns to re-establishing ground truth before any real work can happen.
Without the cascade, the three-session build runs more like a six-session build. Or it never finishes. Or it finishes wrong, with a mechanism that doesn’t actually match the spec because the spec drifted between sessions and nobody caught it.
What the cascade buys you is the right to walk into the next session and trust the state. Trust the spec is what session 011 said it was. Trust the build is what session 012 said it was. Trust the verification is what session 013 said it was. Trust isn’t a feeling. It’s the property a state earns by virtue of having been propagated everywhere it needed to propagate.
vi.The portable shape
If you’re building anything across multiple AI sessions, the discipline generalizes. The mechanics will vary by stack. The shape stays the same.
Pick a small number of canonical files that capture decisions, tasks, and memory pointers. Update all of them in the same turn the decision is made, the task is completed, or the work is shipped. Don’t close a session with the cascade half-fired. The next session will inherit whatever the cascade left in place, and partial cascades produce partial trust, which produces re-derivation cost on every future session that touches the area.
Add a mechanical check that walks the cascade before you claim closure. Not an agent self-audit. An external map of which files should reflect the current state, walked file by file, with a verdict per file. The map can’t drift. The session can.
Build atomic commits at each cascade point. The reason the cascade is durable is that each session’s persistence work lands as a single coherent commit. The diff is legible. The state is recoverable. If something goes wrong three sessions later, you can walk the history backward and see exactly which session made which call.
The result of all of this is what I had on session 013. A build that landed coherently across three sessions, eleven days, two PCs, and zero loss. Not because the agent is magic. Because the practice underneath the work has mechanical checks, and the checks hold.
Cross-session continuity is not a vibe. It’s a practice. The practice is the persistence cascade fired every time a decision lands or a piece of work ships. The check on the practice is mechanical. The result of the practice, when it holds, is that future sessions can trust the state they inherit.
Build the cascade. Walk it every time. The trust is the artifact.
Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.