The hidden cost of switching: when your agent's edge lives in someone else's database

When teams evaluate an AI agent platform, they compare the things that are easy to compare: the model, the editor, the price per run, the integrations. What almost nobody prices in is the cost of leaving — because on day one, there’s nothing to leave with.

That changes fast. And by the time it matters, the bill is already large.

The model isn’t the moat. The accumulated state is.

Here’s the thing that makes the switching cost sneak up on you: the model is the commodity, and the data is the value.

The base model is interchangeable. You can swap one frontier model for another in an afternoon, and a year from now you’ll have even more options. That part isn’t sticky.

What’s sticky is everything your agent has accumulated by running in production:

• Memory — what it has learned about each customer, each account, each recurring situation.
• Conversation history — the full record it draws on to stay coherent across sessions.
• Learned preferences and corrections — the feedback, overrides, and “no, do it this way” signals that shaped its behavior over months.
• Retrieval context — the embeddings and indexes that let it find the right thing at the right moment.
• Evaluation history — the test cases, traces, and labeled outcomes that tell you it actually works.

That’s the asset. That’s the difference between an agent that performs and a blank one that doesn’t. And in most platforms, every bit of it lives in the vendor’s database, in the vendor’s schema, tied to the vendor’s runtime.

What “just export it” doesn’t cover

The standard reassurance is that you can always export your data. And usually you can — you’ll get a dump of something.

But an export is not portability. Three things go wrong:

The shape is theirs, not yours. What you get back is structured for their runtime. Memory records reference their internal IDs; embeddings are tied to their indexing scheme; conversation state assumes their orchestration. Outside that system, a lot of it is semantically inert — bytes you own but can’t use.

The behavior doesn’t come with it. The corrections, the tuning, the accumulated “the agent finally handles this case right” — that lives in the interaction between their stored state and their runtime. Move the data, and you’ve moved the notes but not the performance.

The clock resets. Drop your exported data into a new platform and, even in the best case, your agent starts cold. It has to re-learn, re-index, re-earn trust. For weeks or months your agent is worse than it was — at exactly the moment you’ve decided to change vendors. Few teams can afford a quality regression on a customer-facing system, so most just stay.

That last point is the real mechanism. The lock-in isn’t a contract clause. It’s that leaving makes your agent temporarily dumber, and you know it.

Lock-in that compounds

Most switching costs are a fixed wall: painful, but the same size whenever you hit it. This one is different — it grows.

Every week your agent runs, it accumulates more memory, more learned behavior, more context that makes it good. Which means every week, the gap between “what we’d lose by leaving” and “what we’d start with somewhere else” gets wider.

So the cheapest time to leave is always the day you arrive, when there’s nothing to lose — and you’d never leave then, because the agent isn’t proven yet. By the time it’s proven, leaving is expensive. By design or not, that’s a moat built out of your own data, and you paid to fill it.

The fix is structural: keep the state on your side from day one

You can’t negotiate your way out of this after the fact. The only durable fix is architectural — make sure the accumulated state never lives anywhere you don’t control.

That’s the stance FlowDrop takes. The editor and the runtime are decoupled from the data:

• Your agent’s memory and conversations live in your database, in a schema you can read, query, and migrate — not in ours.
• The runtime is swappable. Because workflows follow an open execution spec, the same agent can run on the hosted runtime, an open-source one, or your own engine. Changing where it runs doesn’t touch where its state lives.
• The model is swappable too — exactly as it should be, since the model was never the thing holding your value.

When the state is already on your side, switching stops being an exit event and becomes a configuration change. You can move the runtime without moving the memory. You can change models without losing a thing the agent learned. Nothing has to be re-earned, because nothing was ever held hostage.

The point isn’t that you’ll definitely switch. It’s that an agent you could leave at any time is the only one you actually own.

What to ask before you commit

You don’t need to predict the future to avoid this trap. You just need to ask the questions on the way in, while you still have leverage:

• Where does my agent’s memory physically live — my database or yours?
• If I leave, do I get a usable schema, or a dump tied to your runtime?
• Can I change the model without re-accumulating anything?
• Can I change the runtime without migrating the data?
• Does the cost of leaving grow the longer I stay?

If the honest answers put your agent’s edge inside someone else’s database, the price you’re comparing on day one isn’t the real price. The real one comes due later — and it’s been quietly compounding the whole time.

Related: Every conversation your agent has is your data — do you own it? and Why your AI workflow tool should be backend-agnostic.

Building it yourself? Start with the docs →