Prevent duplicate charges, reservations, orders, and messages when a personal agent loses a session, waits for approval, encounters a timeout, or resumes after external facts have changed.
A safe retry is not “run the prompt again.” It is a controlled continuation that knows what already happened, what remains valid, what changed, and which external action is still authorized.
Purchase and booking agents cross unreliable boundaries: model reasoning, browser sessions, inventory systems, payment providers, messaging channels, and human approval delays. Any boundary can time out after the external system accepted an action but before the agent received confirmation. If the workflow interprets the missing response as “nothing happened” and blindly repeats the step, one user request can become two reservations, two orders, two charges, or two messages.
The goal is exactly-once intent, not magical exactly-once networking. Systems cannot assume every request and response arrives once. Instead, the application assigns a stable identity to the intended action, makes repeat attempts recognizable, checks external state before repeating side effects, and stores durable evidence of the outcome.
This pattern applies to restaurant orders, grocery carts, appointment scheduling, tickets, quote acceptance, subscription changes, and any task where an agent acts beyond the conversation. It is especially relevant to a text-message AI assistant, because approvals may arrive after prepared facts have changed.
Editorial inference: retry safety will become a visible personal-agent feature. Users will expect to see what the agent might repeat, which facts were refreshed, and why the system believes a prior action did or did not occur.
Create one durable operation key for the intended purchase or booking. Keep it stable across network retries and restarts. Create a new identity only when the user materially changes the date, merchant, quantity, recipient, destination, or price ceiling.
Record each consequential step separately: reservation hold, payment authorization, booking confirmation, order submission, and outbound message. Store request identity, attempt, provider reference, response state, verification, and timestamps.
Mark volatile facts with a validity window. Before resuming, refresh prices, inventory, availability, session state, permissions, and policy checks that may have changed.
Tie approval to the exact action, destination, amount or limit, key details, and expiration. If a material fact changes, invalidate the old approval.
Do not mark success because a tool returned. Query an authoritative external state to verify the intended outcome exists exactly once, then write a receipt.
The workflow should reach a safe, legible state across common interruptions. Select a failure to inspect the required recovery behavior.
The model can propose actions, but transaction controls should decide whether a side effect may execute. Keep that boundary explicit and testable.
Convert the request into structured intent: operation type, provider, items or service, quantity, date and time, destination, price ceiling, recipient, and constraints. Create a stable operation identity tied to the user and this delegation.
operation_id = create_operation(user_id, normalized_intent) status = prepared version = 1
Let the agent search, compare, fill non-consequential fields, and prepare a candidate transaction without committing it. Identify the final side effect and its preconditions. This creates a clean approval boundary and makes volatile facts refreshable.
Show exactly what the agent will do: provider, item or service, date and time, total or maximum, cancellation terms, recipient, and expiration. Bind approval to the operation version. A reply to an old packet cannot authorize a newer transaction.
Use a transactional state change or compare-and-swap so only one worker owns commitment. A replacement worker must inspect the side-effect ledger and provider state before assuming an expired lease means nothing happened.
assert operation.version == approval.version assert refreshed_facts_within_approval() acquire_commit_lease(operation_id) submit(provider_key = operation_id)
A timeout after submission creates an unknown state. Query by provider reference or idempotency key before another submit. Search for an authoritative order, payment, or reservation. If reliable lookup is impossible, escalate rather than guessing.
Provider acceptance may not equal completion. Confirm reservation or order status, amount, date, recipient, and duplicate count. For multi-effect workflows, define which combinations are complete and which require compensation or review.
outcome = provider.lookup(operation_id) assert outcome.count == 1 assert outcome.amount <= approval.max_amount mark_verified(outcome.reference)
Store intent version, approval, attempts, provider references, refreshed facts, verification, status, and user notification. Send a concise message with outcome, cost, cancellation details, exceptions, and follow-up. If abandoned, state what did and did not happen.
A retry may repeat a request, but it must never duplicate the user's intent, exceed the approved boundary, or claim success without verification.
| Test | Injection | Expected behavior | Evidence |
|---|---|---|---|
| Lost response | Drop response after provider acceptance | Operation becomes unknown and reconciles before resubmit | One provider object and lookup call |
| Duplicate approval | Deliver the same approval twice | Second delivery returns existing status | One commit lease and side effect |
| Worker crash | Terminate after submit, before local update | Replacement queries provider and verifies | Persisted request identity |
| Stale price | Increase total after approval | Old approval invalidates; refreshed packet issued | Version mismatch and no commit |
| Expired session | Invalidate browser auth at commit | Task pauses without losing preparation | Checkpoint retained |
| Concurrent workers | Start two commit attempts | Only one owns commit; other observes | Lease history |
| Provider retry | Return transient 500 responses | Backoff retains the provider key | One external object |
| Changed intent | User changes date after approval | New version and approval required | Supersession chain |
| Partial success | Payment succeeds, booking fails | Compensation or human-review state | Refund or escalation receipt |
| Notification failure | Drop final message delivery | Outcome stays verified; message retries separately | One purchase, multiple message attempts |
Human response time makes price, availability, and session state volatile. Separate approval from commit, version the packet, and refresh immediately before execution.
See the text-message assistantBrowser navigation can hide whether a click succeeded. Checkpoint before consequential steps and verify through provider records or refreshed state before clicking again.
Explore computer-use cacheA timed-out publish can create duplicates. Give the release a stable identity, query deployment state, and separate artifact generation from public action.
Explore agent-built websitesWhen certainty is impossible, preserve a task receipt, expose the blocker, and escalate rather than using model confidence as proof.
Learn about SuperIt is a client-provided identity that lets a supporting server recognize repeated attempts for the same operation and return the existing result instead of creating another object. The application must still define intent identity, persist the key, handle conflicts, and verify the outcome.
A prompt can reinforce behavior but cannot replace transaction controls. Duplicate prevention belongs in structured state, storage constraints, commit leases, provider idempotency, reconciliation, and verification. The model may recommend retry; the execution layer decides whether it is allowed.
No. Reads, reversible edits, and consequential side effects have different risks. Reads may retry automatically. Charges, orders, bookings, deletion, publication, or messages require stable identity, duplicate prevention, and often refreshed approval.
Prefer one that does for consequential operations. Otherwise persist an application operation ID before submission, serialize commits, use provider lookup and unique business keys, and escalate uncertain outcomes. Do not claim strong retry safety when external state cannot be reconciled.
Failures can occur at inconvenient moments, so practical systems design for repeated attempts plus deduplication and reconciliation. The useful promise is that one user intent produces at most one accepted effect, or enters an explicit unknown state before further action.
The message identifies the exact action, destination, details, amount or maximum, and expiration. The reply maps to an authenticated user and current version. If price or availability changes, issue a new packet. Higher-risk actions may require authenticated web confirmation.
Include operation and version, approved boundary, provider reference, amount, details, verification time, relevant attempts, exceptions, and notification status. Keep it concise for users, link richer technical evidence for authorized operators, and exclude secrets.
A concrete provider implementation of client keys, repeated request behavior, parameter comparison, and key lifecycle.
Workflow-engine documentation for retry intervals, backoff, maximum attempts, non-retryable errors, and timeouts.
Guidance for action-specific authorization, contextual data, server-side enforcement, and protected authorization flows.
Controls for secret storage, lifecycle, access, auditing, rotation, and limiting exposure.
These sources describe provider idempotency, workflow retries, transaction authorization, and secrets. The end-to-end agent architecture, approval packet, and tests are an applied synthesis for purchase and booking agents.
Super brings personal AI work into the message thread while connecting it to broader computer-use tasks, approvals, and outcomes.
Explore Super