The easiest AI decision to approve is the one that makes a team faster this quarter. The expensive decision is the one that quietly makes the team dependent on a vendor for the next five years.
That is the marketing version of AI vendor lock-in. It is not just a contract, a database, or a proprietary dashboard. It is the accumulated behavior of prompts, tools, evaluation sets, routing rules, team habits, and customer workflows that have been tuned around one model.
The model can be replaced in theory. The business built around it usually cannot be replaced in a weekend.
The new kind of lock-in
Traditional software lock-in is visible. Your records sit in a vendor database. Your workflows use a proprietary object model. Your staff knows one interface. The escape plan is painful, but it is legible. You export the data, rebuild the connections, retrain the people, and accept a temporary productivity hit.
Agentic systems add a less obvious layer: behavioral dependency. A team learns how one model follows instructions, handles tools, summarizes a customer, refuses a request, and uses context. The prompts evolve around those habits. The evaluation suite starts rewarding that model's strengths. Exceptions get patched instead of redesigned.
Over time, the model stops being a component. It becomes an assumption.
That matters in marketing because the work is full of judgment calls. An agent may classify a lead, choose a message, summarize a call, score creative, or decide which customer deserves a follow-up. Change the model and the output may still look plausible while its decisions shift underneath.
That is a harder migration problem than moving rows between databases. You are not only moving information. You are revalidating decisions.
The bill hides in the workflow
The API invoice gets most of the attention. It should not.
The bigger cost is the operating system that grows around the model. Marketing teams build prompt libraries, quality checks, retrieval rules, tool permissions, dashboards, escalation paths, and training programs. Agencies build client delivery processes around a preferred stack. Every successful experiment creates another reason not to disturb the system.
The result is a familiar finance problem. Leaders compare the cost of staying with the cost of leaving, but they only count the vendor invoice. They do not count the work required to make a second model equally safe and useful.
A real portability budget includes:
- Prompt and tool re-engineering
- Parallel testing against a fixed evaluation set
- New monitoring for accuracy, latency, refusal behavior, and cost
- Human review while the replacement model earns trust
- Retraining for the people who operate the workflow
That is why a cheaper model does not automatically create savings. If switching takes a quarter and introduces a measurable risk to customer experience, the cheaper token price may be irrelevant.
Falling prices can increase dependence
There is a strange twist in the economics. Model prices have fallen sharply for many common capabilities. The Stanford AI Index has documented the rapid decline in inference costs for systems near earlier frontier performance. Provider pricing is still a moving target, as the Anthropic API pricing page makes clear. Falling prices make experimentation easier, which is good.
They also make it easier to build too much too quickly.
A team that would have questioned a six-figure monthly experiment may approve dozens of small agents when the initial unit cost looks trivial. Those agents then acquire long contexts, more tools, more retries, and more responsibility. A workflow that began as a cheap assistant becomes a production dependency with a much larger blast radius.
The trap is not that prices never fall. The trap is building a business process that assumes one vendor will always be the cheapest, fastest, and best fit at the same time.
Multi-model is not a magic escape
The usual answer is to use several models. That is sensible, but it is not free portability.
Routing creates its own layer of software. Somebody has to decide which model gets which task, how failures are retried, how outputs are normalized, and how quality is compared. The routing layer becomes important enough to create a new dependency. A team can also end up with fragmented skills, inconsistent outputs, and a measurement problem nobody owns.
Multi-model architecture is useful when it reflects a clear business decision. Use a smaller model for classification. Use a stronger model for rare, high-value reasoning. Keep a local option for sensitive work. Do not add providers simply to make a diagram look diversified.
Portability is not the number of logos in your architecture. It is the time required to switch one important workflow without guessing what changed.
The test marketing leaders should run
Ask your team to move one production workflow to a second model in a sandbox. Do not ask whether it is technically possible. Ask for evidence.
Give both systems the same evaluation set. Compare factual accuracy, brand voice, policy compliance, tool success, latency, cost, and escalation rate. Look at the failures, not just the average score. A model that is slightly better overall may be materially worse on the one edge case that creates legal or reputational exposure.
Then ask a more uncomfortable question: how much of the replacement work depends on the current model's quirks?
If nobody can answer, the organization does not have portability. It has optimism.
This is the same measurement problem that appears in AI attribution drift. It also connects to the multi-LLM routing problem, where flexibility can become another layer of operational debt. A system can keep producing numbers while the assumptions underneath quietly change. The evaluation set is the control group that tells you whether the behavior moved.
Design the exit before the launch
The practical answer is not to avoid proprietary models. They are often the fastest way to learn what a workflow needs. The answer is to keep the first useful version from becoming the only possible version.
Store prompts, tool definitions, test cases, and expected outputs outside the model vendor's platform. Keep a small, representative evaluation set under your control. Record model versions and decision changes. Separate business rules from prompt wording. Use a model gateway only when it reduces a real switching cost rather than adding another abstraction for its own sake.
For high-stakes marketing flows, keep a human approval step until the team understands the failure pattern. Autonomy should be earned by evidence. It should not arrive because a demo looked smooth.
The AI vendor lock-in problem is also a budgeting problem. The same logic applies to the inference cost shock: a low unit price can still create a very expensive system. Put migration work in the total cost of ownership from day one. If the business cannot afford to test a second provider, it probably cannot afford to make the first provider mission-critical.
What the next negotiation looks like
The strongest AI buyers will stop asking only, “What can this model do?” They will ask, “What becomes harder to change if we use it everywhere?”
That question changes procurement, architecture, and marketing operations. It favors vendors that support clear exports, stable interfaces, model-neutral evaluation, and honest usage controls. It also forces internal teams to admit that convenience has a price, even when the invoice looks small.
The future will not be vendor-free. That is not realistic, and it is not even desirable. The goal is different: make sure a vendor is earning your dependence every quarter instead of inheriting it from one successful pilot.
An agent can be autonomous while the business behind it is completely captive. That is the part worth measuring.