[DISCUSS] Session, Filesystem, and Memory as durable storage views

[likun666661]

Context

The conclusion of Beyond Function Calling describes a cloud-agent architecture with durable Session state in inexpensive object storage and disposable compute supplied by isolates, containers, or microVMs.

That separation suggests a deeper data-model question: should Session, Filesystem, and Memory be treated as three durable storage views rather than three unrelated Agent capabilities?

This discussion is architectural framing, not an implementation proposal. It does not replace the scoped Memory work in #4426 or the Sandbox authority question in #4594.

Thesis

Session, Filesystem, and Memory answer different queries over durable Agent state:

Surface	Primary address	Question it answers
Session	time, event identity, causality	What happened?
Filesystem	path, version, snapshot	What exists at this workspace location?
Memory	semantic key, entity, relevance	What prior fact matters now?

The three surfaces can share one durable substrate while retaining different indexes, consistency contracts, and authorization boundaries.

                         Durable Storage

              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
        Temporal View       Path View       Semantic View
           Session          Filesystem          Memory
         Event Log          Snapshot            Index
              │                │                 │
              └────────────────┼─────────────────┘
                               ▼
                        Context Projection
                               ▼
                              LLM

Under this model:

• Session history is an append-only sequence of Runtime facts.
• A durable Workspace is a versioned path projection backed by snapshots, manifests, chunks, or persistent volumes.
• Long-Term Memory is durable data plus semantic, temporal, or entity indexes used to retrieve a bounded projection.
• Model context is Working Memory and remains ephemeral compute state. It is reconstructed by querying the durable views.
• A sandbox-local filesystem may be disposable scratch space. Only committed Workspace state belongs to the durable Filesystem view.

Session is slightly different from an ordinary storage API. It can serve as the root namespace connecting the other views:

Session Root
├── Event Log Head
├── Workspace Snapshot
├── Memory References
├── Artifact References
├── Branch / Parent Lineage
└── Active Operation Metadata

Three-plane architecture

The storage-compute split becomes clearer when separated into three planes:

Storage Plane
  immutable event segments, artifacts, workspace snapshots, memory records

Control Plane
  heads, leases, CAS, admission, permissions, T1/T2 operation state

Compute Plane
  model inference, tool execution, Code Mode, compaction, indexing

The Storage Plane contains the large and durable bodies of state. S3-compatible object storage is a natural target for immutable segments, artifacts, and snapshots.

The Control Plane remains small and strongly consistent. Object storage alone does not provide every coordination primitive needed by an active Agent. Advancing a Session head, preventing duplicate continuation, tracking in-flight side effects, and assigning resource leases still require CAS, durable operation identities, or another authority with explicit linearization semantics.

The Compute Plane is replaceable. A Session can rent a small model for routine work, a stronger model for difficult judgment, a V8 isolate for orchestration, a Python container for data processing, or a microVM for full operating-system tools. No individual model or worker owns Agent identity.

Consequences

A long-running Agent does not require a long-running process

Most Sessions can remain dormant in object storage. A user message, timer, webhook, or completed background operation triggers rehydration onto available compute. New facts and Workspace changes commit back to storage, after which the worker can disappear.

Cost becomes proportional to active thinking and execution rather than the number of retained Sessions.

Model context becomes a query

Compaction, Tool Result pruning, visibility filtering, provider compatibility, and Memory retrieval become projection policies over durable state. The prompt is a bounded read model, not the authoritative Session.

Filesystem tools become storage protocols

Read, Edit, and apply_patch look like model capabilities, but their durable meaning is access to a versioned Workspace view. A POSIX mount inside one sandbox is an execution projection. Canonical identity, version checks, atomic commit, and snapshot lineage belong to the storage or resource authority.

Memory tools become indexed retrieval protocols

The model does not own Long-Term Memory. memory_search and memory_get query durable records under an authorized Scope and project a bounded result into context. Exact, prefix, lexical, vector, entity, and temporal indexes can evolve without redefining Agent identity.

Branch and Fork become cheap

Append-only event prefixes and copy-on-write Workspace snapshots let several Agents share history and immutable artifacts. A child Session can reference a parent prefix and snapshot, then pay storage only for its new suffix and changed objects.

Recovery becomes worker-independent

A lost worker discards volatile stacks and promises, not the Session. Runtime recovery first resolves Tool operations through committed T1/T2 facts, then constructs a fresh execution from a verified prefix on new compute.

Important boundary

Storage-compute separation does not make external side effects transactional. Email, payments, Browser actions, and remote APIs still live outside the Session store. The more disposable workers become, the more the Runtime depends on durable dispatch boundaries, idempotency keys, reconciliation, and Resource Authorities to establish what happened in the real world.

