Before You Automate a Workflow, Decide What Happens When It Fails

A timeout is incomplete information

Consider a system that issues refunds.

It sends a request to a payment provider. The request times out.

Retrying sounds reasonable. But first we need to know whether retrying can issue another refund.

Perhaps the provider supports an idempotency key: an identifier that lets repeated requests represent the same operation. Perhaps we can query the original transaction. Perhaps the case needs to wait for reconciliation.

The right approach depends on the provider’s behavior and guarantees.

What we cannot safely conclude is that a timeout means nothing happened.

A useful engineering habit is to ask what each failure signal actually tells us.

“No response” is often weaker evidence than we want it to be.

Start with the promises the system must keep

Before designing the steps, I want to understand the properties that must remain true.

For example:

• A repeated event must not create a second financial action.
• A failed notification must not erase a completed transaction.
• An uncertain result must remain visible until it is resolved.
• An operator must be able to identify what has already happened.

These promises make the design review more concrete.

Now we can examine whether the implementation preserves them under retries, interruptions, and concurrent requests.

Without them, it is easy to review each step in isolation and miss a failure across the whole sequence.

Every individual function can look reasonable while the workflow produces the wrong outcome.

Disagreement needs an owner

Imagine two systems reporting different inventory counts.

Which one should win?

“Use the latest value” sounds simple until we ask how the timestamps were generated, whether the updates arrived in order, and whether both systems represent the same kind of inventory.

One may track physical stock. Another may subtract reservations. A third may receive delayed adjustments.

We need to define what each value means before deciding how to reconcile them.

This is why connecting APIs is only part of integration work.

The deeper task is defining ownership and meaning across systems that were built with different assumptions.

An AI-generated connector can move the data. Someone still needs to establish what the receiving system is allowed to conclude from it.

Human review needs enough context to work

“Send exceptions to a human” is an incomplete design.

Which human? How soon? With what information?

If an operator sees only “refund failed,” they may have no way to distinguish a rejected request from a completed refund with a missing response.

They need the identifiers, relevant history, current state, and available recovery actions.

Those actions need boundaries too.

Can the operator retry? Cancel? Mark the case resolved? What prevents an accidental second action?

A review queue should help someone make a decision. Otherwise, we have moved uncertainty from software into a person’s inbox.

Recovery deserves its own acceptance criteria

Teams often define success in detail and leave recovery as something support will figure out.

I would test recovery before launch.

Take an operation halfway through. Interrupt a dependency. Deliver the same event again. Change the order in which messages arrive.

Then ask:

Can we see what happened? Can we identify what remains incomplete? Can we resume safely? Do we know when to stop retrying?

The exact tests depend on the system and its consequences. There is no single checklist that proves every workflow reliable.

But demonstrating recovery gives us stronger evidence than assuming a successful test covers failure behavior.

AI makes these decisions more visible

These are established engineering problems. AI didn’t create retries, concurrency, or partial failure.

What faster implementation can do is shorten the time between an idea and a running workflow.

That makes it easier to reach a convincing demonstration before the operating rules have been settled.

The response should be to bring those rules into the design earlier.

Use AI to explore failure scenarios, propose tests, and challenge assumptions. Verify its suggestions against the actual dependencies and requirements.

I’m interested in how much faster we can reach a system whose behavior we understand.

That includes the moments when we don’t yet know whether an operation succeeded.

A workflow is ready for real use when the team has a credible answer for those moments, not simply when the normal path runs.