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.
I hit this in session 101 after a crash: boot hooks sweep the orphaned transcript into a [RECENT] tail, and separating settled decision records from WIP state tells the new agent what was finished vs what died mid-flight.
Good call to be thinking about this, it is highly relevant. I think I ended up creating a good solution to this potential pitfall.
Does agent memory actually work as a concept yet? I've only seen LLMs commit garbage to memory and recall in irrelevant contexts.
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
already has a full sqlite based memory store of everything. :)
But it is not in a format optimised for the task. What kind of a query would you execute, LIKE across all your sessions?
you dont need to, export the sessions and render them to markdown, a nice thing is that OpenCode already understands project locality, so use a .sessions for in you repo and get project specific memories (probably want to summarize them down, do other massaging, but a script and skill is sufficient)
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…
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…
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!
Yes! Because the Codex CLI supports the Model Context Protocol (MCP) and lifecycle hooks, it actually worksperfectly out of the box. In fact, your comment just inspired me to push a quick update a few minutes ago: if you pull the latest version, running engrim setup will now auto-detect your ~/.codex folder and completely wire up the MCP server and hooks (SessionStart, UserPromptSubmit, etc.) natively. Give it a try!
But it is not in a format optimised for the task. What kind of a query would you execute, LIKE across all your sessions?
you dont need to, export the sessions and render them to markdown, a nice thing is that OpenCode already understands project locality, so use a .sessions for in you repo and get project specific memories (probably want to summarize them down, do other massaging, but a script and skill is sufficient)
I do not follow you. Are you exporting yours sessions manually? How are you performing insertions and queries? How does your agent know the session schema? How does OpenCode 'understand' anything when it is just a dumb app? Are you using some OpenCode memory skill? Do you have a write up of your workflow?
you dont need to, export the sessions and render them to markdown, a nice thing is that OpenCode already understands project locality, so use a .sessions for in you repo and get project specific memories (probably want to summarize them down, do other massaging, but a script and skill is sufficient)
I do not follow you. Are you exporting yours sessions manually? How are you performing insertions and queries? How does your agent know the session schema? How does OpenCode 'understand' anything when it is just a dumb app? Are you using some OpenCode memory skill? Do you have a write up of your workflow?
opencode export -h
you can also work with the opencode sqlite database directly
I do not follow you. Are you exporting yours sessions manually? How are you performing insertions and queries? How does your agent know the session schema? How does OpenCode 'understand' anything when it is just a dumb app? Are you using some OpenCode memory skill? Do you have a write up of your workflow?
opencode export -h you can also work with the opencode sqlite database directly
I am not sure we are talking about the same thing. I am talking about a way to automatically create memories, for agentic use. This involves knowing when to create, amend, and delete memories. Are you handling these tasks? This is the core of agentic memory management. Your responses seem to indicate a different use case, like making backups.