Your model provider is not a toolbox. It is a firm boundary.

Leaving somewhere that made itself useful produces a small, specific panic.

You open the settings page.

There’s an export button, probably.

There’s a list of files.

But the thing you’re trying to move isn’t only the files.

It’s how your team asks for work.

The prompt that knows the awkward customer.

The memory of what happened last Tuesday.

The connector that makes an answer consequential.

You weren’t foolish to choose the system that worked. Everyone has to start somewhere.

The model was good enough. The integration was already there. You had deadlines, messages waiting, children to collect, bills, and an old process that couldn’t survive another quarter of being done by hand.

Taking the help wasn’t a moral failure. It was a normal response to a day already full.

Your provider is not the villain here. The problem is a category error.

Convenience makes concentration feel like integration.

A model provider stops being a shelf of interchangeable tools the moment your work depends on its data path, operating surface, memory, permissions and change calendar.

2012 — You pick one cloud drive because it’s easy. The folder has a name and the folder feels like yours.

2019 — Your team’s templates live there. Nobody remembers which version came from the shared drive and which came off somebody’s desktop.

2024 — The assistant learns the workflow. It remembers the preferred wording and finds the files without being told where they are.

2026 — Changing provider means changing the way your work remembers itself.

Where the work collects

Vendor lock-in gets described as a problem with an API, a contract, or a data format. Those are real. They aren’t the whole feeling.

The deeper problem shows up when you can’t describe your service without describing your supplier.

The work is in the prompts. The provider’s memory surface. The tool contracts. The identity path. The evaluation record. And the people who know how to coax an unusual case through.

That’s a firm boundary. Not because your provider is hostile.

Because your provider controls part of the operating world on the other side of it.

The old boundary question was whether a recurring activity sat inside the firm, with a supplier, or somewhere between.

The friendly agent makes that question easy to start and hard to see. It arrives as an answer box. Later it becomes the place the answer gets assembled.

So your dependency map has to start with the service, not the provider name.

“The model” isn’t a service. “Respond to customer-contract exceptions without exposing the wrong record” is one.

For a high-consequence service, the map covers the owner, the required outcome, the supplier chain, data location and access, maximum tolerable disruption, and the replacement or fallback state.

The Bank of England’s guidance maps five resource classes. People, processes, technology, facilities, information.

The point is plain enough. You can’t move a service by copying its visible interface.

And the map gets awkward, because it finds dependencies the architecture diagram wasn’t hiding on purpose.

A supposedly portable agent may rest on one identity provider. Several providers may share one network edge. The data may export cleanly while nobody left inside can reconstruct the retrieval path.

One trusted integrator knows which connector fails quietly.

The visible cloud usually isn’t the boundary that matters.

That’s the correction. You’re not trapped because you chose badly.

You’re dependent because dependence is what integration feels like from the inside.

Three ways out, not one

The reflex answer is that no provider should be allowed to matter.

That sounds firm until it meets an ordinary fact. Even the simplest service needs one technical integration.

A protocol. An operating system. A deployment tool. An identity mechanism. A staff skill set. A data model. A hardware platform. An operating procedure.

Every useful system connects to something. An open-source replacement can swap a visible vendor for a rare integrator or an exhausted internal team.

So exit-risk analysis doesn’t demand permanent duplication. It offers three tiers of effort.

A low-consequence commodity service can accept dependence. An important service preserves portable artifacts and a rebuild path. Only a service whose loss would exceed your impact tolerance needs a live alternate operating mode.

That’s a resilience decision. Not an insult to a provider.

GOV.UK names five situations warranting more than the simplest strategy. Concentration. High-risk data. Legacy technology. Specific feature needs. Legislative requirements.

The list is useful because it names the reason for spending more.

A one-day outage and a hostile commercial change are not the same event. The first may want a manual fallback. The second wants a future rebuild option.

Call both of them “exit” and nobody knows which recovery you actually bought.

There’s a familiar temptation here. Build everything twice, keep both providers live, call the diagram safety.

But two active platforms double your interfaces, identity paths, data replication, monitoring, incident procedures, supplier reviews and training.

They also create inconsistent records, shared dependencies, and the unbearable incident-room question of which version is authoritative.

