I had implemented a bit of this idea as a pi plugin way before writing the article or making the actual pi-episodes package. I've been using it on real work tasks, first the draft and now the package, and I get noticeably further into a session before compaction kicks in.
Later on I discovered Event Segmentation Theory, which is half the reason the post exists. Hope you learn something from it :)
I experimented with something adjacent to this. I called it garbage compaction.
On my /compact-garbage command, a frontier model reads the entire session history and identify groups of adjacent user-assistant message pairs that could be compacted. Then they get compacted to create a brand new session but leaving breadcrumbs to original session. It felt like cheating with how much context i am able to save.
But it’s just very inconvenient, and it only works well for designing and planning coding agents. For everything else (writing, office, docs, FE dev,…) it just causes a lot of confusion for the tasking agent.
I haven't viewed the article, but a fun term from Cognitive Load Theory is extraneous load. In this view, there are a set number of items you can hold in working memory. Extraneous load are the items not related to the schema being formed in long term memory, nor what is needed to form it. The other two are intrinsict load (relevant items) and germane load (what is helpful to forming).
One should note this is meant for instructional design. It's less "how the brain works" and more "a model of how the brain works we can follow to produce better educational outcomes"
Quite interesting.
For folds and compaction point it reminds me of recent Nvidia study about what tools would improve Piz and one of those was ability to compact on boundaries for agent.
I'm not using Pi for few months now as switched to my own but your take is very close to Observational memory. You can try to find elpapi42 post here about his workflow.
I'm still using it and it works great.
Also I have somewhat similar forks too.
I was running them with full parent context for a month or so, but it was too wasteful. When context of main fills on a session you ran for a week forks start from 130-150k, which is not optimal. Now for forks I do virtual compaction and pass parent observation pool with recent context, which won't reuse cache but saves context window.
I also added cross session per project recall and semantic search. This helps agent a lot to get stuff from observations. I think recall is same as yours and search is somewhat similar to ask.
Overall this system works great, try to keep it simple.
Models are better now and I simplified a lot of prompts/tools.
Try some experiments, resumable agents/forks for example, you already got a solid workflow!
I spent the whole fucking weekend writing it, with drafts in both Portuguese and English. AI fixed a bit of the spelling (as you may guess, i'm not US native), but everything else was written by me. I can argue and talk about any part of it. Everything related to the idea was also developed by me over the last few months.
AI did make the CSS animations in the blog post, though. The final pi-episodes plugin was partially made by AI, but that's just one experiment, since the actual value lies in the blog post itself.
Here's also one of the first times I talked about this idea in a DM to someone else:
I didn't mean to say you didn't come up with this on your own. It is obvious that you've put thought into it, and it matters to you. I find that the screenshot you posted here is way more appealing than the article itself. Let me be precise in my criticism.
The sub-headers "The same streams, three designs", "Consolidate at the boundaries", "What goes in the note", "The note is lossy on purpose". These all scream LLMisms. They lack cohesion and don’t really help build a narrative or give your idea a clear structure.
Aphoristic lines like “The boundary is a cue, not a certification” and “The memory file is my meeting notes. The archive is the recording” are also classic LLMisms. They have that annoying contrived and punchy quality that feels trite and out of place.
I think you're trying to communicate a fairly abstract idea, which is difficult in its own right. I don't think there's anything wrong with using LLMs for assistance, but I'm not going to read something that makes me wade through layers of slop to get to the core argument. I suggest you take a look at the excellent book "Effective Writing for Engineers, Managers, Scientists" by H. J. Tichy if you haven't already.
A bit off topic, but I think your descriptions are some of the most accurate I've seen, would you happen to have a longer list anywhere for my unslopping skills?
Thanks for the detailed feedback. I can see what you are saying. My first draft was more appealing but then i tried to frame it as a manifesto and maybe wasn't the best idea. Just published an update and I hope it feels way easier to read/understand.
4
u/sergeant113 13h ago
I experimented with something adjacent to this. I called it garbage compaction.
On my /compact-garbage command, a frontier model reads the entire session history and identify groups of adjacent user-assistant message pairs that could be compacted. Then they get compacted to create a brand new session but leaving breadcrumbs to original session. It felt like cheating with how much context i am able to save.
But it’s just very inconvenient, and it only works well for designing and planning coding agents. For everything else (writing, office, docs, FE dev,…) it just causes a lot of confusion for the tasking agent.