An agent that books travel

Lay the four tools out by what a wrong call costs.

search_flights and get_policy are reads. A wrong call returns wrong information, which the model may act on, but nothing in the world changes. These can be called freely, retried freely, and logged.

hold_seat changes state, but reversibly, and airlines expect holds to lapse. It should be idempotent — the model will call it twice occasionally, because that is how loops behave — so a second identical call must return the existing hold rather than making another.

charge_card is irreversible. Money moves, and unwinding it involves a refund, a customer, and a story. This is the row where the entire design concentrates.

That sorting is the design. The model has the same capability across all four rows; the machinery around each row is what differs.

The model never executes anything. It emits a tool call — a name and arguments — and your code decides whether to comply. That boundary is where every control goes.

For the read tools: rate limits and logging. For the hold: an idempotency key derived from user, flight and date, so duplicates collapse. For the charge: a Guardrail in code that applies whatever the model said — amount under the policy limit, itinerary matches the approved hold, and above a threshold, a human confirms before anything is charged. Not a sentence in the prompt asking the model to be careful; a check the model cannot argue with.

The reason to be strict is prompt injection. The policy document, the airline's fare rules, a previous tool result — any of them could contain text that reads as an instruction, and the model cannot reliably tell. If the charge tool trusts the model's arguments, a line in a fare-rules page can spend the company's money. If it checks them against the user's permissions and the approved hold, it cannot.