22 September 2026 / Agent operations / 8 chapters

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.

A row of industrial control cabinets with the centre cabinet open for inspection.
Generated image: Villar David editorial
Read the Introduction

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.

Chapter 1: Write down each external action on its own

Got a take on this?

Share it on X. I read the replies.

All articles