Very cool approach! We build something super similar, also going for content addressed storage and compare&swap as fundamental primitives.
Also commit dag based, but we also wrote this whole knowledge graph / triple-store CRDT data format on top.[1]
We also have peer2peer syncing of the history so you can use it to track your local work but also to have your agents coordinate within your team.
We had our agents build their own tools on top of that substrate, that way we're vendor independent, this stuff works everywhere from claude web, to self hosted openclaw, you only need to tell your agent to use the faculties.
Because the substrate takes care of everything, every new faculty you write on top of that inherits all of the same properties.
I think the idea of tracking intent in git commits is a great idea but it feels to me like this might be reducible to some prompts/extending git/pre-commit hooks?
Agents can use git FWIW, and you can tell them to search old sessions by saying "Search through sessions in ~/.codex/sessions" and it'll find the most appropriate tools for doing so that is installed already. You can even add this to your system prompt or AGENTS.md and now you don't even have to prompt for it, it'll just look up the session history by itself.
Why this isn't built-in, I dunno, but been possible and easy for a very long time already, and works for any agent harness out there (as long as they persist sessions that is).
Personally I make the agent justify and explain things in the git commits, where is where that info went before agents anyways too, then have some sentences in my AGENTS.md about reading recent commits before doing changes, and using it whenever I prompt for history that isn't part of the current session. Seems to work perfectly fine.
I haven't tried it, but conceptually I can imagine that it is good to have a separate VCS for the agent. This way I can keep git clean and easy to understand for humans and still keep all the verbosity the agent needs.
Branches and worktrees exist and can effectively act as a "separate" history. At the end of the day you would still merge the changes in, possibly with a squash if you don't care about the little commits.
It's really not. Anything the LLM can benefit from people can too. Keeping minimal explicit information in git history is a cultural norm not proven best practice. The best codebases I've worked on have very large commit messages and searching them is very useful. We should have been doing it that way all along.
Git is a particularly egregious one, imo. It has a simple cli and solves all of the problems presented here! Worktrees for "exploratory" work that you might throwaway, and otherwise atomic commits just make tracking changes and reasoning for changes easy.
Cool idea. Time will tell how it matures. It doesn't look trivial. Definitely should beat my current "scan the history" approach. Couple questions arose while reading the README:
- Would it integrate with rtk? Rtk is a token saver that shortens native output of got (and other) commands.
- Does it track feature branches?
- Is there garbage collection when history is rewriting (rebase before PR or removal of credential files.. ) or "simplification" of data as it gets older (Claude session logs lost...)?
Just use git. If your agent (especially claude) doesnt seem to know how, there are skills and hooks and other options to make it work. My 2c.
Exactly like I didn’t do anything super important - but I just tell agent “commit after successful build.
I think it would work with “commit before you want to delete stuff” the same way.
Very cool approach! We build something super similar, also going for content addressed storage and compare&swap as fundamental primitives.
Also commit dag based, but we also wrote this whole knowledge graph / triple-store CRDT data format on top.[1]
We also have peer2peer syncing of the history so you can use it to track your local work but also to have your agents coordinate within your team.
We had our agents build their own tools on top of that substrate, that way we're vendor independent, this stuff works everywhere from claude web, to self hosted openclaw, you only need to tell your agent to use the faculties.
Because the substrate takes care of everything, every new faculty you write on top of that inherits all of the same properties.
1: https://github.com/triblespace/triblespace-rs
2: https://github.com/triblespace/faculties
I think the idea of tracking intent in git commits is a great idea but it feels to me like this might be reducible to some prompts/extending git/pre-commit hooks?
every show hn now is now
cool but look at myproject.com
just curious since it reminds me a bit. Have you / someone tried https://entire.io/ (I'm not affiliated at all, so it is not a plug).
Cool! Have you taken a look at trying to deeply integrate into git like https://usegitai.com/ does?
Agents can use git FWIW, and you can tell them to search old sessions by saying "Search through sessions in ~/.codex/sessions" and it'll find the most appropriate tools for doing so that is installed already. You can even add this to your system prompt or AGENTS.md and now you don't even have to prompt for it, it'll just look up the session history by itself.
Why this isn't built-in, I dunno, but been possible and easy for a very long time already, and works for any agent harness out there (as long as they persist sessions that is).
Personally I make the agent justify and explain things in the git commits, where is where that info went before agents anyways too, then have some sentences in my AGENTS.md about reading recent commits before doing changes, and using it whenever I prompt for history that isn't part of the current session. Seems to work perfectly fine.
I haven't tried it, but conceptually I can imagine that it is good to have a separate VCS for the agent. This way I can keep git clean and easy to understand for humans and still keep all the verbosity the agent needs.
> This way I can keep git clean and easy to understand for humans
Personally I like it best when both humans and agents find it clean and easy to understand, but we all like different things :)
Branches and worktrees exist and can effectively act as a "separate" history. At the end of the day you would still merge the changes in, possibly with a squash if you don't care about the little commits.
It's really not. Anything the LLM can benefit from people can too. Keeping minimal explicit information in git history is a cultural norm not proven best practice. The best codebases I've worked on have very large commit messages and searching them is very useful. We should have been doing it that way all along.
I am all for extremely granular control of agents. Good work.
This is brilliant. Does it only work with Claude right now? Will it work with any agent built on the Claude Agent SDK?
That's a good idea. I think you should develop it to make it more versatile.
None of these X-for-agents seem to motivate why they don’t use X.
Git is a particularly egregious one, imo. It has a simple cli and solves all of the problems presented here! Worktrees for "exploratory" work that you might throwaway, and otherwise atomic commits just make tracking changes and reasoning for changes easy.
Cool idea. Time will tell how it matures. It doesn't look trivial. Definitely should beat my current "scan the history" approach. Couple questions arose while reading the README:
- Would it integrate with rtk? Rtk is a token saver that shortens native output of got (and other) commands. - Does it track feature branches? - Is there garbage collection when history is rewriting (rebase before PR or removal of credential files.. ) or "simplification" of data as it gets older (Claude session logs lost...)?
Wishing you all the best with the project.