The agent works until one dependency stops
A company puts an AI agent in charge of reading requests, consulting customer history, preparing a recommendation and updating a business system. The pilot is successful, so the workflow becomes part of daily operations. Then the model provider slows down, the CRM API starts returning errors or the document index is outdated. The agent remains online, but the process no longer produces a reliable result.
Continuity cannot depend on the hope that every component will be available at the same time. Managers need to define which work must continue, which work can wait, when the process should use a limited alternative and when control must return to a person.
Map the minimum service before choosing a fallback
Start with the business outcome, not the technology. Identify the minimum service that still protects customers, deadlines and regulatory duties. For a service operation, that minimum may be receiving the request, issuing a protocol and preserving the original content, even if classification and response drafting are temporarily unavailable.
Separate critical dependencies from useful ones. A customer identifier may be essential, while a suggested tone for the response may be optional. Also record the maximum acceptable interruption, the volume that can accumulate and the owner who decides whether degraded operation remains acceptable.
The NIST AI Risk Management Framework playbook recommends post-deployment plans that include monitoring, override, incident response, recovery and change management. It also asks organizations to consider non-AI or semi-automated alternatives. This turns continuity into a management decision rather than an improvised technical fix.
Use four controlled responses instead of endless retries
A resilient workflow usually combines four responses. First, fail fast when a dependency is clearly unavailable, so resources are not occupied waiting for a result that will not arrive. Second, retry only transient failures, with a limit, spacing and a budget shared by the service. Third, place eligible work in a durable queue with an identifier, timestamp, priority and current state. Fourth, route critical or expired cases to a manual recovery path with the context already collected.
Retries deserve special attention. Google SRE guidance shows how retries at several layers can amplify one request into many attempts and worsen an outage. The practical rule is to distinguish temporary from permanent errors, limit attempts and avoid retrying the same failed action independently in every layer.
A fallback model or secondary API can help, but it is not automatically equivalent. Define which tasks it may perform, which quality threshold applies and which actions remain blocked. If the alternative produces a narrower result, the interface and downstream systems must mark that state explicitly.
Preserve state so recovery does not duplicate actions
Every interrupted execution needs a durable state. Record the business case identifier, completed steps, input versions, tool responses, approvals and pending action. Recovery should continue from a known checkpoint rather than replaying the entire workflow.
Use idempotency keys or equivalent controls for actions such as creating an order, sending a message or changing a record. Before repeating a write, verify whether the intended result already exists. A continuity plan that restores availability but duplicates a financial or customer action creates a second incident.
A hypothetical example: supplier onboarding
Consider a hypothetical manufacturing company, not an NM Solutions customer case. An agent receives supplier documents, extracts registration data, checks required certificates and prepares a record for approval. The workflow depends on a language model, a document repository and an ERP API.
If the model is unavailable, the company still receives the package, assigns a protocol and stores the files. The case enters a queue without automatic extraction. If the repository responds but the ERP is offline, validated data stays in a pending state and no supplier record is created. A high-priority onboarding that would stop production is sent to an analyst with the files, validation checklist and error history.
When services return, the recovery worker resumes each case from its last confirmed checkpoint. It checks whether the ERP record already exists before writing, processes higher-priority cases first and sends uncertain extractions for review. The example does not guarantee uninterrupted onboarding, but it avoids silent loss, uncontrolled repetition and decisions based on incomplete data.
Practice recovery and define the return to normal
A fallback path that is never exercised is only a diagram. Test dependency failure, queue growth, expired work, manual handoff and restoration at a planned cadence. Confirm that alerts reach the right owner and that people can understand the case without reconstructing the agent's reasoning from scattered logs.
Define exit criteria for degraded mode. Returning to normal may require stable latency, an updated data index, a sample of successful checks and controlled processing of the backlog. Keep an audit trail of what was automatic, deferred, manually completed or abandoned.
Recognize limits and make continuity proportional
Redundancy increases cost and can introduce different behavior between providers. Queues delay work and require privacy, retention and capacity controls. Manual recovery can overload specialists, while a fallback model may not meet the quality required for sensitive decisions. Some processes should stop completely when evidence is incomplete or a safe alternative does not exist.
OpenAI's agent guidance recommends setting failure thresholds and transferring control to a person when attempts exceed them. NM Solutions helps companies map critical dependencies, recovery states, ownership and safe alternatives around the business process. A diagnostic can identify where continuity needs engineering and where a clear operational procedure is enough.