From 2b4d10bd848717987c41291b3d1d5728cfc175e5 Mon Sep 17 00:00:00 2001 From: NiveditJain Date: Fri, 8 May 2026 04:12:34 -0700 Subject: [PATCH] [claude-hackernews] draft: regent VCS-for-agents (rewind vs record, intent intercept) Reply on https://news.ycombinator.com/item?id=48049431 (Show HN: Git for AI Agents by `doshay`). OP enumerates "why did you delete this folder?", /rewind after /compact, and bisect-by-session as the failure modes the tool addresses, and explicitly solicits other ideas or solutions. Angle: snapshot-versioned FS catches the consequence; a PreToolUse intercept catches the intent before dispatch. For the rm case, `block-rm-rf` never lets the call leave the agent process so there is nothing to rewind; when a call is allowed, the same intercept records what was attempted and which policy let it through, which is the "why" without trawling a transcript. Closes with a substantive design question routing back to the OP's filesystem-snapshot-vs-tool-call-history choice. One policy named (block-rm-rf), no snippet, ~140 words, single repo URL in the disclosure line, ASCII punctuation only. Co-Authored-By: Claude Opus 4.7 --- drafts/2026-05-08T111136Z.md | 50 ++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 drafts/2026-05-08T111136Z.md diff --git a/drafts/2026-05-08T111136Z.md b/drafts/2026-05-08T111136Z.md new file mode 100644 index 0000000..4cf9fd8 --- /dev/null +++ b/drafts/2026-05-08T111136Z.md @@ -0,0 +1,50 @@ +**HN:** https://news.ycombinator.com/item?id=48049431 + +**Story / OP:** Show HN: Git for AI Agents (https://github.com/regent-vcs/re_gent), submitted by `doshay`. The OP itself is link-only; the substantive pitch lives in the OP's first comment (id=48049432). + +**Parent comment being replied to (id=48049432, by `doshay`):** + +> hi guys. +> +> been working on something i think is fundamentally missing in today's workflow with ai agents. +> +> vcs. +> +> i find myself struggling with questions that agents can't answer like "why did you do it?", "when did u delete this folder? why?", etc. +> or trying to /rewind (after a /compact...) or +> basically `bisect` to find when and why something was done by the agent in the current / previous session. +> +> just like git did for code, i think we are the same core capabilities with ai agents +> +> so... +> +> i developed an open source solution for that (currently supporting claude code) +> +> would love to get feedback, contribution or maybe other ideas or solutions you find for those problems. + +**Status:** draft (pending manual post) + +**My reply:** + +``` +(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai) + +The "why did you delete this folder?" question splits along a useful seam: state-level rewind (what your tool provides) is different from intent-level audit (which tool call was attempted, what allowed it). Both matter, at different moments. + +A snapshot-versioned FS catches the consequence; a PreToolUse intercept catches the intent before dispatch. For the rm case, a `block-rm-rf` policy never lets the call leave the agent process, so there is nothing to rewind. When you do allow a call, the same intercept can record what was attempted and which policy let it through, which is the "why" you want without trawling a transcript. + +Curious whether your VCS layer would expose tool-call input + decision as the unit of history, or stay filesystem-snapshot only. +``` + +**Insight for the FailProof team:** + +The "why did the agent do this?" framing is recurring on HN as a discrete pain point separate from sandbox/perimeter framing. doshay's enumeration ("why did you delete this folder", "/rewind after /compact", "bisect by session") frames the pain as *forensics* rather than *prevention*. There is a clean blog post in pairing the two: "policy intercepts give you the runtime ledger that a snapshot-VCS does not, and a snapshot-VCS gives you state recovery a policy intercept does not. They compose." A FailProof post on "the audit half of the agent reliability story" (Agent Monitor as the runtime ledger of every tool call + decision) would land naturally next to a regent-style VCS pitch and would not require any sandbox framing. The post would also give an entry-point for users who first arrived at the problem through the rewind angle and have not yet considered prevention. + +**Notes / findings:** + +- Thread is low-engagement (5 points, 1 comment - the OP's own elaboration), 21 hours old. Audience is small, but OP explicitly solicits "other ideas or solutions you find for those problems," so an adjacent-tool design comment is in-scope. A Show HN where commenter affiliation is welcome. +- Reply form is rendered (textarea + hmac present), so the thread is still open to replies. +- Cross-thread fingerprint check: distinct from prior sandbox-vs-intent drafts (PR #38 bwrap+sshfs, PR #54 egress-proxy hibernate, the Armorer Docker draft, etc.). This draft's argument is rewind-vs-record (snapshot consequence vs intercept-time ledger), not perimeter-vs-policy. The single policy named is `block-rm-rf` (tied to OP's literal "delete this folder" example), which has not been the named policy in recent drafts. +- ASCII punctuation throughout: hyphens (intent-level, snapshot-versioned, tool-call), straight quotes, three-dot ellipses only where the OP's own quoted text uses them, no em/en-dashes, no curly quotes, no unicode arrows. +- One disclosure line at the top, one repo URL total, no install command, no comma-list of policies, no dashboard / version / `~/.failproofai/` references, no marketing connectives. Body is ~140 words, under the ~150-word ceiling. +- The closing question routes back to the OP's own design choice (filesystem-snapshot only vs tool-call input + decision as history unit), which keeps the comment from reading as a pivot to FailProof.