The first AI agent saves time. The second connects to a system of record. A few months later, a team cannot finish a core process without the model, connector, workflow platform, and one person who understands how the whole thing works.
That is the point when a useful implementation becomes a business dependency.
Most buyers test whether an agent works. Fewer test whether the business can keep operating when one part of the agent stops working, changes its terms, loses access, or disappears.
Before a workflow becomes critical, build an AI agent business continuity plan around four choices: substitute the dependency, run with redundancy, continue manually, or protect the risk through the contract. "We will figure it out" is not a fifth choice.
Separate recovery from continuity
A failure recovery plan handles a bad run: a timed-out tool call, a duplicate action, a partial write, or a queue that needs reconciliation.
Continuity handles a bigger problem. The model endpoint is unavailable for an extended period. A connector is retired. The platform changes a capability you depend on. The vendor terminates service. Your only specialist leaves. The workflow still matters, but one dependency is no longer usable.
Do not use one generic "AI outage" scenario. The response depends on what failed and which parts of the workflow you still control.
Map the dependency chain before choosing a fallback
Start with one business workflow, not the entire AI program. Draw the path from trigger to completed outcome. Mark the model, prompts and policies, data sources, identity service, agent framework, connectors, approval queue, system writes, logs, vendor support, and people required to operate it.
The AI agent data map covers information movement. Add a second layer that shows ownership and substitution. For every component, record who owns it, where its configuration lives, which data or state it holds, how it can be exported, what could replace it, and how long replacement would take under a tested procedure.
This exposes the dependencies hidden by a clean demo. A workflow may use a replaceable language model but still be trapped by a proprietary connector, approval interface, embedded memory store, or undocumented policy written by one contractor.
Give every dependency one continuity treatment
| Treatment | Use it when | Evidence to require |
|---|---|---|
| Substitution | Another component can perform the job within acceptable quality, cost, and control limits | A completed swap test using representative work |
| Redundancy | The workflow cannot wait for procurement or reconfiguration | Independent capacity, current credentials, routing rules, and a tested cutover |
| Manual continuity | People can safely complete or defer the work for a defined period | A usable queue, current instructions, access, staffing, and reconciliation steps |
| Contract remedy | Replacement is slow or the vendor controls essential data, configuration, or support | Export rights, assistance, notice, service commitments, termination terms, and liability review |
Some dependencies need more than one treatment. A critical customer workflow may need a second provider for short outages, a manual path for unusual cases, and contract language for long-term exit. A low-volume internal drafting tool may only need a documented pause rule.
A second model is not a complete continuity plan
Model substitution gets attention because it is easy to explain. Put two providers behind a common interface and route around a failure. That can help, but the model is only one component.
The substitute may interpret instructions differently, support different tool schemas, enforce different safety behavior, or change cost and latency enough to break the workflow. Test it against the same acceptance set used for production. Check business outcome, error behavior, permissions, human review demand, unit cost, and downstream writes.
The vendor pilot acceptance test should include the substitute path. A configuration that has never processed representative work is an idea, not a fallback.
Build a portability packet while the system is healthy
Portability is more than downloading chat history. The next operator needs enough material to reproduce the authorized workflow without reverse-engineering it from screenshots.
Keep current workflow diagrams, prompt and policy versions, evaluation cases, tool schemas, connector configuration, identity requirements, data mappings, approval rules, environment settings, monitoring thresholds, incident records, and known limitations. Document what cannot be exported and which vendor assistance would be required.
Store this packet somewhere the workflow vendor does not exclusively control. Protect its credentials and sensitive configuration. Assign an owner who verifies it after material changes. Your audit trail can prove what the existing system did, but it does not replace the design records needed to move it.
Manual continuity needs a real queue and real capacity
"A person can do it" sounds safe until the agent stops after processing half the queue.
The team needs to know which items finished, which are uncertain, which never started, and which require reversal. People need access to the source systems, current work instructions, decision authority, and a priority rule. Someone must decide which work can wait and which customer or financial commitments cannot.
Test the manual path without help from the person who built the agent. Measure backlog growth, error rate, completion time, staffing demand, and reconciliation effort. If the manual process cannot keep up, define a reduced service mode instead of pretending the old process is still available.
Do not ignore the key-person dependency
Many early agent systems are held together by one internal champion, one consultant, or one developer who knows where the prompts live and why the connector behaves strangely.
Name an operational owner and a technical owner. Require another qualified person to deploy a configuration change, interpret the logs, pause the workflow, rotate credentials, run the manual path, and restore service from the documentation.
If that test fails, the workflow is not ready to become more important to the business. Buying a support package may be the right answer. So may simplifying the design. The build, buy, or integrate decision should account for the support capacity you can actually maintain.
Put continuity requirements in the buying record
Ask vendors what happens when service changes or ends. Require clear answers about data and configuration export, retention after termination, transition assistance, support response, change notice, dependency disclosures, service suspension, and the customer's right to retrieve records.
Then test the exports during the pilot. Do not wait for a dispute or renewal to learn that the export omits workflow logic, approval history, or state held in a managed service.
Review the terms with the people responsible for legal, security, privacy, procurement, and operations. Continuity is partly an architecture decision and partly a contract decision. Technical flexibility does not help if the team cannot retrieve what it needs. Contract language does not help if nobody can operate the replacement.
NIST explicitly calls for third-party fallbacks
The NIST Generative AI Profile recommends contingency processes for failures or incidents involving high-risk third-party data or AI systems. Its guidance says organizations should identify over-reliance on third-party data, identify fallbacks, establish data redundancy policies, and test rollover and fallback technologies. NIST also notes that fallback may include manual processing.
The same guidance recommends reviewing vendor contracts and considering dependencies when decommissioning a generative AI system. That is useful because continuity cannot begin after the component is gone. The fallback, records, access, and responsibility must exist beforehand.
Run the loss test before expanding the workflow
Pick one dependency and make it unavailable in a controlled test. Start with a realistic scenario: model access removed, connector disabled, workflow platform unavailable, specialist absent, or vendor export required.
Can the team detect the loss, stop unsafe work, preserve in-flight state, route new items, operate the approved fallback, and reconcile the backlog? Can it meet the business's recovery target without creating a data or control problem somewhere else?
Record the result in the same production decision packet used for reliability, cost, and controls. If the dependency has no tested treatment, limit the workflow's authority and business scope until it does.
An agent should earn a larger role because it works and because the business can survive without it. That second test is less exciting than the demo. It is also what keeps a useful automation from turning into operational leverage held by a vendor, a connector, or one employee.