Every automated workflow depends on the systems it connects to. In regulated work, what the workflow does when one of those systems is unavailable needs to be designed and tested before go-live.
Lumay.ai recently published a ranking of what it calls the 20 best AI automation solutions companies in 2026. Each firm gets a score out of ten, a short list of strengths and weaknesses, and a note on the kind of company it suits. One weakness, listed for Tray.ai at number 19 with a score of 8.2, deserves attention from anyone who runs regulated work. The list says the platform is "highly dependent on external API endpoint availability."
That sentence describes nearly every automation that connects systems, whoever builds it. An AI agent that reads an invoice, matches it to a purchase order in the ERP and routes it for approval is calling at least two other systems to do its job. If either one is down for maintenance or returning errors, the agent cannot finish its step. For an operations or quality leader, the useful question is what happens to that item of work while the other system is unavailable.
In most businesses, a failed integration causes a delay and a frustrated user. In a regulated process it can produce an incomplete record, a step that appears finished when it was not, or a decision made on stale data. Picture a complaint intake workflow at a device manufacturer where an agent classifies each complaint after pulling the device history from another system. If that lookup fails silently and the agent classifies the complaint anyway, the file now holds a judgment made without the information it was supposed to use, and nothing in the record says so.
Finance carries the same exposure. A payment approval that depends on a vendor master lookup, or a reconciliation that depends on a bank feed, becomes a control failure when the workflow proceeds as if missing data were present. Auditors testing internal controls under Sarbanes-Oxley can reasonably ask how a process behaves when its inputs are unavailable. For FDA-regulated companies, 21 CFR Part 11 adds the expectation that electronic records be trustworthy and complete, and a half-finished automated step can undermine that without anyone noticing.
Most integration tools retry a failed call a few times, and retries handle brief outages well. A long maintenance window, an expired credential or a renamed field in the other system will exhaust them. At that point the workflow does whatever its designers decided it should do, or whatever the default happens to be if nobody decided.
I think the failure path deserves the same design attention as the main path, and it belongs in the process documentation before go-live. The first decision is whether the workflow holds the item until the system returns or routes it to a person who can complete the step another way. Holding is the safer choice when the missing data is essential to the decision. Routing to a person makes sense when the work is time sensitive and someone has an alternative source they are authorized to use.
The second decision is what the record shows. If an item waited four hours for the ERP to come back, the audit trail should show the failed attempt, the wait and the time the step finally ran. If a person completed the step manually, the record should show who did it and which source they used. Logging the normal path takes little effort, while logging exceptions takes deliberate work, which is why exception logging tends to be the thinnest part of an automation design.
The third decision is who is watching. A queue of held items only helps if a named owner in the business sees it growing and knows whom to call. Alerts should reach that process owner as well as whoever supports the integration technically.
Any workflow that draws data from another system carries this dependency, including well-designed ones. The quoting application Laminar built for Axonics pulls pricing from the ERP, which keeps quotes tied to the system of record. That is the right design, and it also makes ERP availability part of quoting availability. Pulling live data is usually the correct choice in regulated work, provided each connection is treated as a dependency with an owner and a defined behavior when it fails.
Testing failure is harder than testing success. Validation teams need to simulate outages in a test environment, which takes coordination with whoever owns the connected system, and some legacy platforms offer no practical way to do it. There is also a change control gap. When the vendor of a connected system changes its API, the behavior of your validated workflow can change without anyone filing a change request on your side. This can look like a purely technical matter to IT, and the consequences still land on the process owner and the quality record.
Dealing with a similar challenge?
We work with mid-market companies in regulated industries to build AI workflows that actually hold up.
Let's TalkSean Cummings
Founder of Laminar Consulting Services. Specializes in AI workflow automation for regulated industries — medical device, financial services, and complex logistics operations.