LayerFS × Maka: Recursive File States for Multi-Agent Collaboration and MCTS RSI #4881
yifanxuaaa
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi Maka community,
I'm building LayerFS, an open-source recursive filesystem for agents. Your article, “From Copy-on-Write to Mailbox: Two Paths for Multi-Agent Scheduling”, resonated with how we think about execution boundaries and state.
The article asks what a subagent should inherit, how work should be scheduled, and how results should be delivered. It also describes an execution graph that evolves as intermediate results arrive. We would like to explore the filesystem counterpart: what if each execution result could reference a retained file state that subsequent work can read, continue, or recursively branch?
Maka already supports parallel work and an evolving DAG. Our proposed contribution is a branchable file-state layer underneath that execution topology.
1. 🧱 The mental model: LayerStack → Branch → Commit → Workspace
Start with a project at a known filesystem state. Agents can work independently from that point, preserve their results, and explore alternative continuations. Selected work becomes the next shared checkpoint.
LayerFS gives each part of that process an explicit place:
Workspaces under the same Branch represent successive executions. The illustration's upper-right outward “Add” arrow should read Fork/Create; Add publishes a selected Branch head back into the LayerStack.
Publishing a selected Branch head with Add creates the next shared Layer.
Independent executors use identified snapshots, immutable objects carry shared content, and conditional head updates establish an explicit publication boundary.
2. 🛠️ Why Workspace per tool call
We want each filesystem-affecting tool call to have a known input state, an isolated writable view, and an explicit result.
A subagent task contains many decisions. Suppose it edits an interface, builds the project, revises a caller, and runs tests. After the first edit, an alternative might be worth exploring: keep the interface change but try a different caller implementation. Tool-call checkpoints preserve that exact starting point without requiring the whole subtask to be repeated.
This gives the runtime three useful capabilities:
Private changes remain in their Workspace's execution view until the runtime decides how to retain or integrate them. An asynchronous command keeps its Workspace through its actual execution lifetime, including polling; calls without retained file changes can share the same state identity.
Branches accumulate intermediate work; LayerStacks publish deliberate shared checkpoints. Tool-call isolation coexists with longer-lived task and collaboration histories.
↩️ Reversibility as an executable filesystem capability
The DeepSeek-affiliated Cordis paper, A Programming Paradigm for Spatiotemporal Composability, gives a formal account of revertible effects. Its guarantees are scoped to a model whose effects have suitable inverses: section 6.1 places state outside the recovery boundary when the system cannot exclusively control and restore it. Section 6.7 identifies COW or immutable storage as an infrastructure direction for recovering earlier state. System boundary · Storage co-design
A formal recovery guarantee does not, by itself, make arbitrary Agent tool execution reversible. The filesystem still needs to preserve the earlier bytes and structure, contain new writes, and provide an actual way to resume from the retained state. That engineering obligation is the part LayerFS is building:
For these managed file changes, recovery does not require an inverse command for every edit, overwrite, or generated file. The earlier state remains available, and execution can resume from it. COW and deduplication make preserving those recovery points economical.
Our claim is scoped to file state managed by LayerFS. Process memory, network requests, and external effects require their own mechanisms. We want reversibility at this boundary to be exercised and checked through real tool executions and state recovery, rather than inferred from a harness's formal model.
3. ♻️ Making fine-grained state economical
Tool-call checkpoints, parallel candidates, and recursive branching all increase the number of retained states. Yet most of those states still contain the same project. Dozens of agents may use a large codebase while each changes only a few lines.
We want new states to reuse existing content and structure, concentrating storage growth in unique changes and their metadata. Deduplication supports growth in three dimensions:
Four mechanisms make that sharing possible:
Zero-copy fork — reuse the starting state
A new Branch references the immutable root of an existing Layer or eligible Commit. It receives an independent identity and head while retaining shared starting contents. Creating the Branch copies no canonical content objects.
Structural COW — reuse unchanged structure
Copy-on-write preserves earlier states while new states reuse unchanged file and directory structure. Retaining an edit rebuilds affected structure and shares unaffected regions and subtrees. One path can modify a file while another continues to read its earlier version.
CAS — share identical content
Content-addressed storage identifies canonical objects by their contents. Identical objects can be shared across files, Branches, and LayerStacks within one Store, including identical results produced independently. Execution identities remain distinct even when their contents can be deduplicated.
CDC — reuse regions inside edited files
Content-defined chunking establishes boundaries from file content. Local insertions, deletions, and replacements can therefore reuse unchanged regions within a changed file. CDC exposes reusable regions; CAS identifies and shares their objects. The amount of reuse depends on the edit and chunking rules.
Together, these mechanisms cover branching, mutation, and retention: reference an existing state, execute independently, preserve the changed content and structure, and make the resulting state available for another continuation.
Our ambition is COW wherever execution branches in the task tree—between tool calls, between agents, and across exploration levels. Zero-copy applies to the state fork; executable projections, I/O, and metadata still contribute to end-to-end cost.
4. 🔍 How this differs from a Git-backed workflow
Git already provides content-addressed snapshots, cheap branch references, worktrees, and packfile delta compression. It can also be orchestrated to checkpoint every tool call. Its object model, packfile storage, and worktree model are useful shared foundations.
LayerFS centers the lifecycle of an execution and the file states it produces:
We believe this combination fits frequent local edits and repeated branching from intermediate results particularly well. The performance hypothesis should be tested across equivalent complete workloads, including workspace preparation, execution, capture, retention, and cleanup.
Git can remain the project's review and delivery history while LayerFS records the execution paths that produced the selected change.
5. 🌳 Two applications of a recursive filesystem
👥 Multi-agent coding: coordinate independent contributions
Agents work from explicit baselines in independent Branches and Workspaces. Each contribution retains its origin and resulting state, giving reconciliation a base, incoming result, and current state to compare.
The responsibilities stay explicit:
Overlapping writes and changed dependencies can lead to explicit resolution or another execution. A larger task can recursively delegate subproblems using the same state model.
This is a natural connection to Maka: its execution records could identify which task and tool call produced a file state, while its coordinator manages the work that consumes or integrates that result.
🧪 MCTS for multi-lane RSI: evaluate alternative continuations
A search process can fork several candidates from an intermediate state, execute and evaluate them independently, and expand promising results into another generation. File-state recovery makes each retained node a reusable starting point, so a failed continuation can be abandoned while sibling paths remain available.
A self-improvement loop may run for many iterations along one active trajectory. A multi-lane approach also retains alternatives, enabling different continuations from useful historical states. MCTS provides one way to balance exploration and exploitation across those candidates.
RSI candidates can change an Agent's tools, code, or strategy configuration. The runtime, searcher, and evaluator supply conversation context, execution configuration, and feedback; LayerFS supplies the associated file states and views.
We call this a Recursive File System because state, execution, and branching can be composed repeatedly. RFS before RSI expresses our belief that self-improvement benefits from a file environment that supports both depth and breadth. Collaboration integrates contributions; search selects and expands candidates. Both depend on isolated execution and reusable state.
6. 🗺️ LayerFS roadmap and opportunities with Maka
LayerFS is our open-source contribution to AgentFS. We have a working core and are now concentrating on performance, workload coverage, and the next stage of multi-agent state coordination.
📅 Current optimization deadline: September 30, 2026
Our target is to complete the current performance and storage optimization pass by September 30, 2026, focusing on:
Roadmap
The September deadline applies to the current optimization pass; the later roadmap stages describe the direction of development. LayerFS remains a developer preview with one local Store authority, and crash- or power-loss durability is not currently guaranteed.
🤝 Where we see opportunities with Maka
Maka's
SubagentWorktreeExecutorseparates workspace provisioning, patch capture, recovery, and retirement. We see opportunities to connect this execution boundary with LayerFS's isolated Workspaces, Branch histories, and shared LayerStack checkpoints.Maka's scheduling and execution records and LayerFS's file-state model could complement each other. We would welcome a discussion of where these directions align as both projects develop.
Prepared with Codex and published at @yifanxuaaa’s request.
All reactions