I deleted eleven assistants I had built for myself, and the next morning nothing was missing. That is the part I keep thinking about, not the deleting. If you are new here, that team was eleven named assistants, each one a text file describing a colleague with a job and a personality, a researcher named LEVI, a strategist named VERA, a devil's advocate named THEO, all of them played by the same AI model. In June I had predicted that the names were scaffolding and that the layer underneath would outlive them. Six weeks later I tested it: one evening, I moved eleven personas into an archive folder, where they still sit today.

The Measurement Came First

I want to be precise about one thing: I did not delete it on a feeling, even though the feeling had been there since June. And the measuring, to be equally precise, was not me either. Before rebuilding anything, I asked the assistant to survey what was actually sitting in that system, so the new setup's first job was taking inventory of its predecessor. The numbers came back like a lab report.

Eleven of thirteen role files had not been touched since March. Every persona had its own file for lessons learned, which I had once been genuinely proud of, because a team that records what it learns sounded like the responsible way to build one. Four months later, every single one of those files still contained the placeholder text I had written on day one: empty, will be populated through use. The feedback loop I had so carefully designed for my agents had never run once, and I had not noticed, because nothing about daily use ever forced me to look.

My own behaviour told the same story. I had already admitted in the June post that I barely called the names anymore, and the timestamps said "barely" had been generous.

There is a detail in the ending I particularly enjoy. Before deleting anything, I had the plan attacked from several independent angles, and each reviewer started blank, with no memory of our discussions and no idea what I wanted to hear. That used to be THEO's job, the agent whose entire personality I had written around a single task: telling me why I am wrong. The job got done, more thoroughly than THEO ever managed, and nobody named THEO was involved: the method that replaced the team made the case against it. The verdict was not close.

What the System Is Now, Roughly

What survived took a different shape than a smaller team, and on my setup that comes down to six parts.

One assistant. Every chat used to start with a routing decision: who do I ask, do I let the chief of staff delegate, is this a LEVI thing or a VERA thing. That decision simply does not exist anymore. I describe what I am trying to do, and the system works out for itself what the work needs and when to split into parallel strands. The overhead the old design added at the start of every single chat is gone.

An index that is always in view. The filing cabinet from the June post is still the core of everything. One index file per knowledge area, one line per file saying what it covers and when it is relevant, and that index is the only part the assistant reads at the start of every single chat, while everything else stays on disk until a task actually needs it. An index line is deliberately boring. Four parts: the file's name, one sentence of content, the keywords, a status. For the note about my home network storage, it looks like this:

backup-setup.md | NAS backup: what runs, what's verified, open gaps | keywords: backup, restore, NAS | active

The keywords matter more than they look: they are the words I would actually use when asking about the topic, so the right file gets pulled even when I phrase things differently than the day I wrote it. The part I would defend hardest is the cap. The index has a hard line limit, and when it is full, a new entry has to earn its place from an old one. That one constraint has done more for the quality of what my system knows than any instruction I ever wrote.

Owner files with dated rules. Every topic has exactly one file that owns it, and a learning gets written into that file as a dated rule on the day it happens. Mine are rarely flattering. In July I deleted a folder with the same command I had just used to inspect it, and got everything back by luck rather than by design. That evening, this line landed in the file that owns how I handle files:

- 2026-07-07: Never inspect and delete in the same command;
  the recovery was luck, not a concept. (source: session 07.07.)

When a fact changes, the old line gets rewritten in place rather than a new line stacked on top of it. The stacked version would read "backups run nightly" followed three months later by "backups actually stopped in May", and a model reading both lines treats them as equally true, while the rewritten version has one line, one date, one truth. That's exactly how outdated knowledge slips in unnoticed. I wrote a whole post about this exact mistake and then kept making it for another month anyway.

Originals never die. Raw material gets distilled into the owner files, and the original moves into an archive sorted by month. The distillate is for the assistant, the original is for the day the distillate is not enough. I used to believe that once something was properly distilled, the source could go. It took exactly one "wait, what did that actually say?" moment to retire that belief permanently.

The system remembers to remember. Here comes the honest confession underneath all of this: I value saving what I learn, and I still almost never think about doing it at the end of a chat, because by then I am already somewhere else. So now a small automatic trigger logs every chat, and the next one starts by asking whether the previous ones got captured. The one discipline I reliably fail at is no longer mine to perform, and I suspect that single change is worth more than the other five parts combined.

The team survived as verbs. Thirteen role files became thirteen playbooks, reusable step-by-step procedures, same count with different grammar. When a plan needs tearing apart, the work still fans out into independent critics, more of them than I ever had personas, each one starting blank so none of them inherits my bias, and they argue with each other before I see a synthesis. They just do not have names, desks, or personalities that I maintain on weekends. The devil's advocate is a procedure now, and I can run ten of him at once, none of them needing a backstory.

There is also a quieter seventh part. Knowledge is sorted by how long it lives: methods compound for years, project state expires with the project, and the two live in separate stores, so when something reaches the end of its life, archiving it is a move rather than surgery.

If you would rather copy the pattern than read the tour, the part that covers memory is documented as a field guide in my memory-metabolism project.

The Four Questions

The acceptance test for all of this I borrowed from Felix Schlenther's writing on AI operating systems. Four questions decide whether you have a system or just a pile of tools: Where do all steps read and write one shared memory? Is each step's output the next step's input format? Where exactly does the human sit? And does a mistake become a rule that changes an earlier step?

My old team failed the fourth question for four months straight, and that is really the whole story. Eleven empty files for lessons learned are not a feedback loop. A dated rule that lands in the owning file the moment I get corrected: that is one.

The Numbers

  • Personas deleted: 11. Kept: 0.
  • Role files then, playbooks now: 13 and 13. Same number, but they're verbs.
  • Files for lessons learned that ever received one: 0 of 11.
  • Index cap: 200 lines per store, hard. A full index is a deadline to sort things out, not a storage problem.
  • Chats I forgot to capture since the trigger exists: no idea, and that's the point: the log knows.

What I'd Ask Your System

I would not ask whether it has agents, but whether it has the plumbing. Does your setup have one memory that all steps share, or five tools with five separate truths? When something goes wrong, does a rule change somewhere upstream, or is the same mistake quietly waiting for you next month? And who remembers to capture what you learned today, you or the system?

For most of this year, my honest answers to those three questions were worse than I thought they were, and I only found out when I finally had someone take inventory. The models will keep changing, and I suspect some part of what I just built is already on its way to becoming the next thing I tear down. That is fine. This time I would notice in weeks, not months.