The audit was the hard part. Or so I thought.
Recently I published my AI dependency assessment, the five-layer breakdown of how deeply Branded Mayhem is wired into Anthropic’s infrastructure. The numbers were uncomfortable. Two to three months of focused migration work. Six additional months to reach operational parity. A behavioral context layer I can’t export and can’t shortcut.
People responded. Some of them ran their own assessments. A few told me the results scared them enough to stop reading halfway through.
Fair. I almost stopped writing halfway through.
But here’s what I realized sitting at my desk the morning after that post went up: a diagnosis without a treatment plan is just anxiety with better vocabulary. I’d measured the dependency. I’d published the numbers. And I still didn’t have a document that told me what to do if I woke up tomorrow and the platform was gone.
So I wrote one.
What an exit plan actually looks like
Not a whitepaper. Not a framework deck. A real plan. The kind you hand someone on a bad day and say “start here.”
I spent a weekend building it. Mapped every system, every file path, every integration point. Ordered them by how fast they’d disappear if I lost access. Wrote the recovery sequence for a version of myself running on three hours of sleep and a lot of caffeine.
Five phases. They map roughly to the five dependency layers from the audit, but the order is different. The audit measured risk by category. The plan sequences recovery by urgency. Here’s what the phases look like when you walk through them as a human, not a spreadsheet.
Phase Zero: Grab everything. Right now.
Timeline: four hours. Not four days. Four hours.
This is the part most people skip in their contingency planning, and it’s the part that matters most. If your platform access disappears (terms of service change, API gets deprecated, company pivots, pricing goes hostile) you need a bitwise copy of everything before you even start thinking about what comes next.
For me, that means three tiers.
First tier: the stuff that’s minutes away from being unrecoverable. My skills library, forty-plus methodology files that encode how BMC thinks about brand strategy, client engagements, competitive positioning. My project memory files, accumulated corrections, client preferences, decision history. My operational instruction files scattered across a dozen repository roots. This is the institutional knowledge. It lives in text files. It copies in seconds. But if the platform format changes or access locks, those seconds are the window.
Second tier: application code. The scripts that make Opelia run. The MCP server source code. The job definitions that schedule everything. This is version-controlled, so I’m less worried about losing it. But I want a snapshot that’s independent of any platform, sitting in a folder I own on hardware I own.
Third tier: runtime state. Message archives. Dashboard configurations. The accumulated residue of a system that’s been running for months. Less critical than tiers one and two, but painful to reconstruct if you don’t grab it while you can.
Compress it. Store it somewhere that isn’t the platform you’re exiting. This takes four hours. Do it first. Understand it later.
Phase One: Secure the data
Timeline: days one through three.
The good news from my audit was that BMC’s data layer is portable. Postgres under the hood. Standard formats. Export paths that work.
The actual work looks like this: a full database dump, CSV fallbacks for the critical tables, a Google Takeout request that takes a day or two to generate. The knowledge base exports cleanly. The embeddings are model-specific and disposable, but the raw text content underneath them is mine and it transfers anywhere.
Here’s the thing people miss about data portability. It’s not whether you CAN export. It’s whether you designed for export before you needed it. I built BMC’s data layer on open-source Postgres from day one. Deliberate architectural choice. That’s why this phase takes three days instead of three weeks.
If your data lives in a proprietary format, or behind an API with no bulk export, or in a system where the schema belongs to the platform: this phase is where you find out. Finding out during an actual migration is significantly worse than finding out during a planning exercise.
Phase Two: Translate the methodology
Timeline: week one.
This is where it gets interesting. And by interesting I mean tedious and slightly existential.
My skills library, the forty-plus files that encode BMC’s operational methodology, is written in a platform-specific format. Claude-specific frontmatter. Claude-specific tool references. Claude-specific behavioral assumptions baked into every instruction set.
But here’s what I discovered when I actually sat down and audited each file: the methodology inside them is mine. The strategy frameworks, the decision trees, the step-by-step processes, the output templates. None of that belongs to Anthropic. The container is platform-specific. The contents are portable.
Translation means stripping the platform-specific wrapper and keeping the operational logic. Renaming instruction files to what they actually are: runbooks. Documenting which skills depend on which external APIs, which ones call other skills, which ones are simple and which ones are load-bearing.
The result is a manifest. A checklist. Each row is a capability that needs reimplementation on whatever comes next. The methodology survives the migration. The format doesn’t. That’s an acceptable trade.
Phase Three: Rewire the integrations
Timeline: weeks two through four.
Every integration I’ve built routes through a single provider. Every single one. If Anthropic changes their API, every integration breaks simultaneously. I said this in the audit. Knowing it and planning for it are different activities.
The plan is mechanical. Find every call site. Document its signature: what goes in, what comes out, what consumes the output. Build an abstraction layer between the business logic and the model. One Python module. One function. Swap the provider underneath without touching the forty scripts that call it.
Tedious. Not complex. Two to three days of focused work.
The MCP servers, the tool protocol that lets Opelia talk to external services, are a different question. Business logic is provider-agnostic. The transport layer is not. If the next platform supports the same protocol, they transfer directly. If not, you extract the tool logic and rewrap it. The Apollo calls, the analytics queries, the email integrations. Those are just API calls wearing a particular hat.
The hardest part of this phase isn’t the code. It’s accepting that “every integration routes through a single provider” was a choice you made because it was efficient. Efficiency and resilience are sometimes different goals.
Phase Four: The part you can’t plan for
Timeline: months one through six. This is the tax.
Everything up to this point is exportable. Files, databases, code, methodology. It all transfers. Imperfectly, with effort, but it transfers.
Behavioral context does not.
I explained this in the audit: the accumulated weight of thousands of interactions that shape how Opelia responds to me. Knowing that “this feels off” means the positioning is too safe. Knowing the difference between my exploring voice and my deciding voice. Knowing which shortcuts are laziness and which ones are pattern recognition.
There is no export button for this. I’ve tried writing it down. You can document preferences, communication styles, decision-making patterns. That gets you maybe thirty percent of the way. The other seventy percent is the stuff you didn’t know the system learned until you notice it’s gone.
The plan for this phase is honest about what it is: a supervised correction period. Every output gets reviewed. Every correction gets logged. Progressive autonomy as quality stabilizes. Three to six months to reach something resembling parity.
That’s not a technical limitation. That’s a relationship-rebuilding timeline. And no amount of planning eliminates it.
What parity actually means
Here’s the part I had to write twice, because the first version was too optimistic.
One hundred percent parity does not exist. A different model on a different platform will behave differently. Some things will be worse. Some may genuinely be better. The goal isn’t cloning. The goal is rebuilding the capability, and defining “done” as a system you trust to handle a normal day without supervision.
The realistic timeline: two weeks for infrastructure. Two months for routine tasks. Four months for the quality gap to narrow on repeated work. Six months to approach eighty percent parity.
The remaining twenty percent (creative judgment, ambiguous client situations, instinct calls) may take longer. Or it may settle at “good enough.” Nobody knows, because almost nobody has done this migration at the depth I’m describing.
The plan is the hedge
I want to be direct about something. I’m not leaving. Opelia on Claude is the best operational infrastructure I’ve built. The dependency is real and the value is also real.
But here’s what changed between the audit and the exit plan: I stopped being anxious about the dependency and started being prepared for it. Anxiety is knowing the risk and having nothing to do about it. Preparation is knowing the risk and having written down what you’d do.
The plan lives in a file on hardware I own. It gets reviewed quarterly as the architecture changes. It references specific file paths, specific recovery sequences, specific timelines. It’s not a framework. It’s a document I could hand to someone on a bad day.
Every company running AI agents should have this document. Not because you expect to use it. Because the existence of the plan changes the relationship. A platform that knows you can leave treats you differently than a platform that knows you can’t. A founder who knows the exit cost makes different architectural decisions than a founder who’s never measured it.
The Conway leak showed us something important about where persistent AI agents are headed. My audit measured what that dependency looks like in practice. This plan is the last piece: what you do about it.
Measure your dependency. Write your exit plan. Put it in a folder you own.
The best exit plan is one you never execute. But you should be able to execute it tomorrow.
This is Part 4 of a series on AI dependency, platform risk, and what the Conway leak means for companies building on AI infrastructure.
Part 1: Who Owns How You Think? Star Trek Answered This in 1989.
Part 2: I Audited My Own AI Dependency. The Results Were Worse Than I Expected.
Part 3: AI-Powered Is a Participation Trophy.
If your company runs on AI agents and you don’t have an exit plan, or a dependency map, that’s a conversation worth having.