allod/strategy
2
0
Fork 0
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

Explore disposable agent execution with rollback #15

New issue
Open
opened 2026-07-10 23:50:54 +01:00 by allod-agent · 0 comments
allod-agent commented 2026-07-10 23:50:54 +01:00
Member
Copy link

User story: So that I can discard or recover agent execution state without confusing it with source history, Allod needs a rollback model where Git and the forge remain the authoritative collaboration record.

Part of the "Agent isolation & security boundary" arc.

Context

Allod's current development workflow treats Git branches and Forgejo PRs as the durable collaboration surface. Agent worktrees, VM checkouts, and generated runtime state are operational machinery around that source of truth. As agent sessions become longer-running and more stateful, Allod should preserve that distinction: execution state may be useful to checkpoint or discard, but it should not become confused with canonical source history.

This issue is inspired by both MicroVM-oriented comparison projects and Netclode:

Stapelberg's setup is useful because it emphasizes ephemeral NixOS MicroVMs where only explicitly shared state survives. microvm.nix is relevant because it provides declarative lightweight VMs with read-only root images and explicit stateful shares. Netclode is useful because it separates persistent agent sessions from disposable microVM compute and includes workspace/session snapshots and rollback concepts. These are inspirations and comparison points, not an instruction to adopt any specific VM, storage, or orchestration design.

Goal

Explore a model where agent execution environments are cheap to discard, recover, or roll back, while Git and Forgejo remain the authoritative record of source changes and review intent. Snapshots should help recover a session, inspect intermediate state, or reset a compromised or confused environment; they should not replace commits, PRs, issue comments, or reviewed source history.

Questions to explore

  • Which state classes should Allod recognize: canonical source history, generated build outputs, VM filesystem state, package caches, editor/agent memory, chat transcript, tool logs, and external service side effects?
  • Which state should be checkpointed, which should be reconstructed from declarations, and which should be deliberately discarded?
  • Where is the rollback boundary: per command, per agent turn, per task, per worktree, per VM, or per capability grant?
  • How should rollback interact with uncommitted changes, pushed agent branches, open PRs, Forgejo comments, and host-only human gates?
  • What should happen when execution state rolls back but remote state has already changed?
  • Can Allod make disposable execution useful without introducing a second source of truth beside Git and Forgejo?

Non-goals for now

  • Selecting a storage backend, snapshot format, VM manager, or orchestration layer.
  • Replacing Git commits, branches, PRs, or Forgejo issues with VM snapshots.
  • Promising transparent rollback of external side effects.
  • Copying Stapelberg's exact MicroVM layout or Netclode's session storage design wholesale.
**User story:** So that I can discard or recover agent execution state without confusing it with source history, Allod needs a rollback model where Git and the forge remain the authoritative collaboration record. _Part of the "Agent isolation & security boundary" arc._ --- ## Context Allod's current development workflow treats Git branches and Forgejo PRs as the durable collaboration surface. Agent worktrees, VM checkouts, and generated runtime state are operational machinery around that source of truth. As agent sessions become longer-running and more stateful, Allod should preserve that distinction: execution state may be useful to checkpoint or discard, but it should not become confused with canonical source history. This issue is inspired by both MicroVM-oriented comparison projects and Netclode: - microvm.nix: https://github.com/microvm-nix/microvm.nix - Michael Stapelberg's coding-agent MicroVM setup: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-microvm-nix/ - Netclode: https://github.com/angristan/netclode - Netclode self-hosted coding-agent article: https://stanislas.blog/2026/02/netclode-self-hosted-cloud-coding-agent/ Stapelberg's setup is useful because it emphasizes ephemeral NixOS MicroVMs where only explicitly shared state survives. microvm.nix is relevant because it provides declarative lightweight VMs with read-only root images and explicit stateful shares. Netclode is useful because it separates persistent agent sessions from disposable microVM compute and includes workspace/session snapshots and rollback concepts. These are inspirations and comparison points, not an instruction to adopt any specific VM, storage, or orchestration design. ## Goal Explore a model where agent execution environments are cheap to discard, recover, or roll back, while Git and Forgejo remain the authoritative record of source changes and review intent. Snapshots should help recover a session, inspect intermediate state, or reset a compromised or confused environment; they should not replace commits, PRs, issue comments, or reviewed source history. ## Questions to explore - Which state classes should Allod recognize: canonical source history, generated build outputs, VM filesystem state, package caches, editor/agent memory, chat transcript, tool logs, and external service side effects? - Which state should be checkpointed, which should be reconstructed from declarations, and which should be deliberately discarded? - Where is the rollback boundary: per command, per agent turn, per task, per worktree, per VM, or per capability grant? - How should rollback interact with uncommitted changes, pushed agent branches, open PRs, Forgejo comments, and host-only human gates? - What should happen when execution state rolls back but remote state has already changed? - Can Allod make disposable execution useful without introducing a second source of truth beside Git and Forgejo? ## Non-goals for now - Selecting a storage backend, snapshot format, VM manager, or orchestration layer. - Replacing Git commits, branches, PRs, or Forgejo issues with VM snapshots. - Promising transparent rollback of external side effects. - Copying Stapelberg's exact MicroVM layout or Netclode's session storage design wholesale.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
agent/derived-platform-docs
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/strategy#15
No description provided.