Every automation looks good when everything goes according to plan.
The API responds. The data is correct. The AI understands the request. The workflow follows the expected path. The external system is available. The approval arrives on time.
Then reality gets involved.
An API times out. A system is unavailable. Information is missing. An AI model returns something unexpected. An approval never arrives. A customer changes the request halfway through the process.
That does not mean the automation was badly designed.
It means it operates in the real world.
The important question is not whether something will eventually go wrong.
It is what happens to the work when it does.
A failed step should not mean a failed process
Traditional automation often focuses heavily on the happy path.
When step one succeeds, run step two. When step two completes, call step three.
That works until step three does not behave as expected.
At that point, a technically simple problem can become an operational one.
Did the first two actions already happen? Should they be repeated? Is it safe to retry? Does someone need to make a decision? Who needs to know? Can the process continue from where it stopped, or does everything have to start again?
These questions matter much more than whether an error was written to a log.
The work still exists.
Someone still expects an outcome.
A technical failure and a business failure are not the same thing
Sometimes a technical component fails and the business process recovers perfectly.
An API times out, the workflow retries it and the work continues. Nobody needs to care.
That is good automation.
But the opposite can also happen.
Every technical component reports success, yet the business outcome never happens.
The API returned 200.
The workflow completed.
The AI generated its response.
But an approval is still waiting, an exception went to the wrong place or the customer never received what they asked for.
Technically, everything worked.
Operationally, it failed.
That distinction is important.
Success should not be measured only by whether the automation ran. It should be measured by whether the work got done.
Recovery needs context
When automation fails, knowing that something went wrong is only the beginning.
To recover properly, you need to know what already happened.
Which systems were called? What information was retrieved? What decisions were made? What did the AI recommend? Which actions were completed? Which ones were not? Has anything already been changed in another system?
Without that context, recovery often means investigation.
Someone opens several applications, checks logs, asks colleagues what happened and tries to reconstruct the process.
That can take longer than the original work.
A well-designed automation should preserve the context as it executes so that, when something does require attention, nobody has to reconstruct the story from scratch.
Sometimes the correct recovery mechanism is a person
Not every exception should be solved with another layer of automation.
Sometimes the system should retry.
Sometimes it should choose another path.
Sometimes it should wait.
And sometimes it should simply ask a person.
But when a person becomes involved, they should not receive an error code and a blank screen.
They should receive the work with its history intact: what happened, what the systems found, what has already been completed and why their judgement is needed.
They make the decision.
Then the automation continues.
Human intervention does not have to break the automated process. It can be one of the ways the process recovers.
This is where the case becomes important
At Cention, we distinguish between the workflow and the work itself