The Travel Agent Charged the Card, Then Lost the Booking

The consequential moment in this evaluation came after the booking site displayed a confirmation. The agent had already selected the itinerary, submitted the traveler and payment details, and received evidence that the reservation existed. Its remaining jobs were administrative: save the confirmation, email the itinerary, and add the trip to the calendar.

That is where the workflow stopped.

This was not a failed purchase. It was a successful purchase followed by a failed orchestration run, which is harder to recover from because the agent’s internal state no longer matches the outside world. The booking system knows there is a reservation. The card issuer may show an authorization, a temporary hold that precedes settlement.

The email inbox and calendar contain nothing useful. The agent sees an interrupted browser session and must decide whether to continue, investigate, or start over.

Starting over is the dangerous option. A general retry policy may treat the interrupted run like any other failed software operation and repeat it from the last recorded checkpoint. If that checkpoint sits before the purchase, the agent can buy the same trip twice.

The agent lost state after the irreversible step

The run followed a familiar tool sequence. The agent read a calendar to identify acceptable travel times, searched through a browser, selected a reservation within the configured spending limit, and paused for payment approval. After approval, it entered the payment details and submitted the booking.

The failure occurred between the external confirmation and the agent’s durable record of that confirmation. A durable record survives a crashed process or expired browser session, unlike text held only in the model’s current context. The agent had seen the result, but the orchestration layer had not committed the reservation identifier and completion status before moving toward the itinerary tasks.

That narrow gap matters more than the model’s ability to read a booking page. Once money has moved, recovery depends on transaction state, not on another round of language-model reasoning. The agent needs to establish whether the previous action succeeded before it considers repeating the action, even if the browser returned an error or the final page is no longer available.

In the test run, the useful recovery path began with read-only checks. The agent reopened the booking provider’s trip-management page, searched the connected inbox for a confirmation, and compared the traveler, route, and travel window against the original request. Those checks added delay, and none was individually conclusive, but together they established that the reservation existed and that another purchase was unnecessary.

A card authorization alone would not have been enough. An authorization can appear for an attempt that the merchant later reverses, while a booking confirmation without matching traveler and itinerary details could belong to a different trip. Recovery needs several fields, including the provider’s reservation identifier, rather than a vague signal that a charge appeared.

Idempotency has to begin before the click

The primary safeguard is idempotency, which means repeating an operation with the same identifier produces no additional effect. Payment APIs often support an idempotency key supplied by the caller. If a request times out after the provider accepts it, the caller resends the same key and receives the existing result instead of creating another charge.

Browser bookings rarely expose that control. The agent clicks the same button a person would, and the website decides whether two submissions are duplicates. Similar traveler details do not make the operation idempotent. Neither does instructing the model to avoid duplicate bookings, because the model cannot enforce behavior inside the merchant’s transaction system.

The orchestrator can still reduce the risk. Before submission, it should write an operation record containing a stable run identifier, the selected itinerary, the expected price or permitted range, the traveler, and the fact that purchase approval was granted. After submission, it should attach the provider’s confirmation identifier to that same record. If the second write never happens, the unresolved operation remains visible as an uncertain purchase rather than reverting to an unstarted task.

The purchase is not the only action that needs this treatment. Calendar creation should use a stable event identifier or search for an existing event with the same reservation reference before writing another. Email delivery should record the message identifier and check sent mail before resending. A duplicate itinerary email is mostly irritating; a duplicate calendar event can cause later agents to misread availability, so both follow-up tools need replay protection even though their financial stakes differ.

The test failure at the confirmation boundary kept returning as the design test: if the orchestrator runs this exact step again, what outside effect can happen twice? A step that cannot answer that question should not sit behind an automatic retry.

Reconciliation comes before recovery

A retry policy based only on error types is too shallow for this workflow. A browser timeout says the browser stopped waiting. It does not say the reservation failed. The same distinction applies to a disconnected payment tool, an expired authentication session, or a model response that ends before the agent stores the page contents.

The recovery controller needs a state machine, a fixed set of workflow states and permitted transitions, rather than a loose instruction to finish the trip. The relevant state after this failure is not “booking failed.” It is “purchase outcome unknown.” From there, the system should permit provider lookup, inbox search, card-status inspection, and escalation.

It should block another purchase.

Reconciliation is the work of comparing the agent’s record with the systems that performed the real actions. In this case, the strongest evidence was a provider confirmation that matched the requested trip. Once the agent attached that record to the interrupted run, it could resume the lower-risk tasks without asking the user to approve each one again.

There is a cost. Reconciliation adds tool calls and makes successful runs slightly slower when the system performs verification routinely. It also requires connectors that can retrieve existing bookings, not merely create them, plus logs that preserve submitted fields without exposing full payment credentials. A browser-only agent with no structured booking lookup has a weaker recovery path and will hand more cases to a person.

That tradeoff is reasonable. The alternative saves a little time during ordinary runs by making the rare uncertain run expensive, confusing, and potentially chargeable twice.

Human approval belongs at changes in liability

Approval before the first purchase did not authorize every possible recovery action. It covered one itinerary under the user’s stated constraints. It did not cover a second booking, a higher replacement fare, a cancellation with a penalty, or accepting travel credit instead of a refund.

Those actions change the user’s financial position and should interrupt automation. If reconciliation finds no reservation but a card authorization remains, the agent should present the evidence and wait rather than infer that another purchase is safe. If it finds two reservations, it should not choose which one to cancel unless the user has supplied a specific duplicate-resolution policy and the cancellation terms are unambiguous.

Human review also belongs where identity is uncertain. A confirmation email with a similar route but a different traveler is not permission to attach that booking to the run. Nor should an agent use a partial card match as proof when several people share a travel account.

The safe automatic portion is narrower. After confirming the one intended reservation, the agent may send the itinerary, create the calendar event, and mark the workflow complete, provided those writes carry their own stable identifiers and can be checked before replay. The failed step-four run then finishes without another purchase attempt.

The practical adoption test is therefore not whether an agent can navigate a travel site. It is whether the orchestration layer preserves intent before the charge, records the external result after it, and treats the gap between those writes as a distinct operational state. Without that machinery, browser, email, calendar, and payment access increase the number of places where an uncertain outcome can cause another side effect.

Questions people ask

Can an

AI agent retry a travel booking after a browser error?

Only after it determines that the first attempt did not create a reservation or charge. A browser error reports what happened to the browser session, not what happened inside the booking system, so the agent should reconcile provider records, email, and payment status before another purchase.

Which travel-agent actions need idempotency?

Purchases, payment submissions, cancellations, refunds, itinerary emails, and calendar writes all need duplicate protection. The financial actions carry the largest downside, but repeated calendar and email actions can corrupt later workflow state or cause the agent to treat an existing trip as a new one.

When should the agent ask for human approval again?

It should pause before a second charge, a replacement at a changed price, a cancellation with uncertain terms, or any choice between refund and credit. The original approval covers the original transaction, not every financial action an agent might attempt while repairing the workflow.

Is a card charge proof that the reservation succeeded?

No. A pending authorization may later disappear, and it may not identify the final booking clearly. The agent should look for a matching provider confirmation and reservation identifier, then compare the traveler and itinerary with the approved request before it resumes the workflow.