Likewise, calling all three surfaces storage views does not require one universal physical database or one universal consistency model. Temporal history, filesystem paths, and semantic recall can share durable object storage while using specialized metadata stores and indexes.

Questions

1. Is the temporal / path / semantic view model a useful long-term abstraction for Maka?
2. Should Session become the root durable namespace referencing Workspace, Memory, Artifact, and lineage state?
3. Which state must remain in a strongly consistent Control Plane, and which state can move to immutable object segments?
4. Should durable Filesystem commits and RuntimeEvent commits share one operation identity or remain independently reconcilable?
5. Is Long-Term Memory authoritative data, a rebuildable projection from RuntimeEvents, or a mixture of accepted records and derived indexes?
6. What is the minimum Session Manifest needed to rehydrate execution on a new worker without binding the Session to one sandbox implementation?
7. Can this model support local-first Maka and cloud-hosted Maka through the same logical contracts with different storage backends?

Related discussions

• Proposal: expose bounded memory_search and memory_get over the existing memory_item store #4426 proposes bounded model-facing reads over the existing memory_item store.
• Should Host-spawned stdio MCP servers run under SandboxPolicy? #4594 asks where Sandbox authority should apply to Host-spawned MCP processes.
• feat(runtime): coordinate tool batches through resource authorities #4542 discusses parallel Tool scheduling and the separation between batch orchestration and Resource Authority.

AI assistance disclosure: OpenAI Codex helped structure and draft this discussion; reviewed and posted by me.

中文

背景

Beyond Function Calling 的结尾描述了一种 Cloud Agent 架构：Session 的持久状态存放在廉价对象存储中，Isolate、Container 或 MicroVM 则提供即用即弃的计算资源。

这种存算分离进一步引出了一个数据模型问题：Session、Filesystem 和 Memory 是否应该被视为 Agent Durable State 的三种存储视图，而不是三种互不相关的 Agent 能力？

本 Discussion 讨论的是长期架构模型，不是具体实现提案，也不会取代 #4426 中已经收窄的 Memory 工作或 #4594 中关于 Sandbox Authority 的讨论。

核心命题

Session、Filesystem 和 Memory 对 Agent 的持久状态提出了三类不同查询：

表面能力	主要寻址方式	回答的问题
Session	时间、事件身份、因果关系	发生过什么？
Filesystem	路径、版本、快照	Workspace 的这个位置存在什么？
Memory	语义键、实体、相关性	哪条历史事实与当前任务有关？

三者可以共享同一套持久化底座，同时保留不同的索引、一致性协议和授权边界。

                         Durable Storage

              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
        Temporal View       Path View       Semantic View
           Session          Filesystem          Memory
         Event Log          Snapshot            Index
              │                │                 │
              └────────────────┼─────────────────┘
                               ▼
                        Context Projection
                               ▼
                              LLM

在这个模型中：

• Session History 是一串 Append-Only Runtime Facts。
• Durable Workspace 是按路径组织的版本化视图，底层可以由 Snapshot、Manifest、Chunk 或 Persistent Volume 支撑。
• Long-Term Memory 是持久记录，以及用来生成有界检索投影的语义、时间或实体索引。
• Model Context 是 Working Memory，属于易失的计算状态；它通过查询这些持久视图重新构造。
• Sandbox Local Filesystem 可以只是临时 Scratch Space，只有已提交的 Workspace State 属于 Durable Filesystem View。

Session 与普通存储 API 略有不同。它可以成为连接其他视图的根命名空间：

Session Root
├── Event Log Head
├── Workspace Snapshot
├── Memory References
├── Artifact References
├── Branch / Parent Lineage
└── Active Operation Metadata

三层架构

把存算分离进一步拆开，可以得到三个 Plane：

Storage Plane
  immutable event segments, artifacts, workspace snapshots, memory records

Control Plane
  heads, leases, CAS, admission, permissions, T1/T2 operation state

Compute Plane
  model inference, tool execution, Code Mode, compaction, indexing

Storage Plane 保存体积庞大且需要长期持久化的状态。S3-Compatible Object Storage 很适合承载不可变 Event Segment、Artifact 和 Snapshot。

Control Plane 体积很小，但需要强一致。对象存储无法独立提供 Active Agent 所需的全部协调语义。推进 Session Head、防止重复 Continuation、跟踪未完成副作用以及分配 Resource Lease，仍然需要 CAS、Durable Operation Identity 或拥有明确 Linearization Point 的 Authority。

