TL;DR: The expensive part of AI agent lock-in is the setup you’d have to abandon: config files, skills, audited tools, login sessions, habits. The subscription was the cheap part. Here’s a reuse test for any workspace you’re evaluating, and the protocol story that decides where your agents’ work should live.
The subscription was the cheap part
When you picked your current agent, the fee was never the real price. The real price was the week you spent making it good: the instructions file you rewrote until it stopped misunderstanding you, the skill files for the tasks you repeat, the MCP servers you vetted one by one, the accounts you logged it into, the review habits your team settled into.
A recent Hacker News thread about one developer’s coding-agent setup made the point plainly: what keeps you on an agent is the accumulated workflow, the custom commands and files you’d have to rebuild from zero somewhere else. In another thread, this time about an open-source coding agent, a commenter hoped the new tools would not “grow into full agent OSes with artificial lock-in effects and big effort buy-in.” Read those two together. The lock-in people actually feel is the effort they put in, and the tools that try to manufacture it artificially are the ones getting called out.
None of that investment is waste. It’s exactly why your agent is useful. But it changes what “try this new tool” costs you. A workspace that asks you to migrate is asking you to throw away the thing that made you productive, and most builders rationally say no.
The market keeps asking you to switch anyway
Look at what most agent platforms sell: a new place to work. New agent, new queue, new memory, new export format you’ll need if you ever leave. When a big vendor launched hosted agents recently, the discussion kept circling one risk above the model and the price: locking into a framework.
The counter-trend is already here, and it came from tooling, not platforms. The Agent Client Protocol started as Zed’s answer to a question editors face constantly: must we integrate every agent by hand? Their answer was to define the socket once so any agent can plug into any client. In January, JetBrains stood up a public ACP registry, the same move that turned language servers from per-editor integrations into commodities. When an industry builds a protocol for something, it is officially admitting that the switching cost was real.
We think the same admission is coming for agent workspaces.
What reusing an agent actually looked like this month
We track the agent runtimes our users bring to CrossMind, and two decisions we made this month show both sides of the reuse question.
One runtime we evaluated speaks a standard protocol. Connecting it meant adding an entry to our registry. No migration on the user’s side: their agent keeps its identity, its subscriptions, its setup. That’s what reuse costs when the plumbing is standard.
Another agent we wanted has no public programming interface at all. There is nothing to integrate with, so support waits until that changes, however long it takes. Same team, same effort level, opposite outcome. The bottleneck was reachability: whether the agent can be adopted without abandoning it first.
That asymmetry is the whole thesis. Where protocols exist, reuse is cheap and everyone benefits. Where they don’t, even a workspace that wants to adopt your agents physically can’t, and you learn who’s serious about reuse by watching who builds for the protocols that exist today.
A reuse checklist for any workspace you’re evaluating
Before you hand a new tool your agents, four questions:
Do your logins and keys stay yours? If the workspace resells you the models you already pay for, it’s a switch wearing a reuse costume. Bring-your-own means your subscriptions and API keys keep running the work.
Does the agent’s setup travel with the agent? Your instruction files, skills, and tool configs should keep pointing at the same agent you’ve already trained. If the tool needs you to translate everything into its own format, you’re paying the migration cost it claimed to remove.
Where does memory land? If context accumulates in the vendor’s cloud, leaving means leaving your agent’s education behind. We’ve argued the opposite case in why agent memory matters more than the model’s IQ, and it should survive any single tool’s departure.
Can you still audit what it does? Connecting more agents into one place concentrates power along with convenience. Whatever workspace you choose, keep the habit of reading what each tool can actually reach. We wrote about that audit for MCP tools versus standalone agents, and it applies before you connect anything anywhere.
Where CrossMind fits
CrossMind exists because we kept meeting builders running three agents from three vendors, none of which they were willing to abandon. We’ve written before about why most one-person-company agent setups fail; the failure mode there is juggling, and juggling is what you get when nobody’s willing to migrate but nothing connects. So we built the opposite of a migration: a workspace that connects the agents you already run, keeps your keys and logins in your hands, lets them share one workspace and memory, and queues every outbound action for a human yes. When a runtime speaks a standard protocol, adding it is a registry entry, not a project.
If you’ve been putting off “getting organized” because every option seemed to demand new accounts and new setups, that instinct was correct. The tools that respect it are the ones worth trying. Start at crossmind.io.