I agree with the take not to bother with a sophisticated memory system. Anything worth remembering should be in docs, guides, source comments, commit messages or tickets. You don't need another layer, every conceivable granularity is already covered by existing best practices

▲

sdesol 6 hours ago | parent | next [-]

> You don't need another layer

I do think we need another layer, but it should be a routing layer. I am finalizing my pi-brains extension for Pi (https://github.com/earendil-works/pi) which does this:

https://github.com/gitsense/pi-brains

Right now "humans" need to define the routing rules for how to access information, but I will support what I call "knowledge agents" that can monitor conversations to inject context when needed.

▲

prakharjain 5 hours ago | parent [-]

It looks like an interesting experiment. But a hard problem since it needs to store useful information and be able to inject it at the right time. It will also need to not be redundant to the information already stored.

What do you think is the potential value that you might get out of this, which is not already available with the existing options?

	▲	sdesol 5 hours ago \| parent [-]
		This is a hard problem, but one worth solving, I think, since it means less tokens and better AI reasoning. I believe LLMs are good enough that, if given the right context, it can very much solve almost all tasks. If this works, it means we can probably get by with smaller models (since it doesn't need to know everything). LLMs are pattern matchers, and if you can provide them with the right shape (context), they should produce the expected output. For my solution to work, you need business buy-in, which I don't think will be a problem. Enterprise wants to know how tokens are being spent, so I can see them wanting structured analysis during code reviews. What may also not be obvious is that the information is ultimately designed to live with your code. Lessons and notes are designed to be mapped to files, so if you want to know why a piece of code is implemented in a certain way, you can have the LLM filter by files to help find the needle in the haystack. It is a hard problem, but the only missing piece is discipline, which I believe business leaders will not have an issue with enforcing since we are ultimately talking about eliminating/significantly reducing the bus factor in our code. If you look at https://github.com/gitsense/smart-ripgrep, you can get a better sense of how context can be injected when it is needed.

▲

throwup238 7 hours ago | parent | prev | next [-]

Especially a layer that is largely out of band in a project (i.e. ~/.claude/…). In any project where I’ve needed memory I just add a line to AGENTS.md telling it to use MEMORY.md to save memories or STATUS.md to track progress.

▲

andai 6 hours ago | parent [-]

I've been enjoying having a little todo file the agent updates as it goes along, because then I can keep track of progress without scrolling through aeons of "Combobulating..."

Also if context runs out you can just do "cat todo.md | agent" and you're off to the races again.

	▲	mock-possum 6 hours ago \| parent [-]
		Yep all my projects start with a PLAN.md at the root, and that acts as the ‘save file’ recording our progress over time. My session always ends with updating the plan file with what’s been done, and the next session always begins, as you suggest, with consuming the current state of the plan doc.

▲

CuriouslyC 6 hours ago | parent | prev | next [-]

There is some value to agents being able to query the history of work done, docs aren't a good place to accumulate negative evidence for example, but it can be tagged in traces so that it's efficient to look up as needed. Additionally, docs rot while traces can be tagged with commit hashes and other things that make their lifetime clearer.

	▲	sdesol 6 hours ago \| parent [-]
		The user flow I am trying to get adopted for sessions is to turn them into notes and lessons when you have finished and it should be part of the code review process. By propery categorizing lessons and notes, it should make it easy to scrub and keep up to date. I also suggest mapping lessons and notes to files when possible to make discovery and cleanup easier.

▲

re-thc 5 hours ago | parent | prev [-]

> I agree with the take not to bother with a sophisticated memory system. Anything worth remembering should be in docs, guides, source comments, commit messages or tickets. You don't need another layer

That is a sophisticated memory system though -- maybe not to you experienced humans!