When an AI agent’s request to change a business system times out, do not interpret the missing response as proof that nothing happened. The service might have completed the action, or it might still be processing it. Before enabling automatic retries, define how the integration identifies the original operation, discovers its outcome and prevents a second attempt from creating a second effect.
This is a design decision for the application owner and developer, not something a more confident completion message can settle. The relevant outcome is one intended ticket, booking or notification, with an accurate record of uncertainty when completion cannot be established.
Our existing customer-support resolution guide introduces the need to check an unknown action. This article examines the harder implementation question: when does that check justify another write? The timeline and operating rules below are editorial proposals, not results from a product trial.
An empty status check can still leave the outcome unknown
Jiapeng Li’s September 24, 2026 preprint, Where Does Exactly-Once Live?, studies agents in a deterministic sandbox with simulated services and injected failures. Its key distinction is between faults a read-back can resolve and faults involving requests still in flight or delivered more than once. An empty read can precede a late commit, so verification alone cannot guarantee one execution without additional timing or service guarantees.
The study grades committed effects, including duplicates later undone. Its services are simulated, model versions are from September 2026, and several analyses are exploratory. It is research from a model vendor, not independent production validation. We use its failure distinction rather than generalizing its numerical results to current business tools.
Consider a fictional agent creating a maintenance ticket for an approved request. Assume this invented service creates a new ticket on every successful submission and has no duplicate-prevention mechanism:
- The agent submits the ticket. Processing continues, but the connection times out.
- A status lookup returns no ticket because the original submission has not finished.
- The agent submits again, interpreting the empty lookup as permission to retry.
- Both submissions finish. Two technicians now see work arising from one request.
The lookup was not necessarily inaccurate. It answered what existed at that moment, while the integration needed to know whether the original submission could still complete. The response to this scenario should be designed before the agent encounters it.
Give the business operation an identity before dispatch
Create a durable record of the intended operation before sending it. For the fictional ticket workflow, that record could contain the approved maintenance-request reference, operation type, target system, fixed parameters, attempt history and current status. Retain only the information needed for recovery and audit under the organization’s data-handling rules.
Distinguish the operation from each transmission attempt. Restarting a worker, resuming an agent conversation or retrying a connection should not silently turn one approved request into a new business operation. Conversely, two separately approved requests for identical work may legitimately require two tickets.
Malcolm Featonby’s Amazon Builders’ Library engineering account explains why matching request parameters alone cannot reliably identify duplicates: customers can intend identical operations. It describes caller-provided request identifiers, service-side handling and the need to coordinate recording the identifier with the mutation. This is AWS practitioner guidance; the behavior of a particular connector still requires its own contract.
For a service that supports an idempotency key, generate and persist the key before the first attempt, then transmit it through the supported field. Idempotency here means repeating the same operation does not add another effect beyond the first. Merely saving a key in the agent’s notes cannot make a service honor it.
Check the whole path. Does the connector expose the field? Does middleware preserve it? Will a resumed run recover the same key and parameters? Which account, endpoint and retention period define its scope? Assign these questions to the integration owner rather than leaving the model to invent answers during recovery.
Read the actual retry contract, including its limits
Stripe’s idempotent-request documentation provides a concrete example of why details matter. For API v1, Stripe retains the initial status and body after endpoint execution begins, including server errors. It compares parameters on repeated keys and can prune keys once they are at least 24 hours old. Reusing a pruned key can create a new request. API v2 has different replay behavior; the v1 rules should not be generalized to it.
These are Stripe’s documented semantics, not a universal guarantee for agent tools. A different service may offer a conditional update, a unique external reference or an operation-status endpoint instead. Each mechanism addresses particular risks. A condition that protects a record update does not automatically prevent a separate notification from being sent twice.
Record which layers can retry: the agent, its framework, the connector, the SDK and any queue. Give one component responsibility for the overall attempt budget and recovery decision. Otherwise, an apparently modest retry setting can coexist with other automatic retries the application owner has not considered.
Changing parameters also changes the recovery question. If the agent corrects the ticket description after a timeout, it must first establish what happened to the original operation. Starting a new request because the wording improved could leave both versions in the target system.
Choose recovery from evidence rather than an error label
The following decision table is a proposed review aid for the fictional integration. Its implementation must use the target service’s documented behavior and the authority already granted to the workflow.
| Evidence available | Recovery decision | What must remain visible |
|---|---|---|
| Matching committed ticket identified | Record completion; avoid another creation | Ticket reference and verified outcome |
| Original operation still processing | Follow the service’s wait or status procedure | Pending operation and next check |
| Retry protected by a valid service-side key | Preserve the original key and parameters within its documented scope | Attempts belong to one operation |
| Service authoritatively establishes no effect and no remaining execution | Consider a retry under the approved policy | Evidence supporting that decision |
| Empty search result with uncertain visibility or processing | Keep outcome unknown; reconcile or escalate | Owner, uncertainty and follow-up |
Stripe’s advanced error-handling guidance similarly treats a 500 outcome as indeterminate and warns against switching to a new key before resolving it. It describes object retrieval, dashboard inspection and webhook events as reconciliation paths. Those are product-specific mechanisms, not evidence that every tool exposes equivalent status information.
For another integration, identify its authoritative status source and visibility guarantees. A search index, activity feed or cached listing may lag behind the write system. If no available mechanism can settle the outcome safely, retain an explicit unresolved operation for an accountable owner. “Unknown” should initiate follow-up, not disappear when the chat ends.
Handle batches and compensation as separate operations
A workflow may create several tickets, then fail after some succeed. Do not assume resending the whole collection is safe because the top-level response was an error. Agree whether the endpoint is atomic, supports resumable batches or returns item-level results. Where appropriate, give each intended item its own durable identity and track its outcome.
The fictional maintenance workflow might also notify a coordinator after ticket creation. Treat creation and notification as separate effects with their own recovery rules. Confirming the ticket exists does not establish whether the notification was sent, and retrying both steps can duplicate one of them.
If a duplicate is discovered, do not equate deleting it with having prevented it. Someone may already have received a message or begun work. Record the incident and any authorized corrective action. Compensation can require a separate decision, may fail, and should not remove the original evidence from the audit record.
Test uncertainty before granting wider write access
Use a controlled environment with synthetic records and an independent record of committed effects. Ask the development team to exercise a request rejected before execution, a successful write with a lost acknowledgement, a delayed completion, a stale status response and a partially completed batch. Include restarts and simultaneous retries of the same approved operation.
For each scenario, inspect the resulting records and the attempt history. Did one intended operation create excess effects? Was required work omitted? Did unresolved work retain an owner? Did the user-facing report accurately describe what was confirmed? A passing happy-path demonstration does not answer these questions.
These are proposed tests; we have not executed them against an agent or business service for this article. Start with one bounded workflow and document the actual connector, API and retry configuration tested. Keep ambiguous, unprotected writes under a recovery process the team can operate. Expand autonomy only when the integration can both limit repeated effects and make its remaining uncertainty visible.