The Plumbing Outlived the Org Chart

The last post about my AI team ended with a prediction I wasn't entirely comfortable making: that the named roles were scaffolding, and that the plumbing underneath would outlive the org chart. If you're new here, that team was eleven named assistants I had built for myself, 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.

Six weeks later I deleted the team. Not metaphorically, not "I'll use it less". One evening, one move, eleven personas into an archive folder where they still sit today. This post is about what was still standing the next morning, because that turned out to be the interesting part.

The Measurement Came First

I want to be precise about one thing: I didn't delete it on a feeling, even though the feeling had been there since June. And the measuring, to be equally precise, wasn't 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 hadn't been touched since March. Every persona had its own "lessons learned" file, 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'd 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 hadn't noticed, because nothing about daily use ever forced me to look.

My own behavior 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's a detail in the ending I particularly enjoy. Before deleting anything, I had the plan attacked from several independent angles, each reviewer starting 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 job: telling me why I'm wrong. The job got done, more thoroughly than THEO ever managed, and nobody named THEO was involved. The method that replaced the team is what made the case against the team. The verdict wasn't close.

What the System Is Now, Roughly

What survived is not a smaller team. It's a different shape entirely, and on my setup it comes down to six parts.

One assistant. Every session 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 doesn't exist anymore. I describe what I'm trying to do, and the system works out what the work needs, including when to split itself into parallel strands. The entrance tax of the old design, due at the start of every single conversation, is gone.

An index that's 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's relevant, and that index is the only part the assistant reads at the start of every single conversation, 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're the words I'd 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'd defend hardest is the cap: the index has a hard line limit, and when it's full, a new entry has to earn its place from an old one. That constraint has done more for the quality of what my system knows than any prompt 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. The rewritten version has one line, one date, one truth. The stacking failure is exactly how knowledge tips over quietly; I wrote a whole post about it and then kept committing 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 isn't 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 is the honest confession underneath all of this: I almost never think about saving learnings at the end of a session. Not because I doubt the value, but because by the end of a session I'm already somewhere else. So now a small automatic trigger logs every session, 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, 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 starts blank so none of them inherits my bias, and they argue with each other before I see a synthesis. They just don't have names, desks, or personalities that I maintain on weekends. The devil's advocate is a procedure now. I can run ten of him at once, and none of them needs a backstory.

There's 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, not surgery.

If you'd rather copy the pattern than read the tour, the memory-hygiene half of this is documented as a field guide in my memory-metabolism repo.

The Four Questions

The acceptance test for all of this I borrowed from Felix Schlenther's writing on AI operating systems. Four questions that 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. Ten empty lessons files are not a feedback loop. A dated rule that lands in the owning file the moment I get corrected: that's one.

The Numbers

• Personas deleted: 11. Kept: 0.
• Role files then, playbooks now: 13 and 13. Same number, but they're verbs.
• Lessons files that ever received a lesson: 0 of 10.
• Index cap: 200 lines per store, hard. A full index is a curation deadline, not a storage problem.
• Sessions I forgot to capture since the trigger exists: no idea, and that's the point. The log knows.

What I'd Ask Your System

Not 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's fine. This time I'd notice in weeks, not months.