This week I moved from a shared Claude login to my own account. Same company, new email. Here’s why I bothered.
On July 7th, Claude changed something in the desktop app that sounds small and isn’t: Cowork sessions that used to be effectively private (stored locally, separate on each machine) started syncing across everyone on the same login. Four of us shared that clientservices@ account, and across our different laptops we suddenly started seeing each other’s sessions. Nothing leaked. The product just quietly redefined what a “shared account” means.
Here’s the uncomfortable part: any privacy you got from sharing a login was never real. It was a side effect of how the software happened to store things, and it vanished the second the platform centralized sessions at the account level. The account is the only privacy boundary that has ever existed here. So I stopped borrowing time and got my own.
And I have a specific reason to care. I’m the CEO, but on any given day I’m also the CFO, the COO, the CMO, and the CRO. That means I’m the one working with payroll, financials, pipeline, and a whole lot of data that’s genuinely sensitive. It’s not that I keep secrets from my team. I don’t. It’s that some of this is high-risk enough that the accountability for it needs to sit with one person, me, for now, instead of getting quietly spread across everyone who happens to share a login. A shared account made that accountability fuzzy. My own account makes it clear.
And then the next thing: there’s no “move my stuff” button. Anthropic doesn’t migrate data between accounts, and the stuff that actually makes an account useful day to day (scheduled tasks, dashboards, custom skills, connectors, folder access, projects) doesn’t export and re-import. Lose track of it and it’s just… gone. The risk was never the move. It was silently losing the hundred small things I’d built up over a year and not noticing until the morning I needed one of them.
If you know me, you know I’m stringent about process, not for its own sake, but because getting the process right is the fastest way to scale before you even touch the software. So I didn’t wing it. I planned it. And I planned it for two very different users: me, and Claude.
Two plans, not one
From the start, I went in thinking about what Claude would need, and I treated Claude like an end user. Because that’s what it is. Agentic AI is still software, but when it’s doing the work, it’s the end user, and you plan for it the way you’d plan for any end user: what does it need to execute without me hovering over it?
A human and an AI need different things from the same migration. So I wrote both:
- A human plan: the narrative. Why we’re moving, what the tradeoffs are, which decisions only I can make. Something a person reads once and understands the shape of the work.
- A Claude-specific brief: written directly to Claude, in second person, assuming zero memory of the conversation that created it. Exact backup file names. Recreate this dashboard by this exact ID. Reinstall these named skills. Rebuild these scheduled tasks with these exact cadences. And, critically, clear flags on the handful of steps that need a human: the OAuth clicks, the judgment calls, the “which of these 28 old projects do I actually still use.”
When we ran it today, that separation was the whole game. Claude did the machine work: republishing nine dashboards, reinstalling 22 skills and plugins, rebuilding 11 scheduled tasks. I did the human work: clicking through connectors, deleting stale files, deciding what to keep. Neither of us guessed at the other one’s job.
Verify, don’t guess
The other lesson is going on my wall. Every single mistake we caught came from the same place: writing down what we assumed instead of checking what was true.
- A tool reported 2 scheduled tasks. I actually had 16. The rest were built in the app, where the API couldn’t see them.
- A tidy “list of my skills” pulled from names and descriptions turned out to include a plugin authored by Chris, not me.
- A connector I’d have sworn was a standard one-click setup was actually a custom configuration.
- Two folders that looked like two separate steps? One was nested inside the other. Half a step, gone.
Inferences get you about 80% of the way. The other 20% is exactly the part that bites you mid-move. So every time I said “that number looks wrong,” the right answer wasn’t to edit the doc to match me. It was to go look at the live source. My correction was a signal to re-verify, not the new truth.
Where the 5P Framework by Trust Insights™ comes in
This is the 5P Framework by Trust Insights™ in real life, not on a slide.
Purpose: migrate to a new instance, and trade an accidental privacy boundary for a real one. People: me and Claude. Agentic AI is still software, but it’s often the end user, so I treated it like one and planned for what it would need. Process: everything we built in the planning, before touching a single setting. Platform: Claude desktop, and everything we migrated onto it. Performance: an efficient migration, no hiccups.
And I mean no hiccups. One of the rebuilt scheduled tasks fired on its own this morning, clean and on schedule, before I’d even sat down. That’s Performance you can see, not hope for. Period.
The takeaway
If you’re handing a big job to an AI (a migration, an audit, a rebuild), don’t just give it your plan. Give it its plan, and keep yours. Decide who does what before anyone starts. And when something looks off, go check the source instead of arguing with the person telling you.
People first, process second, technology third. Even when the technology is doing half the work.