I've settled on writing these bespoke per project/client, typically as a harness plugin in its own repo. Not infrequently that maps 1:1 with a single target repo. There's something to be said for having the tools and memories you need and _not_ having those you don't, and it simplifies the full mental model not to have to handle moving from machine to machine and keeping all that in sync.
Go-to stack for this in my case is to start off with a MEMORY.md, and then keep a long-running agent session going to observe human-operated tmux sessions, surface/respond to occurrences where there's something significant learned (typically the human operator redirecting away from an agent/LLM decision), then start having it integrate into and read out of DuckDB. The latter becomes dense, easily searchable data for agent skills and commands and, yes, memory and such.
Comments
I've settled on writing these bespoke per project/client, typically as a harness plugin in its own repo. Not infrequently that maps 1:1 with a single target repo. There's something to be said for having the tools and memories you need and _not_ having those you don't, and it simplifies the full mental model not to have to handle moving from machine to machine and keeping all that in sync.
Go-to stack for this in my case is to start off with a MEMORY.md, and then keep a long-running agent session going to observe human-operated tmux sessions, surface/respond to occurrences where there's something significant learned (typically the human operator redirecting away from an agent/LLM decision), then start having it integrate into and read out of DuckDB. The latter becomes dense, easily searchable data for agent skills and commands and, yes, memory and such.