Agent = model + harness. Everyone benchmarks the first half. Here is the anatomy of the second half, drawn from an open-source system over 3,700 developers starred.
Good practical article on the super power you get with a harness!
I still struggle with managed memory (MEMORY.md). I haven’t found a proper way to define , promote, and reject memory instructions. One of my student used it as a book 😂 any advice welcome!
I’m investing more those days on weekly feedback loops. What works best for me and my students: a light skill that captures on the moment a drift observation (voice, workflow, fact, etc) and when we run our week close workflow, we get asked to review the observations and make a call (or not) with AI help. That’s light and efficient.
Btw - I just installed your Obsidian plugin and testing it this month. Will keep you posted.
The book problem comes from keeping everything in one file. Split it. One fact per file, and a short list at the top that holds just a one-line summary of each. The list is what loads every time. The full note only gets read when its one-liner matches what you're doing. Mine is 35 notes and the list is 35 lines.
What stopped mine from growing: write something down only if it's not obvious and it changes what the model does next time. If the code or the git history already says it, don't save it. That's a lookup, not a memory.
For rejecting: assume every note goes stale. Anything with a file name, a flag or a number gets checked before you act on it, and deleted when it's wrong. A wrong note is worse than no note, because the model believes it.
Your weekly review is the same thing, just done once a week instead of daily. That works. I'd only add a delete pass. Most people keep adding and never remove.
And thanks for installing the plugin. Tell me how it goes!
I actually already moved to index knowledge files, it's just that I initially taught with MEMORY.md in each workspace (project) and I am reaching the conclusion that it should be avoided similar to the black box memory of LLMs that is a curse IMHO because you don't control its behavior and it's hard to fix (had a few instances where I moved a skill to a prompt execution and it kept in memory the trigger words even though the skills were removed...).
I'd split those two. Black box memory is a curse because you can't see it. File memory has the same failure mode, stale entries, but you can open it, search it, delete the bad line. That's the whole difference.
Your trigger-word ghost actually proves the point. If the words survived after you removed the skill, they were living somewhere you didn't control, another file, an old session, cached context. A file can't haunt you after you delete it. Something else was holding that state.
So my conclusion isn't avoid MEMORY.md. It's never keep memory you can't read and diff. One index, one fact per file, a delete pass. The moment memory becomes something you can't inspect, it stops being yours.
Good practical article on the super power you get with a harness!
I still struggle with managed memory (MEMORY.md). I haven’t found a proper way to define , promote, and reject memory instructions. One of my student used it as a book 😂 any advice welcome!
I’m investing more those days on weekly feedback loops. What works best for me and my students: a light skill that captures on the moment a drift observation (voice, workflow, fact, etc) and when we run our week close workflow, we get asked to review the observations and make a call (or not) with AI help. That’s light and efficient.
Btw - I just installed your Obsidian plugin and testing it this month. Will keep you posted.
Thanks Fabrice, glad it helped.
The book problem comes from keeping everything in one file. Split it. One fact per file, and a short list at the top that holds just a one-line summary of each. The list is what loads every time. The full note only gets read when its one-liner matches what you're doing. Mine is 35 notes and the list is 35 lines.
What stopped mine from growing: write something down only if it's not obvious and it changes what the model does next time. If the code or the git history already says it, don't save it. That's a lookup, not a memory.
For rejecting: assume every note goes stale. Anything with a file name, a flag or a number gets checked before you act on it, and deleted when it's wrong. A wrong note is worse than no note, because the model believes it.
Your weekly review is the same thing, just done once a week instead of daily. That works. I'd only add a delete pass. Most people keep adding and never remove.
And thanks for installing the plugin. Tell me how it goes!
Great advice, thanks!
I actually already moved to index knowledge files, it's just that I initially taught with MEMORY.md in each workspace (project) and I am reaching the conclusion that it should be avoided similar to the black box memory of LLMs that is a curse IMHO because you don't control its behavior and it's hard to fix (had a few instances where I moved a skill to a prompt execution and it kept in memory the trigger words even though the skills were removed...).
I'd split those two. Black box memory is a curse because you can't see it. File memory has the same failure mode, stale entries, but you can open it, search it, delete the bad line. That's the whole difference.
Your trigger-word ghost actually proves the point. If the words survived after you removed the skill, they were living somewhere you didn't control, another file, an old session, cached context. A file can't haunt you after you delete it. Something else was holding that state.
So my conclusion isn't avoid MEMORY.md. It's never keep memory you can't read and diff. One index, one fact per file, a delete pass. The moment memory becomes something you can't inspect, it stops being yours.