Continuity: What Grok Build Keeps, Reconstructs, and Relearns
Grok Build's continuity problem begins when the current turn is no longer the whole story. A session may be resumed after a process exits, compacted when its context grows large, rewound after an unwanted turn, or supplied with project rules and optional memory. This chapter examines what Grok Build actually preserves and what it reconstructs. The practical goal is to distinguish durable session history from derived views, conversation rewind from workspace rewind, project instructions from cross-session memory, and remembered context from facts that still need verification.
Continuity is not one feature called “memory.” It is a collection of state transitions with different sources of truth, durability guarantees, and trust boundaries. Confusing them can produce a particularly dangerous kind of confidence: the agent appears to remember a decision, but what it has is an old summary; a conversation appears rewound, but files remain changed; a project rule appears authoritative, but it came from an untrusted directory.
What a session can recover
A Grok Build session stores more than user and assistant messages. Its persisted state can include summary metadata, ACP and xAI updates, chat history, plans, signals, usage, rewind points, workflow state, compaction artifacts, and relationships to forked or subagent sessions. That breadth reflects the runtime's lifecycle. A resumed session needs to know not only what the model said, but which model and agent definition were active, which worktree or working directory was involved, what task state survived, and what client-visible events can be replayed.
The most important distinction is between the update stream and the chat history derived from it. The session's updates record the chronological event surface: user-message chunks, agent messages, tool calls, tool updates, and extension notifications. The chat history is a convenient conversation representation rebuilt from that stream. If the derived history is missing or empty, the storage layer can reconstruct it from the updates rather than treating the cache as the only truth. This is a strong recovery choice because the event stream preserves distinctions that a simplified chat view may not.
The distinction also explains why a torn write does not necessarily destroy a session. JSONL appends can be interrupted, leaving an incomplete final line. The adapter uses append locking and can terminate a torn tail before writing the next record. When loading, malformed or unparseable lines can be skipped with a warning and the original file quarantined, allowing the rest of the session to load. That is not perfect preservation: skipped lines may mean that some history or display events are absent. But it is a deliberate choice to recover a usable session rather than make one damaged record brick the whole conversation.
Durability has levels. Fire-and-forget writes can remain buffered until a later barrier, so a hard power loss may remove the tail since the last successful synchronization. Operations that a caller awaits as a durability barrier flush and synchronize the dirty session files before acknowledging. Atomic-renamed files protect replacement writes from becoming half-written garbage, while directory synchronization helps make newly created session state durable.