Memory That Knows When to Resume—and When to Verify

In holaOS, memory is not one giant transcript and continuity is not the same thing as long-term knowledge. This chapter examines how the project separates standing policy, short-term resume state, durable recall, and retrieval-time verification. The practical value is calibration: the reader should be able to tell what the next run can restore cheaply, what it should retrieve only when relevant, and why an old remembered fact may still need a live check.

Consider the product-launch workspace from earlier chapters. An agent may pause while waiting for an approval, return days later with the latest session context, recall the team's preferred tone, and check whether a release date has changed before drafting a new announcement. Those are four different information needs. Treating them as one undifferentiated memory store would make the environment expensive to load, difficult to inspect, and prone to confusing old context with current truth.

Three kinds of state, three different jobs

The first kind is standing workspace policy. This is authored instruction such as the role an agent should play, the rules it must follow, or the conventions that apply on every run. It belongs in the workspace's instruction surface, not in an automatically generated recollection. Policy is normative: it tells the agent how the environment should operate.

The second kind is runtime continuity. Continuity helps the next run resume active work without replaying a full transcript. HolaOS stores normalized turn results, sanitized request snapshots, persisted harness-session state, recent-turn and blocker projections, session-memory snapshots, and session scratchpads. These records answer questions such as what the latest run was doing, what it was waiting for, or which working notes belonged to an interrupted session.

The third kind is durable memory. Durable memory contains knowledge meant to remain useful after the immediate run: a stable user preference, a project decision, a reusable procedure, a recurring blocker, a durable identity fact, or a reference that should be recalled later. It is smaller and more selective than continuity. A verbose error log or a one-off tool failure may matter while a run is active but usually does not deserve to become long-term knowledge.

This separation is a lifecycle rule. A session-memory snapshot can restore the latest blocker without asserting that the blocker is a permanent fact. A scratchpad can hold interim evidence without becoming a user preference. A durable procedure can be recalled in a new run without forcing the runtime to replay the conversation in which it was first discovered. The same information may move from one state to another only when its role changes and the system has a reason to preserve it.

The storage model reinforces the distinction. Canonical durable content is markdown-first. Workspace interaction leaves and semantic trees live with the workspace; integration evidence and profile-global preference or identity memory live under the configured global memory root. Semantic nodes, search documents, relations, and embeddings are derived structures over that markdown. If a derived index disagrees with a canonical file, the file is the durable source of truth that can be rebuilt.

Scope is equally important. Interaction memory belongs to a workspace and is shared by the different agents operating inside that workspace.