A timeout does not prove the action failed
A timeout means the caller did not receive an answer within its waiting period. The receiving service may already have completed the work. Asking an agent to “try again” can therefore repeat a successful action. A more capable model cannot establish what happened inside another system from a missing response alone.
This is an integration problem, not a problem unique to AI. AWS describes idempotent operations: repeat attempts do not produce additional side effects. In a business workflow, the important outcome is one intended change, even when several attempts are needed. Keep that responsibility in the software that executes actions, rather than relying on a prompt telling the model to be careful.
Follow one invoice through the awkward case
Illustrative example, not a Fewzen client result: an operations team uses AI to extract an order from an email. Conventional checks validate the customer, amounts and required fields. A person approves a draft invoice. The workflow then asks the accounting platform to create that approved draft.
The platform creates it, but the connection drops before the workflow receives its identifier. The local record should now show an unknown outcome, not a definite failure. If the API supports a suitable idempotency key, a permitted retry uses the original key and unchanged approved request. Otherwise, the operator needs a reliable way to find the original draft before deciding what to do.
Do not rerun extraction, invent a new identifier and submit another invoice. That creates a new candidate action while the first remains unresolved. A corrected invoice is a separate decision, with its own approval and relationship to the original.
Identify the action before the first attempt
Generate and persist an opaque action identifier when the approved change is recorded. Associate it with the business account, source record, operation and approved version. Each retry of that same action reuses its identity. Two genuinely separate orders need separate identities, even when their amounts and descriptions match.
Keep a snapshot of the approved request. A second model response must not silently change the customer or amount during recovery. If the intended change is revised, stop the old action, resolve its status and obtain the appropriate approval for the revision. Avoid putting names, email addresses or other sensitive values into the identifier itself.
Track each external action separately
An invoice, a CRM update and a confirmation email are three separate effects. Record each step’s action identifier, approved input reference, status, attempts and returned destination identifier. Suggested states include pending, in progress, completed and needs investigation. Resume the unfinished step without repeating the completed ones.
A queue does not remove this responsibility. Google documents that Cloud Tasks can execute a task more than once. Two workers must not both see an action as available and submit it simultaneously. Ask the implementer how the action is claimed atomically and how a crashed worker is recovered.
A local “sent” flag alone is insufficient: the remote action can succeed before the flag is saved. The design still needs destination-side duplicate protection or a dependable reconciliation route. If neither exists, stop automatic retries for that action and make the uncertainty visible to an operator.
Check what the actual API promises
“Supports idempotency” is a starting point. Check the endpoint, API version, key lifetime, concurrent-request behaviour and response to changed parameters. Your connector must expose the required feature; its underlying platform supporting it is not enough.
For example, Stripe’s API v1 documentation says it stores the first response after execution begins, including server errors. Keys may be removed after they are at least 24 hours old; reusing a removed key creates a new request. Stripe also checks for changed parameters. These are Stripe API v1 rules, not a guarantee about an accounting connector or every Stripe API version.
Align your recovery procedure with the documented lifetime. A job restarted days later may need investigation even if it retains its original key.
Make retries limited and visible
Follow the provider’s guidance on retryable errors. A temporary connection problem is different from invalid data or missing permission. Use bounded retries with increasing delays and jitter, which spreads attempts over time. AWS explains how repeated calls can worsen an overloaded service, especially when several software layers retry independently.
Define a stopping point and an owner for unresolved work. Show the action reference, last confirmed step, last error and destination link where available. Give the operator a controlled resume action. Asking staff to restart the whole agent conversation is a poor recovery procedure when earlier steps may have succeeded.
Ask for evidence before switching it on
Use a test environment and synthetic records. Agree the expected business result before each test, then inspect the destination as well as the workflow log. A green status in the automation tool is not sufficient evidence.
- Deliver the same trigger twice and start two workers together. Expect one intended destination action.
- Drop the response after the destination accepts the request. Expect recovery to find or reuse the original result.
- Crash after the remote action but before saving local success. Expect an explicit reconciliation path.
- Change an approved input, then replay an old attempt. Expect the change to require a separate decision.
- Resume after the provider’s duplicate-protection window. Expect investigation where safe replay cannot be established.
- Fail the final step of a multi-step workflow. Expect completed earlier steps to remain completed.
Start with one recoverable action
Choose one workflow with a clear owner and a destination you can inspect. Begin with drafts where appropriate. Measure duplicates, unresolved outcomes, manual recovery time and accepted results during a limited pilot.
Duplicate protection adds state, implementation work and operational responsibility. It also does not make an incorrect action correct or replace approval. If a connector cannot support the required controls, narrow its authority or choose a more suitable integration before expanding automation.