Restart an interrupted AI workflow without repeating completed business actions

If your ERP saves a production-order change just before an AI worker stops, your team needs to recover without submitting the change again. A workflow that preserves its progress and checks the ERP’s result can spare your staff from reconstructing every step, while routing genuinely uncertain actions to the person responsible. AWS’s guidance explains the retry protection behind this approach.

Idempotency is the property that repeating an operation leaves its effect unchanged. Durable execution preserves completed step results; idempotent business logic protects actions that may run again because an interruption occurred before completion was recorded. AWS documents this distinction.

The practical benefit is selective recovery: carry forward confirmed results, retry eligible actions and investigate only unresolved work. FAIS would build this around your business ontology—the shared model of business objects, relationships and permitted actions—and connect it to workflow records and ERP checks. The model identifies what the action means; the connector and recovery controls establish whether it happened.

What lets your automation resume without repeating work?

Your recovery design needs evidence from the system that performs the business action. A worker restarting successfully is useful, but the operating decision depends on whether the ERP saved the intended change.

AWS Lambda returns checkpointed results instead of rerunning completed steps, while interrupted steps may execute again. Neither at-least-once nor at-most-once per retry attempt guarantees exactly-once execution across a workflow. Lambda checkpoint behavior and SDK execution semantics explain why recovery must cover the destination write as well as the worker.

A restart is a technical event; recovery is a business outcome.

Replace manual reconstruction with a traceable action

Consider an illustrative manufacturer whose automation writes an approved production-order change into its ERP. Without recovery controls, a restarted worker finds no local success record, leaving a planner to establish whether the change happened before anyone resubmits it.

With the proposed controls, the workflow stores the intended change and its action identifier before dispatch. After interruption, the connector checks authoritative ERP evidence. A matching completed action lets the worker record the destination reference and continue without another write. An uncertain result goes to the planner with the original request and available evidence.

The improvement is a narrower investigation: the planner reviews unresolved actions rather than reconstructing the entire run. Approval of a production change remains with the designated business role; recovery does not grant permission to change its payload.

FAIS would connect the production order, approved change and responsible owner to those durable action records. Our proposed business ontology and workflow automation approach builds recovery controls around your current ERP investment, rather than requiring an ERP replacement. The shared business definitions provide a reusable foundation for future automations and agents, while each connector still needs its own verified write and lookup behavior.

Make the retry decision explicit

The restarted worker should reconcile its action record with destination evidence. Specify the following decisions before testing:

Destination evidence	Recovery decision
Matching action completed with the intended payload	Record the destination reference and continue without another write.
Completion is unconfirmed, but a verified destination idempotency contract covers the retry	Retry the unchanged request with its original key.
Authoritative evidence confirms the action did not complete, and the earlier request cannot still commit.	Retry through the approved write boundary and concurrency protection.
Lookup is unavailable, visibility is uncertain or the earlier request remains outstanding	Pause dependent work and assign an owner.
The identifier matches a different payload or records conflict	Stop automatic writes and request reconciliation.

These proposed boundaries follow AWS’s guidance on stable keys and transactional checks and its treatment of changed intent and identifier retention.

A local identifier alone does not prevent duplicate destination writes. Verify the connector’s lookup consistency, transaction visibility, outstanding-request behavior, uniqueness enforcement and retention window. An empty search result is sufficient only when those checks establish what absence means.

Prove recovery on one bounded workflow

Your starting point is one ERP-writing automation, exercised in a sandbox or against isolated records with downstream effects contained. Persist its business object, intended change, action identifier, payload and owner before dispatch; keep the identifier stable across retries, as AWS’s token pattern requires.

Interrupt the worker before dispatch, while the request is outstanding and after the ERP commits but before local success is recorded. Include unavailable lookups and conflicting results. Measure recovery time, missing work, duplicate actions and unresolved handoffs against thresholds agreed before the test.

The implementation decision is whether this workflow can recover confirmed work and present uncertainty clearly enough for its owner to act. Keep operation supervised until the tested conditions meet that standard. Discussing the workflow with FAIS connects that decision to the real production-order model, connector behavior and automation controls your business needs.