AI Provider Exit Strategy: What to Keep, Export and Document

An AI provider exit strategy is a maintained set of exports, documents and tested procedures that lets you move your agents to another provider without losing what makes them yours: instructions, knowledge, memory, integrations, permissions and proof of how they behave. Build it while the relationship is healthy, because the material is easiest to collect when nobody is in a hurry. The aim is not to leave. It is to make leaving possible, which also keeps every provider honest.

Key takeaways

• The model is the most replaceable part of an AI setup. Your instructions, knowledge, memory, tool definitions and tests are where your investment actually lives.
• Accounts, credentials and data stores should be registered in your company's name, not the provider's, so access does not depend on goodwill.
• Exports only count once they have been restored somewhere else. Rehearse the exit on a small scale before you need it.
• Documentation of decisions (why the agent behaves as it does, what it may never do) is as valuable as the files themselves.
• Review the plan on a recurring schedule, because a plan that was accurate at signing drifts as the setup changes.

What does an AI provider exit plan actually cover?

Most people picture an exit as copying files. In practice an AI setup has several layers, and each one can be portable or trapped. A useful way to see it: the model generates language, the harness around it decides what the model sees, which tools it can call and when it must stop, and your company supplies the knowledge, rules and accounts. If you want the vocabulary, AI model, agent and harness: what is the difference? explains the split.

The exit plan has to address the layers you would lose or have to rebuild if the provider disappeared tomorrow:

• Behavior: the instructions, task definitions, tone rules and escalation rules that shape what the agent does.
• Knowledge: the documents, structured records and indexes the agent draws on.
• Memory: what the agent has learned about your customers, projects and preferences over time.
• Tools and integrations: the connections to email, calendar, CRM, messaging and internal systems, plus the permissions each one carries.
• Identity and channels: the accounts, numbers and addresses the agent uses to act.
• Evidence: logs, test sets and records of approved decisions.

Lock-in rarely arrives as one dramatic clause. It builds up through small conveniences, which is why How to Avoid AI Vendor Lock-In With Business Agents is worth reading alongside this plan. This article focuses on the practical inventory and the handover.

Which assets should you be able to export?

Start with a plain inventory. For each asset, record where it lives, who can access it, in what format it can be exported and whether you have actually done so. The list below is a reasonable minimum for a business agent.

• Agent instructions: the full text of system instructions, role descriptions and style rules, with version history if it exists.
• Task contracts: for each workflow, what the agent receives, what it must return and what counts as done.
• Knowledge sources: the original documents, not only the provider's processed copy, plus any metadata such as owner, date and approval status.
• Index configuration: how documents are split, labeled and retrieved, so the same behavior can be reproduced elsewhere.
• Memory records: the stored facts and notes the agent keeps, in a readable format with source and date for each entry.
• Tool definitions: names, inputs, outputs, error behavior and the permission level of each tool (read, draft or send).
• Integration settings: which systems are connected, through which method, and which scopes were granted.
• Channel assets: phone numbers, messaging business accounts, mailboxes and domains the agent uses.
• Test sets and results: the examples you use to judge quality, and the latest outcomes.
• Logs and approval records: what the agent did, what a human approved and what was rejected.

The question of who holds legal rights over these items deserves its own read. Who Owns Your AI Prompts, Memory and Data? A Company Guide covers it in detail. For the exit plan, the working rule is simple: if you cannot export it in a format a human can read, treat it as not yet yours.

### Accounts and credentials come first

The most common exit failure is not missing data. It is missing access. If the provider registered the messaging number, owns the OAuth application or holds the only administrator login, you are negotiating from a weak position. Delegated access to your systems should use standard authorization flows such as [OAuth 2.0](https://developers.google.com/identity/protocols/oauth2), where your organization can see and revoke each grant. Keep these in your name:

• Domain, mailbox and messaging accounts used by the agent.
• Administrator access to each connected system, with at least two named people on your side.
• Cloud storage or databases where documents and memory are kept.
• Billing relationships with any underlying model or infrastructure service, where practical.

What documentation makes a setup portable?

Files without context are a pile. A new provider, or a new internal team, needs to understand why the setup looks the way it does. Ask for, or write, the following documents and store them with your own records.

• An architecture summary: one or two pages describing the layers, the data flows and which systems the agent can touch.
• A permission map: every tool, its access level, who approved it and what it must never do without a human.
• An escalation guide: when the agent stops and asks, to whom, and with what information attached.
• A change log: what was modified, when, by whom and why. Without this, a replacement team repeats old mistakes.
• Known failure notes: the situations where the agent struggled, and the rules added in response.
• A dependency list: third-party services, model versions, schedules, webhooks and any scripts the setup relies on.
• An operating calendar: recurring jobs, review dates and renewal dates for credentials and certificates.

If your agent connects to tools through a shared protocol such as the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro), the tool descriptions themselves become part of this documentation, and they travel more easily between providers than custom, provider-specific connectors do. Prefer open or well-documented interfaces where the choice exists.