A passive alternate decays just as effectively. Only more quietly.

Export is the beginning

There’s a particular humiliation in discovering that “export” meant “download a file.”

A real departure asks whether that file carries its relationships, time fields, permissions, attachments, configuration, and enough meaning to support an actual task.

NIST notes that portability depends on standardized interfaces and formats, while platform and software services often lack even common terminology for describing a transfer.

Your export button was never the whole promise.

The useful test has four stages. Export, validate, reconstruct, operate.

Export proves access. Validation tests completeness. Reconstruction recreates the application or process. Operation proves a queue, a report, a decision or a recovery procedure can actually work on the other side.

A representative sample exposes an unexported identifier before a crisis turns it into a migration programme.

An unsuccessful import is a design finding. Not a supplier betrayal.

With agents your portable artifact is bigger than the database.

The prompt carries local policy translated into usable language. Memory may be short-term, scoped to a thread, or long-term across threads. The tool contract says which verbs exist and what each one means.

The trace records request identity, agent and prompt version, policy decision, credential scope, approval, tool arguments, external result, recovery event. The evaluation record says which version was trusted to do what.

Leave those behind and your new provider receives data without the work that made data usable.

Memory deserves its own alarm here.

A persisted preference, a completed-task note, an organization policy and a model-generated reflection don’t share an owner or a safety property.

Shared policy memory may need to be read-only. Sensitive shared-memory writes may need human validation. A shared scratchpad anyone can write to can carry a prompt injection across sessions.

Memory isn’t your agent’s personality. It’s a writable input to tomorrow’s work.

And a familiar standard doesn’t make any of this interchangeable.

The OECD names three structural characteristics reinforcing hyperscalers. High concentration. Deep integration with other digital services. High entry or expansion barriers.

An API can move a request while leaving performance, security defaults, operational tooling, data semantics and the surrounding integration ecosystem behind.

Standards reduce friction. They don’t create equivalence.

What became specific

The old test for a difficult supplier relationship asked whether knowledge, tooling, systems, location or investment lost value outside that relationship.

Agents make the answer more intimate.

You can build a perfectly sensible set of prompts, evaluations and tool boundaries. Then the provider changes a model version, a memory policy, a connector or an approval threshold.

And you find that your accumulated arrangement doesn’t move as cleanly as your original subscription did.

Your trace is part of the exit asset, because it tells the next operating surface what has to be reproduced and what has to stay reviewable.

It also tells you when the service changed under your feet.

A new tool, a broader scope, a model version, a memory policy, an approval threshold, a connector update. Each of those is a material change.

Each needs a named owner, an evaluation, a rollback plan and a recorded authorization.

Keeping the endpoint name is not the same as keeping the system.

The limits are the point

None of this proves you should replace your model provider, or that every pilot needs an alternate production stack.

Provider-specific capability can be exactly why your service is safer or more reliable.

GOV.UK names three operational benefits of serverless technology. Easier patching. Prevention of common attacks. Better integration of monitoring and defensive capabilities.

Portability has an opportunity cost. Common-denominator design discards capability you may not be able to reproduce well.

The same restraint applies to sovereignty.

The European Commission puts data location at level one of a four-level framework. Higher levels add third-country independence, ownership and control, and supply-chain conditions.

A local copy isn’t an exit plan if it has no tested access, no current data and no usable operating process.

The honest work is less dramatic than any of this suggests. Hold an exit estimate beside your run cost.

Discovery. Build. Conversion. Validation. Parallel operation. Training. Temporary licences. Lost capacity. Internal people. Elapsed time. Money. Likely service disruption.

A range with assumptions. Not a number pretending to know the future.

That estimate will change. So will destination prices, product capabilities, staff skill and business requirements.

It may show that the sensible choice is a manual fallback, a warm rebuild, a controlled export, or explicit acceptance signed by somebody senior.

Exit-risk analysis can’t decide your impact tolerance for you. It can make the choice visible before the provider’s choice makes it for you.

Your model provider may well be the right provider. The agent may be genuinely helpful.

But once your work remembers itself through somebody’s surface, leaving stops being about swapping a tool.

It’s about moving a fragment of the firm. Its records, its routines, its authority and its memory.

That isn’t panic. That’s the boundary, finally visible.