Compute Plane 则可以被替换。一个 Session 可以为普通工作租用小模型，为复杂判断租用强模型，为编排租用 V8 Isolate，为数据处理租用 Python Container，为完整操作系统工具租用 MicroVM。Agent Identity 不属于其中任何一个模型或 Worker。

推论

Long-Running Agent 不要求 Long-Running Process

绝大部分 Session 可以休眠在对象存储中。User Message、Timer、Webhook 或后台任务完成事件到来时，系统才把 Session Rehydrate 到可用计算资源上。新事实与 Workspace 修改提交回存储后，Worker 即可消失。

系统成本因此取决于正在思考和执行的 Session 数量，而不是保存的 Session 总量。

Model Context 是一次 Query

Compaction、Tool Result Prune、Visibility Filter、Provider Compatibility 和 Memory Retrieval 都可以理解为 Durable State 上的 Projection Policy。Prompt 是一份有界 Read Model，不是权威 Session 本身。

Filesystem Tool 是存储访问协议

Read、Edit 和 apply_patch 表面上是模型能力，其持久语义是访问版本化 Workspace View。Sandbox 内的 POSIX Mount 只是执行投影。Canonical Identity、Version Check、Atomic Commit 和 Snapshot Lineage 属于 Storage Authority 或 Resource Authority。

Memory Tool 是带索引的检索协议

模型本身不拥有 Long-Term Memory。memory_search 与 memory_get 在授权 Scope 内查询 Durable Record，再把有界结果投影进 Context。Exact、Prefix、Lexical、Vector、Entity 和 Temporal Index 可以独立演进，而不需要重新定义 Agent Identity。

Branch 与 Fork 变得廉价

Append-Only Event Prefix 和 Copy-on-Write Workspace Snapshot 允许多个 Agent 共享历史与不可变 Artifact。Child Session 只需要引用 Parent Prefix 和 Snapshot，并仅为新后缀与修改后的 Object 支付存储成本。

Recovery 不再依赖 Worker

Worker 丢失时，消失的是易失的 Stack 和 Promise，不是 Session。Runtime 首先依据已提交的 T1/T2 Facts 收敛 Tool Operation，再从可信 Prefix 在新计算资源上构造执行。

重要边界

存算分离不会让外部副作用自动获得事务语义。Email、Payment、Browser Action 和 Remote API 仍然位于 Session Store 之外。Worker 越容易被丢弃，Runtime 就越依赖 Durable Dispatch Boundary、Idempotency Key、Reconciliation 和 Resource Authority 来确认现实世界中发生过什么。

同样，把三个表面能力都称作 Storage View，并不意味着必须使用同一个物理数据库或统一的一致性模型。Temporal History、Filesystem Path 和 Semantic Recall 可以共享 Durable Object Storage，同时采用专门的 Metadata Store 与 Index。

讨论问题

1. Temporal / Path / Semantic View 是否适合作为 Maka 的长期抽象？
2. Session 是否应该成为引用 Workspace、Memory、Artifact 和 Lineage State 的根持久命名空间？
3. 哪些状态必须留在强一致 Control Plane，哪些状态可以迁移到 Immutable Object Segment？
4. Durable Filesystem Commit 与 RuntimeEvent Commit 应该共享同一个 Operation Identity，还是保持独立并允许 Reconcile？
5. Long-Term Memory 是权威数据、RuntimeEvent 的可重建 Projection，还是 Accepted Record 与 Derived Index 的组合？
6. 在不把 Session 绑定到具体 Sandbox 实现的前提下，能够支持新 Worker Rehydrate 的最小 Session Manifest 是什么？
7. 这套逻辑契约能否通过不同 Storage Backend，同时支持 Local-First Maka 与 Cloud-Hosted Maka？

相关讨论

• Proposal: expose bounded memory_search and memory_get over the existing memory_item store #4426 提议在现有 memory_item Store 之上提供有界的 Model-Facing Read。
• Should Host-spawned stdio MCP servers run under SandboxPolicy? #4594 讨论 Sandbox Authority 应该如何覆盖 Host 启动的 MCP Process。
• feat(runtime): coordinate tool batches through resource authorities #4542 讨论 Parallel Tool Scheduling，以及 Batch Orchestration 与 Resource Authority 的职责分离。

AI assistance disclosure: OpenAI Codex helped structure, translate, and draft this discussion; reviewed and posted by me.

[me2seeks]

Thanks for framing this as views rather than capabilities — the temporal / path / semantic split holds up well when I map it against the current codebase. A few observations on the open questions, grounded in what exists today:

