Shepherd supports agent-run rollback beyond git rewind

• According to Avichawla's Shepherd walkthrough, Shepherd records a long agent run as typed commits that capture the process and filesystem, not just a chat log or a Git diff.
• Avichawla's Claude Code comparison says Shepherd can roll back Bash-side changes that file-only rewind misses: pip install, sed, echo, /tmp, dev servers, and directory moves.
• Avichawla's KV-cache reply frames cache warmth as the cost lever: snapshotting alone still repays prefill, while the Shepherd thread claims over 95% KV-cache reuse on replay.
• Avichawla's gating reply narrows the safety story: external side effects have to be flagged before they fire, because an email or payment API call cannot be magically undone.
• TigrisData's soft-delete post shows the same undo pressure showing up outside the agent runtime, with object deletes held for 7 to 90 days before reclamation.

The Shepherd repo is the main artifact in the thread; Avichawla's follow-up link points to another related resource. The screenshot attached to Avichawla's rewind comparison is the useful boundary table: Claude Code rewind tracks file content, while Bash writes, directory operations, remote files, and cross-session recovery fall outside it. timescale/tigerfs and NTM show adjacent attempts to make agent state versioned, inspectable, and recoverable.

According to Avichawla's Shepherd walkthrough, Shepherd treats each agent-environment interaction as a commit in a typed trace. The commit carries the agent process and filesystem together using copy-on-write, so a branch can resume from the live state at that point.

The thread draws three layers of recoverability:

• Message log: records model messages and tool calls, but misses memory, open file handles, child processes, installed packages, /tmp, and KV cache.
• Git: versions files, but does not restore the running process or keep the model cache warm.
• Shepherd: versions the live run, including process state and filesystem state, then forks from a previous commit.

The concrete pitch is runtime branching for agents. A bad step at turn 10 can fork back to turn eight without restarting the task from turn one.

Avichawla's Claude Code comparison makes the boundary more concrete by comparing Shepherd with Claude Code rewind.

• Agent edits a file through the Edit tool: rewind restores it, Shepherd restores it.
• Agent runs pip install in Bash: rewind misses it, Shepherd restores it.
• Agent writes with sed or echo: rewind misses it, Shepherd restores it.
• Agent starts a dev server and writes to /tmp: rewind misses it, Shepherd restores it.
• Agent creates, moves, or deletes a directory: rewind misses it, Shepherd restores it.
• Agent runs a DB migration: Shepherd reverts the files, but a real database write needs an inverse operation registered first.
• Agent sends email or hits a payment API: neither rewind nor Shepherd can undo the external side effect.

The attached Anthropic docs screenshot in the same comparison lists four rewind limits: Bash changes are not tracked, checkpoints are tied to the session that created them, only file content is covered, and remote or network files are not tracked.

Avichawla's Shepherd walkthrough claims Shepherd's copy-on-write fork is roughly five times faster than docker commit, and that replay reuses over 95% of the KV cache when the prompt prefix is unchanged.

Avichawla's KV-cache reply adds the missing cost detail: a snapshot that restores filesystem and process state can still repay the model prefill unless the KV cache stays warm.

GergelyOrosz's context note separates the infra concern from user-visible behavior: KV cache affects resource usage and latency, while context size and context compression affect what the model appears to remember.

mathemagic1an's KV-compaction post points at a neighboring direction: compressing long trajectories by training a small MLP or autoencoder to reconstruct activations that the original KV cache would produce on later tokens.

The Shepherd thread describes a meta-agent that watches the trace and calls fork, replay, or revert when the run starts going wrong. Avichawla's Shepherd walkthrough says adding that live supervisor on CooperBench raised pair-coding pass rate from 28.8% to 54.7%.

The constraint is timing. Avichawla's gating reply says gating only works if the supervisor flags the bad action in time.

That makes the supervisor more like a pre-commit hook for the live sandbox than an all-purpose undo button. Files and sandbox state can be restored after the fact; irreversible external calls have to be stopped before execution.

The database case is the sharp edge. Avichawla's rewind comparison says Shepherd can restore the files around a migration, but row-level effects need a matching inverse step registered ahead of time.

Yacine's database warning adds that queries are not zero-write operations in many real systems. That matters for agent sandboxes because a tool labeled as a read path can still mutate caches, counters, audit rows, locks, or session state.

The evidence pool has three adjacent state systems orbiting the same problem: agents need disposable compute, but the state they touch cannot always be disposable.

• timescale/tigerfs describes a PostgreSQL-backed filesystem where writes are logged, versioned, and reversible, with savepoints for atomic undo.
• NTM describes a tmux-based multi-agent control plane with checkpoints, timelines, audit logs, approvals, and destructive-command guardrails.
• TigrisData's post says object storage deletes can be held in a soft-delete state for 7 to 90 days, and the attached demo shows a deleted object being restored.
• TigrisData's partnership post says Isorun provides hardware-isolated agent compute while Tigris provides durable, forkable disks.

Shepherd sits closest to the live execution path. TigerFS, NTM, and Tigris cover surrounding storage, orchestration, and persistence layers where agent mistakes also need a history.