When Your AI Workflow Stops Working

One Operational Ecosystem, Part 4

At 9:15 on Friday morning, the purchasing assistant stops confirming supplier availability. It can still open specifications and prepare a comparison. The chat window responds normally. But the connection to the supplier's ordering system is unavailable, and production needs a decision before noon.

The purchasing manager has three orders in progress. One is still being prepared. Another has approval but has not been submitted. The third was sent just before the connection failed, and nobody has received confirmation.

What should the team do next?

This is where our hypothetical purchasing example moves into day-to-day operations. The earlier articles covered putting AI to work, checking its information, and defining its authority. Now the team needs to keep working through an interruption without losing track of what has already happened.

Establish what is still working

The assistant's ability to answer a question tells the manager very little about whether it can complete a purchase.

In this example, document retrieval is available. Supplier availability cannot be confirmed. Order submission is interrupted. Those differences should be visible to the person using the system.

I would want the interface to explain the effect on the task: “You can prepare a comparison, but current availability cannot be checked and new orders are on hold.” It should also show when the last successful check occurred, wherever previously retrieved information is still being displayed.

That gives the manager a basis for deciding which work can continue. A general error message leaves them guessing. A normal-looking response based on old information could encourage them to proceed without realizing that a required check has failed.

Each step in the workflow needs an agreed response to missing dependencies. Drafting a comparison may remain useful during an interruption. Committing money may need to wait. The business should settle those choices before someone has to make them under pressure.

Make the unfinished work visible

The three orders need different treatment.

The draft can remain available for editing, with any unverified information clearly marked. The approved order should stay in the queue until the required checks can be completed. The submitted order needs investigation because its outcome is unknown.

I would expect the team to have a work list that survives the interruption and shows these distinctions. Each item should have a stable reference, its last confirmed state, the time of that confirmation, and the next action required.

For the third order, that next action might be contacting the supplier with the existing order reference. Sending a replacement order immediately would risk buying the same components twice.

The operating procedure should identify who resolves uncertain outcomes and how they record the answer. A note in a private chat or someone's memory will be difficult for the next person on shift to find.

Recovery begins with knowing what is pending, what has completed, and what remains uncertain. Restarting the assistant does not settle those questions.

Give the team a usable fallback

“Use the manual process” sounds straightforward until the team tries it.

Can the buyer still access the supplier's contact details? Can they retrieve the approved specification and quote? Does their account allow them to enter an order directly? Who checks that the assistant has not already submitted it?

For this workflow, I would prepare a short fallback procedure and test it with the people expected to use it. It should explain how to take ownership of a pending purchase, verify its state, complete the necessary checks, and record any action taken outside the assistant.

Someone also needs to stop the automated workflow from processing that purchase in parallel. Otherwise, a buyer might place an order by phone while the assistant submits its queued copy after the connection returns.

The fallback should preserve the business's approval requirements. If the purchasing team needs an exception during an interruption, there should be a defined person who can authorize it, a clear scope, and a record of the decision.

There may be less capacity while the team works manually. I would agree which purchases take priority and what can wait. An alternative process that cannot handle the expected workload needs that limitation made explicit.

Choose deployment arrangements around the work

The interruption also raises a question about where the system runs.

A local model might let the assistant continue drafting while a hosted model is unreachable. That would be useful if the required documents and permissions were also available locally. It would not restore the supplier's ordering service or confirm stock that had changed elsewhere.

A cloud-hosted assistant might remain available when equipment at one office fails, provided staff still have a working connection and a way to sign in. The relevant question is which parts of the workflow remain usable under the failure being considered.

I would ask the team to consider specific interruptions: loss of internet access, an unavailable business application, a failed local machine, or an identity service that cannot confirm access. For each, decide what can continue, for how long, and with which restrictions.

The answers may lead to local copies of selected records, an alternative connection, spare equipment, or a procedure for working without the assistant. Each choice brings maintenance work. Copies need updating, equipment needs support, and fallback procedures need practice.

That is a more useful basis for a deployment decision than assuming a location alone provides continuity.

Decide who takes charge

The purchasing manager needs a clear contact when the workflow stops progressing. That person needs the means to investigate, communicate the impact, and coordinate a response.

Technical support may be responsible for restoring the connection. Procurement owns decisions about pending purchases. A supplier may need to confirm whether an order was received. These responsibilities should be understood well enough that the buyer does not have to assemble the response from scratch.

In Chapter 3 of my Applied AI Handbook, I discuss the need to observe a system's state, adjust its behavior, and provide clear escalation paths. For our purchasing assistant, those ideas translate into practical controls: inspect pending work, pause submission, assign an order for manual handling, and tell users what remains available.

The person responsible for the business outcome should know who can operate those controls. A pause mechanism that only the original developer understands is a weak arrangement for a busy Friday morning.

Resume work deliberately

At 11:00, the connection returns. The team has already dealt with one purchase by phone. Another is no longer needed. A third still requires confirmation.

I would reconcile those items before allowing the queue to resume. Orders completed manually should be recorded and removed from further submission. Canceled work should remain canceled. Uncertain outcomes should be resolved rather than treated as failures that can simply be retried.

Pending orders may also need fresh checks. A quote could have expired during the interruption, an approval could have been withdrawn, or the required delivery date could now be impossible.

Restoring the service and releasing the backlog should be separate decisions. The team needs evidence that the connection is working and that the queued work is still appropriate to carry out.

Afterward, I would review how long it took to identify the problem, which records were difficult to find, and how much manual work was required. Those observations provide specific improvements for the next interruption.

Rehearse one interruption

Before expanding an AI workflow, choose one dependency and test its loss in a controlled environment. Use test transactions so the exercise cannot place real orders or disrupt production.

Ask someone from the business to work through the interruption using the information and procedures they would actually have. Watch whether they can identify affected work, distinguish an unsent order from an uncertain one, and find the person authorized to help.

Then restore the dependency and test the return to normal operation. Check that manually completed work stays completed and that changed conditions trigger the required review.

For our purchasing team, a successful exercise would end with every order accounted for, clear ownership of unresolved items, and a workable path through the deadline.

Take one task your business now depends on AI to perform. If a required service became unavailable tomorrow morning, could the team explain what would stop, what could continue, and how it would recover? That is worth finding out while there is time to improve the answer.

Further reading

• Dom Jocubeit, Applied AI Handbook: Implementing AI Without Breaking the Business, the Law, or Trust, Chapter 3, “System Design as Governance,” particularly “Designing for Intervention,” p. 39.