On Q2 (Session as root namespace): the Session Root works well as a navigation root, but I don't think it can be the authority root. Some durable state is not session-scoped: Long-Term Memory today lives in an instance-wide store, not under any session; credentials are explicitly excluded from Session Bundles; and discovery itself ("which Sessions exist?") cannot be answered from inside any Session. The view model stays intact if the root moves one level up — an instance-level root that references per-Session heads, with Session remaining the unit of execution and continuation.

On Q3 (what must stay strongly consistent): heads, leases, and operation records — but I'd add a precondition: commits must carry facts, not payloads. On a real local install I see ~47KB per model_call event and ~900KB per-step provider request snapshots. If an ordered commit pipeline serializes payloads of that size, one slow or stalled commit blocks everything behind it. Facts belong in the ordered log; payloads belong in immutable content-addressed objects referenced by digest — which is exactly what the Session Root sketch already does for Artifacts and Memory.

On ordering scope (relates to Q4): ordering is only needed between writes that can conflict, and writes only conflict within one Session. A single global order across all Sessions would make unrelated Sessions queue behind each other — with several concurrent local Sessions this is observable, not theoretical. Scoping the order per Session ledger also matches what #4662 already implements: its commit CAS is keyed on {sessionId, expectedRevision}. Cross-Session facts (roster, Memory heads) are low-frequency and can live on a small instance-level ledger; the rare cross-ledger operation can be correlated with an operation identity rather than requiring global atomicity.

On leases: two local processes resumed the same Session here and proceeded to contend on the SQLite lock and duplicate provider calls. So the head/lease authority is not only a cloud concern — local-first needs the same fencing, otherwise "sync the files" silently becomes last-writer-wins.

On Q7 (one contract for local and cloud): yes, if local SQLite is demoted to a rebuildable materialization of the committed history. Then local mode is just a file-backed adapter over the same two ports (immutable blobs + head CAS), and read latency is unchanged because queries still hit the local projection.

Related: #4662 (per-Session head CAS, already merged-direction), and this roaming Agent Home RFC draft which explores the instance-level root and single-writer fencing: https://gist.github.com/M4n5ter/bdbc27f190c1461c74f50db95c73e07e

中文版本

感谢把这个问题框定为"视图"而不是"能力"——时间 / 路径 / 语义的三分法对照当前代码库是成立的。基于现状，对几个开放问题提一些观察：

关于 Q2（Session 作为根命名空间）： Session Root 作为导航根是成立的，但作为权威根我认为不行。有些持久状态天然不属于任何 session：长期记忆目前存在实例级的存储里，不挂在任何 session 下；凭据被明确排除在 Session Bundle 之外；"我有哪些 Session"这个发现问题也无法从任何一个 Session 内部回答。把根上移一层，视图模型依然成立——实例级根引用各 Session 的 head，Session 仍是执行和续跑的单位。

关于 Q3（什么必须保持强一致）： head、租约和操作记录——但要加一个前提：提交必须携带事实而不是载荷。在一个真实的本地安装上，我观察到每条 model_call 事件约 47KB、每步 provider 请求快照约 900KB。如果有序提交管道串行化这种体积的载荷，一个缓慢或卡住的提交会挡住后面所有提交。事实属于有序日志；载荷属于按 digest 引用的不可变内容寻址对象——Session Root 的草图对 Artifact 和 Memory 已经是这么做的。

关于顺序的作用范围（与 Q4 相关）： 顺序只在可能冲突的写之间需要，而写只在同一个 Session 内冲突。跨所有 Session 的全局单一顺序会让互不相关的 Session 互相排队——在多个本地 Session 并发时这是可观察的，不是理论问题。把顺序限定在每个 Session 的账本上，也与 #4662 已经实现的方案一致：它的提交 CAS 以 {sessionId, expectedRevision} 为键。跨 Session 的事实（花名册、Memory head）是低频的，可以放在一条小的实例级账本上；罕见的跨账本操作可以用操作身份关联，而不需要全局原子性。

关于租约： 本机发生过两个进程 resume 同一个 Session，随后争抢 SQLite 锁并重复调用 provider。所以 head/lease 权威不只是云端问题——local-first 同样需要 fencing，否则"同步文件"会悄悄退化成 last-writer-wins。

关于 Q7（local 和 cloud 共用一套契约）： 可以，前提是把本地 SQLite 降级为已提交历史的可重建物化。这样本地模式只是同一对端口（不可变 blob + head CAS）上的文件后端适配器，读延迟不变，因为查询仍然打在本地投影上。

相关：#4662（按 Session 的 head CAS），以及这份探讨实例级根与单写者 fencing 的可漫游 Agent Home RFC 草稿：https://gist.github.com/M4n5ter/bdbc27f190c1461c74f50db95c73e07e