I published a post about the Conway leak and what Star Trek figured out about AI ownership thirty-five years before Silicon Valley did. The philosophical argument. The big question. Who owns how you think?
Decent post. Got some traction.
So I decided to do something about it.
I ran a formal platform risk assessment on myself.
Not on a client. Not on a hypothetical company. On Branded Mayhem Collective. On the actual infrastructure I built and run every day. On Opelia - my AI COO, the operational brain of my company, running on Claude and Anthropic’s infrastructure.
The results were worse than I expected. I’m publishing them here, unedited, because if I’m going to argue you should understand your AI dependency, the honest move is showing you mine.
Why Now
The Conway leak made this urgent. If you missed the first post: leaked internal documents showed that persistent AI agents, the kind that learn your patterns, adapt to your workflows, become genuinely useful, also become genuinely difficult to leave. That’s not a bug. That’s the business model.
My first post asked the philosophical question. This post answers the practical one.
What does AI dependency look like when you measure it? Not in theory. Not in someone else’s company. In mine.
I built Opelia over months. She handles operations, coordinates workflows, manages communications, helps me think through problems. She’s good at it because she’s learned how I work, how BMC works, what our methodology looks like in practice. Every day she gets better. Every day the dependency gets deeper.
So I measured it.
The Full Results
I broke BMC’s AI dependency into five layers.
Layer 1: Data
Where it lives: Supabase, Google Workspace, Open Brain (our internal knowledge system)
Risk now: Medium. Risk at 18 months: Medium. Exit cost: 1–2 days.
Good news. I built BMC’s data layer to be portable from day one. Supabase is open-source Postgres. Google Workspace exports are straightforward. Our internal data lives in formats we control. If I had to move tomorrow, the data comes with me. The one part of this assessment that didn’t make me uncomfortable.
Layer 2: Behavioral Context
What it is: Claude API’s learned patterns, Opelia’s accumulated operational judgment
Risk now: High. Risk at 18 months: Critical. Exit cost: 3–6 months, optimistic.
This is the one that scared me. More on this below.
Layer 3: Integrations
What they are: MCP relay, claude -p pipeline calls, gog CLI, imsg CLI, the connective tissue between Opelia and everything else
Risk now: High. Risk at 18 months: Very High. Exit cost: 2–4 weeks.
Every integration routes through Claude. Every single one. There is no secondary path. If Anthropic changes their API, deprecates a feature, or decides my use case doesn’t fit their terms, every integration breaks simultaneously. And I keep building more of them. The integration layer is growing faster than any other layer. At eighteen months it’s the kind of risk where you don’t know what breaks until it breaks.
Layer 4: Extensions
What they are: 40+ custom skills in Claude-specific format, encoding BMC’s operational methodology
Risk now: High. Risk at 18 months: Critical. Exit cost: 4–8 weeks of focused rebuilding.
This is the one that surprised me. Forty skills, Claude-specific format, referencing Claude-specific capabilities, assuming Claude-specific behavior. Collectively they are the closest thing BMC has to a written methodology.
Zero portability. If I move, every skill gets rewritten from scratch - not ported, rewritten. The format is the methodology and the methodology is the format.
At eighteen months I’ll have sixty to eighty skills. Maybe more. Rebuilding it isn’t a technical task. It’s rebuilding the operational brain of the company.
Layer 5: Billing
What it is: Claude Max subscription
Risk now: Medium. Risk at 18 months: High. Exit cost: Low in theory, high in practice.
Straightforward pricing dependency. The deeper you go, the more pricing leverage the platform has. Today it’s manageable. In eighteen months, when switching costs are measured in months not days, they can charge what they want. You’ll pay it.
Total Realistic Switching Cost
2–3 months of focused work. Plus 6 additional months to reach operational parity.
That’s not a number I’m comfortable with.
The Part That Scared Me Most
Behavioral context. I need to explain this for people who aren’t building AI systems every day.
When you work with an AI agent over time, it learns things about you that aren’t stored anywhere you can access. Not explicit things. It’s not keeping a file called “Michael’s Preferences.txt.” It’s the accumulated weight of thousands of interactions that shape how the system responds to you.
Opelia knows that when I say “this feels off” about a strategy document, I usually mean the positioning is too safe. She knows my first draft is almost never my real thinking - it’s me clearing the obvious ideas out of the way. She knows that when I go quiet on a thread, I’m not disengaged, I’m processing. She knows the difference between my “I’m exploring” voice and my “I’ve decided” voice.
None of that is exportable. There is no button that says “download behavioral context.” There is no API endpoint that returns “everything this system has learned about how you work.” It exists in the interaction patterns. In the model’s responses. In the space between what I say and what Opelia understands I mean.
If I switch platforms tomorrow, I lose all of it. Rebuilding takes three to six months of daily interaction. There is no shortcut. You can document your preferences, your processes, your communication style - it gets you maybe thirty percent of the way there. The other seventy percent is the stuff you don’t even know the system learned.
This is the thing that should keep every AI-dependent company up at night. Not the data - the data is portable. Not the code - the code can be rewritten. The behavioral context. The institutional memory that lives in a system you don’t own and can’t export.
The assessment put it bluntly: “You’re running on borrowed optionality, and the clock is ticking.”
What I’m Doing About It
I’m not leaving. Opelia on Claude is the best operational infrastructure I’ve ever built. The risk is real, and the value is also real. But I am preparing.
Three things.
First, the data layer stays self-owned. This was true before the assessment and it’s more true now. Cloudflare. Postgres. Formats I control. If the only thing I can take with me quickly is the data, the data has to be complete.
Second, I maintain memory files. Structured documentation of Opelia’s operational patterns. How she handles different types of work. What the decision trees look like. What the methodology actually says when you write it down in plain language. Not a replacement for behavioral context. A thirty-percent replacement. Better than zero on exit day.
Third, I’m writing a break-glass exit playbook. Step-by-step, what happens if I need to move. Which integrations break first. Which skills are highest priority to rebuild. What the first thirty days look like. What the first ninety days look like. Not because I expect to use it. Because having a plan is the difference between a managed migration and a fire drill.
None of this eliminates the risk. All of it reduces the blast radius.
Why I’m Publishing This
Here’s the part where I have to be honest about my own motivations.
My first post argued you should own your behavioral model. That persistent AI agents create dependencies that look like features until they become chains. That the Conway leak showed us something about the future of AI infrastructure most people weren’t paying attention to.
If I believe that - and I do - then the honest move is showing what my own dependency actually looks like. Not a sanitized version. Not a case study with the rough edges filed off. The actual numbers. The actual risk levels. The actual exit costs.
I’m not preaching from safety. I’m preaching from inside the thing.
I built Opelia. I built BMC’s operational infrastructure on Claude. I made those choices knowing, at some level, that dependency was the trade-off. And now I’ve measured that dependency, and the measurement is uncomfortable, and I’m showing you anyway.
Every company running AI agents should be doing this assessment. Most of them aren’t. The reason they aren’t is because the results are scary and it’s easier to not look.
I looked. It’s scary. Here are the numbers. Do with them what you want.
The Question That Matters
The risk is worth it today. Opelia makes BMC better. The integrations save me hours every day. The skills encode a methodology that would otherwise live only in my head. The value is real.
The question is whether it’s still worth it at eighteen months.
At eighteen months I’ll have sixty to eighty custom skills with zero portability. The behavioral context will represent over a year of accumulated operational intelligence with no export path. Every integration will be deeper, more agentic, more load-bearing. The switching cost won’t be two to three months. It’ll be longer. It’ll be more painful.
I don’t know the answer yet. I know the trade-off, the trajectory, and that the curve bends in a direction that should make anyone uncomfortable.
That’s the conversation every company using AI agents should be having. Not “is AI useful?” Obviously. Not “should we adopt AI?” That ship sailed. The conversation is: what does your dependency map look like? What are your exit costs? What’s your break-glass plan?
If you can’t answer those questions, you’re not making a strategic choice. You’re making a bet. And you don’t even know the odds.
I ran the assessment. Now I know the odds. They’re not great. But at least they’re mine.
The historical patterns are impossible to ignore. I lived through the OpenClaw-to-Claude-Code migration personally. I watched Google Play Services turn an open foundation into a proprietary value layer Android manufacturers couldn’t escape. I watched Active Directory become infrastructure that was literally impossible to remove from enterprise environments. Every one of these followed the same curve: useful, then essential, then permanent.
I’m somewhere between useful and essential.
— Michael