Article
Recovering an automated workflow after a partial failure
If an automated workflow stops halfway through, some of what it did may already be sitting in other systems. Before you restart it, work out what actually finished and which steps are safe to run again.

Say you've got an automated workflow that sends an approved record to another system, waits for a response and times out. The operator sees a failed run, but the record might already be sitting in the destination. If they start it again they could create a duplicate, and if they leave it alone there might be real work that never got done. Which is it?
OpenAI's Agents API announcement this month talks about agents that keep working across long sessions, use tools and hand parts of a task off to subagents. Once work can run for hours or days, how you recover from a failure becomes part of the design, because a lot more steps can finish before anyone notices something went wrong.
I'm going to use a hypothetical document-processing workflow to talk through it. It receives a document, prepares a proposed record, gets that proposal approved, writes it to an external system and then notifies the person who asked. An AI agent might prepare the proposal or help look into an exception, but whoever designs the recovery still has to account for what each external action actually did.
What I want is for the next operator to pick up a case without guessing. The fields and checks below are what I'd propose, so adapt them to the destination's API, your approval rules and how bad a duplicate or a missing action would be.
On X
Got a take on this?
Share it on X. I read the replies.