Treat an uncertain response as a product problem
Imagine an AI workflow preparing a customer campaign and asking a connected service to publish it. The request times out. Did publication fail, or did it succeed before the response was lost? Sending the same request again could create a second campaign. This hypothetical example shows why an automation plan needs a recovery path alongside its happy path. Agree which operations can be repeated and which require a status check or human decision.
Know which layer owns the retry
Retry behavior depends on how an operation is invoked. AWS Lambda documentation says direct invocation does not automatically retry function-code errors; the caller chooses the response. Failed asynchronous invocations are retried up to two times by default. Other connected services can have their own behavior. Map those layers before enabling retries in an application, worker, and connector simultaneously. A timeout alone does not tell you whether an operation completed. Read the Lambda retry guidance.
Give each business operation a stable identity
Amazon’s Builders’ Library describes caller-provided request identifiers that let an API recognize repeated requests for the same operation. Identical parameters alone may not establish identical intent: a customer can legitimately request two identical items. For a custom pipeline, define the business operation before selecting its identifier. Keep that identifier stable during retries, and specify how the receiving service handles an identifier reused with different parameters. Confirm the actual connector supports this contract. Read the idempotent API guidance.
Separate a draft from a committed action
Our proposed pilot separates model-generated drafts, reviewer acceptance, and external actions into explicit stages. Record the accepted draft and its version before starting an action. If the action’s result is uncertain, reconcile its status before repeating it. Provide an operator with the operation identifier, last confirmed stage, and an appropriate recovery option. Avoid treating a fresh model response as proof that an earlier external action failed.
Test the interruption, then measure the recovery
Before expanding automation, simulate a lost response, duplicate event delivery, and a failure after an external action succeeds. Check that the final business state matches the intended operation. Track unresolved actions, duplicate outcomes, recovery time, and manual interventions alongside model quality and usage. Set a bounded retry policy and an escalation owner. These are suggested acceptance tests, not claims of measured client performance or guaranteed exactly-once execution.