The Session: An External Append-Only Log So Work Survives the Machine
The session is the durable state object that connects the brain (the agent loop) to the hands (the ephemeral sandbox), defined by agent-topology as the third leg of the split. Concretely it is an append-only event log: the canonical record of everything that has happened in a task, written one event at a time and never rewritten. The one property that makes it load-bearing is where it lives. The log is stored durably outside both the brain and the hands, on no single machine.
Anthropic calls it "the append-only log of everything that happened," held outside the harness and the sandbox (Scaling Managed Agents). Shopify backs the same object with Postgres and states the consequence directly: "the work picks up where it left off because the work lives in Postgres, not in memory" (Shopify case study). The handbook is funded by Wallfacer Technologies.
Because the state is off the machine, every machine in the loop becomes disposable. A crashed brain, a dead sandbox, an idle task whose host got reclaimed: each is a replay from the log on a fresh host, not a lost task. That same property is why the session is the easiest audit trail a team can have. The record an auditor reads after the fact is the record that resumed the work. The compliance half is the audit trail property.
State inside the machine dies with the machine
Anthropic's first design put the session, the harness, and the sandbox in a single container. They name the failure plainly: they had adopted a pet. If a container failed, the session was lost; if a container was unresponsive, an engineer had to nurse it back to health. The only debugging window was the WebSocket event stream, which could not say where a failure arose. A harness bug, a dropped packet, and a dead container all presented identically. The remaining option was to shell into a container that also held user data, which, as they put it, "essentially meant we lacked the ability to debug."
This is the laptop model's failure repeated one level down: state coupled to a specific machine dies with that machine. The fix is the same in both cases. Move the state out. (For why per-task sandboxes are the right unit to make disposable, see one environment per task.)
What a session holds: events, transcript, context, kept separate from the context window
A session is the event stream plus what it renders into, not the model's context window. The model's context window is a working set the harness assembles per turn; the session is the durable superset the harness assembles it from.
- Events. The append-only stream. Every model call, tool call, tool result, and decision is written as it happens with
emitEvent(id, event)(Anthropic). The order is the history. - Transcript. The human-readable conversation reconstructed from the events. Shopify makes this a first-class artifact: River runs only in public Slack channels, so "every session is a searchable, reproducible transcript" (Shopify case study).
- Context, on demand. The brain interrogates the log through
getEvents(), pulling positional slices, rewinding to the lead-up before a specific action, or rereading old context (Anthropic).
Anthropic argues against treating the context window as the record. Context-management techniques such as compaction and trimming make irreversible decisions about what to keep, and it is hard to know which tokens future turns will need. The session avoids that by being lossless. The division of labor: the session guarantees only that events are durable and available, while all transformation, summarization, and cache-friendly reorganization happens in the harness, which can change freely as models change.
Marker events. A working implementation interleaves bookkeeping events among the conversational turns: turn-boundary markers recording that an exchange finished, queue-management records, generated-title events, file-reference markers. On a completed turn, the tail of the log is the turn-boundary marker, not the assistant's reply.
Logic that assumes "the latest event is the assistant's message" misfires silently on every completed exchange. Give every event an explicit type field and filter on it: a transcript renderer keeps user and assistant and skips the markers, and a completion trigger filters the same way before checking the tail.
Append-only and event-sourced: the log is the source of truth, not a side effect
The session is event-sourced. State is not stored and mutated. It is derived by replaying the event stream from the start, and new facts are appended rather than overwritten. Shopify's phrase for it is "the canonical truth about what's happened so far" (Shopify case study). Anthropic's interface enforces the same shape: the harness writes with emitEvent and reads with getEvents; there is no edit-in-place (Anthropic).
Two properties fall out of append-only. Ordered means the stream replays forward deterministically, which is what makes resume possible. Immutable means an event written at turn one is the event read at turn fifty, which is what makes the log trustworthy as evidence.
Resume is a replay, and idle eviction proves the point
In the decoupled design, nothing in the brain needs to survive a crash because the log sits outside it. When a harness fails, a new one boots with wake(sessionId), fetches the log with getSession(id), and resumes from the last event (Anthropic). A dead sandbox is the same story from the other side: the harness catches the failure as a tool-call error, passes it to the model, and a fresh sandbox is re-provisioned with a standard recipe.
Idle eviction is the case that shows state is genuinely off the machine, because nothing crashed. Shopify lets an idle session's process exit on purpose. When the next interaction arrives, the platform spawns a fresh "session cell," possibly on another host, and rehydrates it from Postgres. The sandbox is reclaimed when no one is using it; the session persists; the next message wakes the work somewhere else with no loss. Shopify reports tens of thousands of sessions in a recent 30-day window (Shopify case study), so eviction-and-rehydration is the common path, not a rare recovery branch.
Resume on a fresh machine is also the mechanism behind the four-transfer standard. A human taking over a task needs the conversation and the process state, and the session log already holds both. Takeover is a wake() with a person on the other end.
The same log the auditor reads
Intercom's AI review system shows what the session becomes under audit: every AI-approved PR is "labelled, logged, and queryable," because "the evidence an auditor expects to see is the same whether a human or an AI approved the change. The 'who' may change, but the 'what' doesn't." Their auditors confirmed the evidence meets SOC 2 and the other frameworks they hold.
The link is structural, not coincidental. The properties that make a log a good resume mechanism are the properties that make it good audit evidence: complete (every event written as it happens), external (survives the death of any one component), and ordered-and-immutable (replayable forward for resume, queryable backward for audit). A team that builds the session for reliability gets audit evidence as a byproduct, and a re-runnable history is the same artifact compliance reads as reproducibility. A team that skips the external log has neither.
A managed substrate frames this object cleanly. Wallfacer's published design includes an external append-only session-event log as the session, mapping onto this split by construction, though it publishes no customer-scale throughput numbers and its row is a design to evaluate rather than results to bank (Wallfacer case study).
The reports give you the object, not the audit-grade controls
The published interfaces specify the session's shape and durability, and nothing an auditor would ask next. They are silent on retention windows, on access control over the log, on whether append-only is enforced at storage or only by convention, and on querying across sessions by actor or time range. Those are compliance requirements layered on top of the artifact, not properties the interfaces guarantee. The architecture hands you the right object; making it audit-grade is your work, and the audit trail property spells out the bar.