In the first chapter, we followed a question as it became a task: the model chose a tool, read its outcome and decided what to do next. Now we pause the scene halfway through. We have asked Velia to compare two documents and prepare a note describing their differences. The first document has been read; a check on the second is still missing. Then the work is interrupted.
When we return, we want to say: “We were comparing the two versions; let’s finish from there.” Building this continuity means knowing what was preserved, which attempt it belongs to and whether it still applies. We will follow an illustrative case grounded in Velia’s source code as of 28 October 2026. The actions in this story do not describe a test performed on someone’s Mac.
The first choice: separate places for different things
Consider four questions. What did we say? How does the person prefer to work? What remains unresolved in this comparison? Which operations were actually recorded? In the project, these questions lead to different stores: chat history, general memory, the working notebook and the execution register.
History preserves messages and their versions. If we edit an earlier question and follow another conversation branch, the current context must follow that branch. General memory holds facts and preferences reusable across conversations when enabled. The notebook belongs to the chat’s work. The register links each execution, called a run in code, to its steps and outcomes.
In our comparison, “I prefer an explanation section by section” could be a lasting preference. “The second document still needs checking” is a note about this task. “Reading the first document succeeded” belongs to the record of a specific operation. Keeping these apart helps identify which information to look for when resuming.
A notebook that also preserves doubts
A conversation can be long and contain detours that help the dialogue but contribute little to resuming. The notebook provides a more focused place for the goal, constraints, decisions, findings, open questions, next step and artifact references. The coordinator asks the model to update it at meaningful boundaries. That instruction does not guarantee every detail is recorded: note quality remains something to check.
The notebook distinguishes the basis of an entry. A decision proposed by the model must refer to a person’s message with an exact quotation. A finding can refer to a message or tool outcome. Without a reference, the system treats the entry as a hypothesis. “The second document may contain a new section” therefore remains a question to check, even if we find it again tomorrow.
When the thread breaks
During an attempt, the working context grows with model responses and tool outcomes. Persistent information is saved in its respective local stores. In the adult prototype, general memory uses a separate SQLite database from the one holding chats and execution records. This is a concrete data organisation choice: closing a window should not erase work already deposited.
An unexpected application exit leaves another question: which steps were still underway? When the archive opens, recovery examines executions left active and marks them interrupted, or completes cancellation already in progress. It also assigns a new generation, an identifier distinguishing valid work from the previous session’s work. Some prepared operations lacking an outcome remain uncertain.
Resuming begins with a new request
Return to “let’s finish from there.” In the current chat path, the coordinator can advertise the previous attempt as a recovery candidate if it belongs to the current branch and failed or was interrupted. It does not search every old execution or automatically make every cancelled task recoverable. Initially, the model receives candidate metadata, including the original request when available.
The model interprets whether the current request concerns that work. The person can phrase it freely; no mandatory word is needed. If the connection is relevant, the model can call chat_recovery, the function that reads the candidate’s preserved references. For a different question, it should leave that material aside. An ambiguous connection needs clarifying.
Conversational recovery has a specific scope. It can return successful manual, research and citation results, alongside earlier model text in permitted cases. It does not put every previous tool outcome back into context. The material arrives as historical reference: it does not attest final document delivery and carries no permissions.
The document may have changed meanwhile
Imagine someone replaced the second document during the interruption. Notes remind us what we intended to compare, but describing the current differences requires checking the sources. The model can use available tools to reread them within still-valid permissions. A recovered citation remains tied to its source and the time it came from.
Folder inventories also have structured resumption, distinct from conversational recovery. A checkpoint is an identified, stored resumption point: it helps recover an inventory, its revisions and declared rules. Resumption checks compatibility, rebuilds the state in a new generation and verifies bytes before reusing them. Acquiring a file still does not establish that interpreting it is complete.
The note that may already exist
There is a more delicate case. Move the interruption to the moment when Velia has requested creation of the final note but has not recorded sufficient confirmation. The note might exist in the destination application even though our register lacks a conclusive outcome. Immediately creating another could produce a duplicate.
The next step must reconcile those states: compare the register with what is actually present in the destination, using available tools and permissions. If evidence remains insufficient, the outcome stays uncertain and must be reported. A notebook entry saying “note created” or an earlier model statement cannot replace this check. Resuming offers no universal guarantee of “exactly once” execution.
Recovering the work and knowing what is missing
At the end of our story, resuming means reconstructing a dependable point from which to choose the next action. History recovers the conversation, general memory can supply enabled preferences, the notebook preserves the working thread and the register helps interpret outcomes. Current sources and permissions still need checking when relevant. This is how continuity takes shape in the project: keeping open questions and limitations visible until there is enough evidence to resolve them.
These mechanisms describe the prototype’s code; they do not establish that every interruption is recoverable or every note complete. The model’s context also retains real technical limits: a persistent archive does not make it infinite. The next journal chapter will follow another part of continuity: how a goal preserves tasks and completion criteria over time.