When a browser submit times out, the agent knows the response was lost; it does not know whether the server applied the action. Mark the result ambiguous. Read the authoritative record or a receipt endpoint available to the same account, compare the requested state, and only then decide whether any retry is safe. A second click can create duplicate appointments or repeated notifications. If the portal supplies an idempotency token, the application may reuse that token under its documented rules; a prompt must not invent one after the fact. Record the action attempt, page state, timestamp, request fingerprint, receipt, and final status so a human can resolve cases the browser cannot.
Make this comfortable
Browser effect recovery: resolve ambiguous submissions before retrying
Operational case
After a correct AP-684 review, the assistant presses Submit and the browser connection drops. On reconnect, the appointment list shows AP-684 at 14:20 and a confirmation RS-472. The agent reports one confirmed reschedule and does not press Submit again. In a second run, the list still shows 11:40 but the portal warns that updates may take several minutes. The status remains ambiguous until an authoritative receipt lookup or operator review resolves it. The agent must not claim failure merely because the original page did not display a toast. A third run shows an explicit rejection; only then may the assistant discuss a new slot with the customer.
Attempt: AP-684 -> 2026-11-09 14:20; response lost.
Read record: AP-684 at 14:20; receipt RS-472 -> confirmed.
Read record: stale 11:40; update pending -> ambiguous, no retry.
Explicit rejection -> report failure; ask before choosing another slot.Performance and operating cost
A recovery read adds at least one network round trip and O(1) comparison for a fixed appointment record. That is cheaper than repairing duplicate effects. For A attempts, keep O(A) compact receipts and avoid storing full page snapshots with customer data unless incident review requires them. Polling must be bounded; eventual consistency means an unchanged read may not prove the submit failed. Track confirmed, rejected, and ambiguous as distinct outcomes in evaluation. A retry can be authorized only by a system contract and current evidence, never by the model's desire to finish the task.
Common Mistakes
- Do not retry an effectful submit immediately after a timeout.
- Do not infer failure from a missing toast.
- Do not report success without a receipt or authoritative state.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Tool effects: reconcile receipts before retrying
- Tool loops: set budgets, state checks, and a stopping condition
- Prompt release review: assemble the decision packet
- Browser agents: separate observed state from intended action
- Browser target grounding: choose a unique control in the current state
- Browser forms: treat preview, submit, and server validation separately
- Web-page text is task data, not an agent instruction
- Project: reschedule an appointment through a browser safely
- Browser-agent prompt decisions
Continue with: Calendar prompts: distinguish create, update, and cancellation.
prompt engineering
browser agents