The Problem
I’ve spent about a year building an agent setup around my marketing work: a notes vault, a hundred or so skills, scheduled jobs, a few memory layers. Almost all of it was built while working at one company. I wanted to know, as a thought experiment, what would happen if I took the same role somewhere else. Which parts are mine and portable, and which parts would quietly carry the old company’s context into the new one?The Approach
I asked Claude for a full inventory and a plan, in plan mode so nothing could be changed. It split the question three ways and ran three read-only agents at once: one over the vault’s content, one over the skills, rules and scripts, and one over everything outside the vault, meaning memory databases, search indexes, scheduled jobs and logins. While those ran, it put three decisions to me. I picked a fresh vault with the working parts copied in, over fencing off the old material inside the same one. On confidential material it recommended deleting at departure. I chose an encrypted offline archive, with a note to read my employment agreement first. For memory, export what is portable and start empty.What Happened
One report came back saying all 102 skills mentioned my employer. The agent caught its own mistake. Every file in the vault has the same metadata block at the top, and the company’s name happens to sit inside one of the field names. So a plain search for the company matched every file. Two of the three agents fell into it independently. The corrected number was 57, and only 15 of those were truly employer-only. The bigger surprise was the third report. I had been thinking about folders. The folders turned out to be the easy part. About three quarters of the vault by size was employer material, and the portable core, the frameworks, the lessons, my voice spec, came to under 4 MB of text. What would actually follow me was the memory. One plugin held more than eleven thousand observations and injects some of them into every new session before I type anything. Another lives in the cloud and would outlast any local cleanup. Ten scheduled jobs, across two schedulers, were still writing new company material, so anything I cleaned would refill. One agent also reported a config file with a key in it was tracked in git. Claude checked that directly before repeating it. It was not. Git was tracking thirteen unrelated files. The plan that came out of it builds the new vault by copying things in on purpose, so a miss shows up as something absent. It stops the scheduled writers before anything is archived. It ends with a test: open a fresh session and ask who I report to. I read the plan and declined it. Later I realized removing the old company ended up being a much simpler approach than starting a whole new vault. That’s the next entry.What I Learned
I think of this system as my practice, and most of its weight belongs to one employer. The part that is mine is small and dense. I would check the memory layers before the folders next time, and I would distrust any search that comes back at a hundred percent as much as one that comes back at zero.Drafted by my Claude from our working session. I edited and approved it.