For work in progress, a structured handoff note matters too. An AI agent handoff template that preserves the work shows what to capture so unfinished tasks do not vanish in a switch.

How do you rehearse the exit before you need it?

An export you have never restored is a hope, not an asset. A rehearsal does not require leaving your provider. It requires proving that someone else could pick up the pieces. Work through these steps with a small, low-risk workflow.

• Step one: choose one workflow with a clear purpose and limited permissions, so a failed rehearsal cannot hurt customers.
• Step two: request a full export of its instructions, knowledge, memory and tool definitions, and note how long it takes and what is missing.
• Step three: open every file as a person outside the provider would. Check that formats are readable and that records carry their source and date.
• Step four: rebuild a minimal version in a separate environment, even a basic one, using only the export and the documentation.
• Step five: run your test set against the rebuilt version and compare outputs with the current setup. Differences in wording are fine. Differences in decisions are findings.
• Step six: list every gap, assign an owner and a due date, and ask the provider to close the ones on their side.
• Step seven: record the date, the findings and the next rehearsal date in your governance notes.

The test set is the piece that makes the rehearsal meaningful. If you do not have one, Build a golden test set for your AI workflow is the place to start. Evaluation tooling from model vendors, such as the [OpenAI evals guide](https://platform.openai.com/docs/guides/evals), can help structure the checks, though a spreadsheet of realistic cases with expected outcomes is enough to begin.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a description of a real company.

A small distribution firm uses an AI agent to prepare customer follow-up drafts and update a shared task list. The provider hosts the instructions and the memory of customer preferences. The firm decides to rehearse an exit and asks for a full export of the follow-up workflow.

The export arrives with instructions and tool definitions, but the memory notes come as a single unlabeled file with no dates. The firm cannot tell which preferences are current. The messaging account used for customer contact turns out to be registered under the provider's administrator. The test set exists only as a few examples in a chat thread.

None of this causes harm, because it was a rehearsal. The firm now has a short, concrete list: dated and sourced memory exports, transfer of the messaging account to a company administrator, and a proper test set stored in the firm's own drive. Six weeks later, a second rehearsal shows the rebuilt workflow produces the same decisions on every test case. The firm has not changed provider, but it can, and its conversations with the current provider are noticeably calmer.

How does Be Human approach exit readiness?

Be Human designs the setup so that portability is part of the build rather than a late request. Accounts, channels and data stores are set up under the client's control, instructions and tool definitions are kept in readable form, and permissions are documented per tool with approval boundaries stated. Managed operations include recurring evaluations and permission reviews, which keep the inventory and the test set current as the setup changes. The client can request an export and a handover package at any point, written in English or Portuguese.

When should you actually trigger the plan?

Having a plan does not mean using it at the first irritation. Use this decision guide to separate a problem to fix from a reason to move.

• The provider misses agreed support or reliability commitments repeatedly and does not respond to a written remediation request: prepare to move, and start with a rehearsal export.
• Quality has dropped but your test set shows the cause is in your own documents or instructions: fix the setup first, since a new provider would inherit the same problem.
• The provider changes terms, data handling or subprocessors in a way your security review cannot accept: begin the exit steps and involve whoever owns governance.
• A needed integration or channel is unsupported and unlikely to be added: compare options before leaving, since a smaller change may solve it.
• The provider is being acquired, restructured or winding down: complete a full export immediately, then decide.
• Your own needs have outgrown the arrangement, for example a move toward an internal team: use the plan as the handover, and read In-House AI Team vs External Partner for the trade-offs.

In every case, move one workflow at a time, keep the old and new setups running side by side for a short period and let humans approve actions until the test set passes on the new side.

Frequently asked questions

How often should we update the exit plan? Review it on a fixed rhythm and after any significant change, such as a new integration, a new channel or a change of model. The inventory goes out of date quietly, so tie the review to your regular permission and evaluation reviews rather than leaving it as a one-off project.

Do we need to export everything, including old logs? Not necessarily everything, but you should decide deliberately what to keep. Approval records, incident notes and logs that show how decisions were made are usually worth keeping for accountability, while raw technical noise can be summarized. Check any retention obligations with whoever handles legal and data protection for your company.

Can we prepare an exit if the provider is uncooperative? Partly. You can keep your own copies of source documents, instructions you wrote, test sets and account registrations from the start, and you can document permissions yourself. What you cannot recover without cooperation is provider-side memory and configuration, which is why asking for export rights and formats in writing before you sign matters.

Is an exit plan only for large companies? No. Smaller companies often have the most to lose, because one person usually set up the agent and the knowledge sits in their head. A short inventory, named administrators and one rehearsed export give a small firm most of the protection at a modest effort.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.