AI vendor lock-in: the kill-switch risk when your agents run on one vendor

When AI was a chat window, an outage meant you wrote the email yourself. Once agents receipt payments, chase invoices and answer the phone, the vendor behind them is as critical as your bank feed. That is the trade-off of an AI execution layer: more work done, more dependence. The answer isn't to avoid dependence; it is to make it survivable.

Three ways a single vendor can stop your agents

Outages, including ones that aren't the AI company's fault

AI services run on cloud infrastructure, and cloud infrastructure fails. In October 2025 a fault in Amazon DynamoDB's DNS management in AWS's Northern Virginia region caused hours of disruption to many services that depend on it, as AWS describes in its post-event summary. You don't need to know which data centre your AI vendor uses to plan for this; you need to know what happens to your work when it is unavailable for an afternoon.

Model retirements and price changes

Models have a shelf life. Anthropic's deprecations page lists retirement dates and promises at least 60 days' notice for publicly released models; after retirement, requests to the old model fail. Other providers run similar schedules. A retirement is manageable if someone re-tests your workflows on the replacement in time. Price and usage-limit changes work the same way: they rarely arrive as a surprise, but they do arrive.

Policy and account changes

Providers change acceptable-use policies, regional availability and terms. An account can be suspended by an automated check. If every agent in your business runs through one account with one provider, a single decision you don't control can pause everything.

What you need to own, whichever vendor you use

Lock-in is mostly about where the valuable things live. Make sure these are yours, in a form you can take with you:

• Your records. Contacts, deals, notes and next actions should sit in a system you can export from (CSV at minimum), not only inside an agent's memory.
• Your instructions. The rules your agents follow ("never text tenants after 7pm", "always attach the progress note to the invoice") should be readable text you can copy out, not hidden configuration.
• Your logs. What was done, by which agent, who approved it. You may need these for a dispute, an audit or a privacy request; our security team covers this in audit trails for AI agent actions.
• Your accounts and credentials. Agents should connect to your mailbox, your CRM and your phone numbers through access you grant and can revoke, not through accounts the vendor owns.
• Your files. Documents agents produce should land in your drive or your system of record.

Model portability: test it before you need it

A workflow is portable if it would still work, perhaps a little worse, on a different model. Most aren't tested for this until an outage forces it. A simple quarterly drill:

1. Pick three of your most important agent tasks.
2. Collect five real past examples of each, with the output you accepted.
3. Run them on an alternative model (or ask your vendor to) and compare against the accepted outputs.
4. Note where the alternative falls short and whether the gap is acceptable for a few days.
5. Write down which tasks should pause during an outage and which can run on the fallback.

If you built your own stack, this drill is your job. If you buy, ask the vendor how they do it and how fast they can switch. We cover that trade-off in build your own AI agents vs buy.

The exit plan checklist

Write this down once, keep it with your business continuity notes, and review it when you add a major workflow.

1. List every task agents perform and mark each one critical, important or nice to have.
2. For critical tasks, write the manual fallback in two lines (who does it, using which system).
3. Confirm you can export CRM records, notes and files today. Do a test export.
4. Copy out the standing instructions and rules for each agent into a document you control.
5. Confirm how long logs are kept and how to download them.
6. Know your contract terms: notice period, cancellation, what happens to your data after you leave.
7. Check that phone numbers used for calls and SMS can be ported or redirected.
8. Keep the list of integrations and access grants so you can revoke them in one sitting.
9. Name the person who decides to switch to fallback, and how they will be told about an outage.
10. Re-run the portability drill after any major model change.

Questions to ask any AI vendor, including us

Where data goes is its own topic, especially in Australia, where the Privacy Act's cross-border disclosure rules apply. Our security writers explain it in sovereign AI in Australia. The OAIC's guidance on commercially available AI products also says due diligence should be ongoing, not set and forget.

How Fulcrum Cortex approaches lock-in

We are a vendor too, so judge us by the questions above. Here is what we can say from our published facts. Cortex lists several model and cloud providers among its integrations, including Anthropic, OpenAI, AWS, Microsoft Azure, Google Cloud and SCX.ai, which offers sovereign AI models. Agents connect to your own Google Workspace, Microsoft 365 or Zoho mailbox and to CRMs and accounting systems such as HubSpot, Salesforce, Xero and MYOB, so records stay in systems you control. Plans are monthly and cancel anytime. Cortex is 100% Australian owned.

What we can't do is make any provider immune to outages, including ourselves. That is why the exit plan above belongs to you, not to us. Lock-in also shapes the consolidation decision; if you are thinking of retiring tools, read our SaaS consolidation maths with this checklist beside it.

For how Cortex handles data and access, see our privacy page, and bring your vendor questions to a demo.