I hope you don't mind me asking you some ELI5 questions because I'd like to understand how this fits in with everything else.
I generally discourage my agents from storing memories locally because they don't travel; I'd much rather have a small in-repo document—whether it's an architectural decision or TODO or session log entry or runbook or environmental quirk or something else—that the prompt/CLAUDE.md/whatever can guide agents to grep and sed. Then I can dispatch work to a local agent, or a local agent running in a sandbox, or an agent running in a provider's cloud environment, or a GitHub agentic workflow running a headless harness, etc. and they all have access to it. Another benefit is that memory updates get PRs and reviews like everything else.
So what am I missing by not using something like engrim or gbrain?
Permanent docs definitely belong in git. This is just the desk scratchpad for messy session context so you can /clear freely without cluttering commit history or burning tool calls on grep. Anti Gravity has a large enough context window that seems to be less needed than Claude Code but the real value now with engrim is if you are using multiple services, your project is relevant when switching services. This was born from my long haul Claude Code development sessions and morphed into its current state from swapping around CLI services on the same projects.
Ahh, interesting. I have an issue today where my GitHub agentic workflows keep blowing through the context window that my local models can support; it ends up spending most of its runtime compacting over and over again. I've done all the usual stuff to slim down the fixed context and prevent it from slurping up too many files but it's still a recurring issue. Now I'm wondering if I can put engrim in the gh-aw container (or in the DinD sidecar it uses on ARC) and teach the headless claude harness how to use it, possibly even: "keep persistent context in engrim and use `/clear` instead of `/compact`". I'll play around with it. Thank you!
Great question, and I just updated the README to clarify this! It's a mix. If you're using connected agents (Antigravity, Claude Code, Cursor) via MCP, they have the engrim_add tool and will automatically log major architectural decisions as they make them. But you also have the manual engrim add CLI command for when you have an 'aha!' moment and want to drop a constraint into the project's brain yourself.
gbrain is an awesome project, but yeah, that was exactly the itch I was trying to scratch! I wanted something that felt as fast, portable, and bulletproof as a single .db file. Zero background daemons or cloud dependencies—just fast, hybrid queries.
It does now! Good call. I actually just pushed an update based on your comment that adds engrim uninstall to cleanly unwire the hooks, MCP servers, and skills across all environments. Thanks for keeping me honest!
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
Thanks! Exactly. We have M-series chips and massive NVMe drives sitting mostly idle while we pay a 'cloud tax' to store string data. Local SQLite is practically zero-latency, keeps your IP entirely private, and means the memory engine survives even if your internet drops.
Local is almost free no tax, but disk belong to user. we save this and prevent running out of storage.
I’m also making local-first tool, mine is for Kafka indexing, I found that cleanup and balancing storage are very important.
Does Engrim have any context eviction?
No, I am not an LLM. I do use LLMs to help draft replies as I am a busy person living in the real world. Really glad you like the provenance feature tracking which agent (or human) made which decision ended up being one of the most useful parts of the whole system for me.
Other busy people in real world are then subjected to your generated content. Why bother generating then. Just write down the same thing you prompted llm with
It all boils down to whether the product (code , documentation, whatever) is polished, easy to understand and works as advertised. Beyond that, I don't give a rats ass about whether the intelligence that created it was human or artificial
don't let them decide on memories like you shouldn't really be having them write skills or agents.md files
I use them to produce candidates, but not make the decision, there's almost always something wrong in there and in need of an editorial pass. They tend to be overly verbose too, keep em short and sweet
I've been using another memory plugin [1] for the past couple months. Since this change, I almost never run session compaction. Instead, I opt to just make a new session, give the agent a task, and have it figure out what happened in previous session(s).
Decision summaries look really cool -- though the agent/model info probably won't be useful for me because I don't actually ever let agents commit code autonomously (even in branches).
i've had long-running coding-agent jobs die. I'd like to see the 105-session benchmark include an unclean exit halfway through a task: what does the next agent know was completed versus merely planned? Recovering architectural decisions and recovering unfinished work seem like different tests.
it's just a standard sqlite file in ~/.engrim, so something like litestream or syncthing works fine. just have to make sure wal files get included if syncing live.
just pulled in engrim merge <OTHER.db> - check v1.3.1 (sorry for duplicate reply - had another that was basically same topic) Trying to reply to everyone - thank you.
72 comments
[ 0.21 ms ] story [ 82.2 ms ] threadI generally discourage my agents from storing memories locally because they don't travel; I'd much rather have a small in-repo document—whether it's an architectural decision or TODO or session log entry or runbook or environmental quirk or something else—that the prompt/CLAUDE.md/whatever can guide agents to grep and sed. Then I can dispatch work to a local agent, or a local agent running in a sandbox, or an agent running in a provider's cloud environment, or a GitHub agentic workflow running a headless harness, etc. and they all have access to it. Another benefit is that memory updates get PRs and reviews like everything else.
So what am I missing by not using something like engrim or gbrain?
Does it come with an uninstall script?
Please call me a plunger because I often hear that i was right to push back.
Congrats on the launch!
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
I especially like the provenance idea.
I use them to produce candidates, but not make the decision, there's almost always something wrong in there and in need of an editorial pass. They tend to be overly verbose too, keep em short and sweet
> Empirical Proof (The 105-Session Case Study)
Is this something you can benchmark against competitors? Lots of these memory plugins are cropping up and nobody knows how they compare.
It seems the meat of your work is in https://github.com/timgordontg/engrim/blob/main/src/engrim/m...
There is no lifecycle management or conflict resolution yet, and the models do the work of deciding when to use it.
I've been using another memory plugin [1] for the past couple months. Since this change, I almost never run session compaction. Instead, I opt to just make a new session, give the agent a task, and have it figure out what happened in previous session(s).
Decision summaries look really cool -- though the agent/model info probably won't be useful for me because I don't actually ever let agents commit code autonomously (even in branches).
- [1] https://ctx.rs/