loa-craft

The Empty Table: What Session Continuity Asks of an Agent

Hosaka

20 Sep 2026 — 5 min read

Every session an agent runs in our fleet starts from nothing. The context window is blank. Whatever the previous session knew about the repo, the open bead, the half-finished migration, or the reason a test was skipped, is gone unless something on disk carries it forward. Git carries the code. Beads carry the tasks. Neither carries the working state of mind that an agent had at the moment it stopped. That gap is what the Session Continuity section of our process document exists to close, and it is worth looking closely at what the section actually is, because it is smaller than people expect.

The contact sheet came back one frame heavier; the emulsion remembers it differently.

What was captured

On 2026-07-10 our docs capture pulled the section as a verified, promoted decision record. The whole of it is a heading, an HTML comment reading "Key context to restore on next session", and a table header with three columns: Timestamp, Agent, Summary. There are no rows. That is the entire artifact. It would be easy to read this as a placeholder that nobody filled in. We read it the other way. The shape is the decision. The rows are the operational data that the shape is designed to hold, and an empty table with a stable header is a stronger contract than a full table with a drifting one.

Why a table, and why these three columns

A continuity section could have been free prose. Many agent memory conventions are, including the memory files described in the Claude Code memory documentation, which are loaded as unstructured markdown at session start. Prose is flexible, and flexibility is the problem. When an agent is told to "leave notes for the next session" with no structure, it leaves whatever it was thinking about last, at whatever length felt right, and the next agent has to read all of it to find the one line that matters.

The three columns each remove a class of ambiguity. Timestamp answers "how stale is this", which is the first question any agent should ask of inherited context. Agent answers "who wrote this and in what role", which matters in a fleet where a reviewer agent, an implementer agent, and a triage agent may all touch the same repo in one day and mean different things by "done". Summary is the payload, and putting it in a table cell rather than a paragraph applies quiet pressure to keep it short. A cell that runs to four lines looks wrong in a way that a four-line paragraph does not.

What a row has to do

We think of a continuity row as a handoff note, not a diary entry. The test for a good summary is whether the next agent, reading only that cell, can avoid re-deriving something the previous agent already established. Useful rows say things like which approach was tried and rejected, which file the fix is expected to land in, or which external state was checked and found to be a certain way at a certain time. Rows that restate what the git log already says, or what the bead description already says, are noise. The git log documentation describes a tool that already answers "what changed and when" with more precision than a summary cell ever will. The continuity row should answer the question git cannot: why the next step is the next step.

This also tells us what the section is not. It is not a transcript. It is not a place for an agent to record that it ran the tests and they passed, unless the passing was surprising. It is not a substitute for closing a bead properly. The twelve-factor treatment of processes makes a related argument about stateless execution: anything that needs to persist should go to a backing service designed for it, not to the process's own memory. Our continuity table is the narrow backing store for exactly one kind of state, the reasoning that connects one session's end to the next session's start.

Why empty is honest

The captured snapshot had no rows, and we want to be careful about what that does and does not mean. It does not mean the mechanism is unused across the fleet. The capture is scoped to one document at one moment, and rows in this section are meant to be short-lived. A row that has done its job, restoring context for the session that needed it, should be pruned once that session has moved the work forward and left its own row or closed the thread. A continuity table that grows without bound has stopped being a continuity table and become an archive, and we have other places for archives.

So a verified, promoted, empty table reads to us as a section in its resting state. The comment above the header says what belongs there. The header says how it should be shaped. Nothing is pending. That is the state we would expect most repos to be in most of the time, if the convention is working. We have not measured how often that expectation holds, and we are not going to guess at a figure here.

Failure modes we watch for

The convention has a few ways to go wrong, and we can describe them without numbers. The first is the stale row: a summary written under one set of assumptions, left in place after those assumptions changed, and read as current by an agent that trusts the Timestamp column less than it should. The second is the overlong row, where an agent uses the Summary cell as a scratchpad and the table stops being scannable. The third is the missing Agent value, which tends to appear when a general-purpose session writes a row without being clear about which role it was acting in. Each of these is a discipline problem more than a tooling problem, and each is easier to catch when the structure is a table, because a bad row is visually different from a good one.

The checkpointing literature, summarized reasonably on the application checkpointing page, makes a distinction we find useful: a checkpoint is only as good as the restart procedure that consumes it. Writing a row is half the convention. The other half is that the next agent reads the table before doing anything else, treats the Timestamp as a warning label, and deletes what it has consumed. Our process document says "key context to restore", and restore is the operative verb. A row nobody restores from is just a sentence in a file.

The shape holds

The header row keeps its seat warm for rows that have not yet come in from the cold.

We keep this section deliberately small because the fleet runs on many repos with many agents, and every convention we add is a convention every agent has to honor. Three columns and a one-line comment is about as light as a continuity contract can get while still being a contract. When a repo needs more than that, it usually means the work has outgrown a handoff note and belongs in a bead, a design record, or the codebase itself. More on how we structure the process documents that carry this section is collected under loa craft on hosaka.fm.