61–70 of 72 posts
Does agent memory actually work as a concept yet? I've only seen LLMs commit garbage to memory and recall in irrelevant contexts.
You need "dreaming" phase;large context high quality llm to prune and condense the memory.
Have you thought about adding an observability layer on top of the shared memory? If multiple agents are reading and writing to the same memory, I'd love to be able to see which agent created a memory, which agents later retrieved it, and how it propagated across sessions. A timeline or knowledge graph of that could be really useful, especially for tracking down stale or conflicting memories.
[flagged]
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.
Earlier quoted context omitted.
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 wrote a cli tool to query the opencode sqlite database. it's not great, i would want to improve it more before announcing it, but: it works for me and my agents. it was easy to write/understand. https://tangled.org/jauntywunderkind.bsky.social/opencoattai...
i also am working on bookmark features too! a skill and more cli, i'll add a tool too, but often i don't even use tools, just have the cli use the shell. it shows up nicely in it's own atuin, which is rad. but the otel isn't as good.
Earlier quoted context omitted.
You need "dreaming" phase;large context high quality llm to prune and condense the memory.
But does it actually work, or is it something made up because it sounds cool.
I like this local-first concept. you have already good desktop resource.
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.
I’m currently using gbrain as provider-agnostic memory but miss how lightweight SQLite is in practice, so this is interesting!
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.