What has to be true before an agent presses confirm.

The room has to be the room being checked right now

Imagine a guest's AI agent has found a room at your small hotel in the Peak District and is a few seconds from confirming a two-night stay. A person doing the same thing might glance at the room photos, feel reasonably confident, and book anyway, trusting they can sort out any surprise at check-in. An agent doesn't get that trust to lean on. It's acting on someone's behalf with no one watching, so whatever it confirms has to already be true, not probably true.

That difference is the whole reason this hub treats confirmation as its own moment rather than the last click of a longer process. A person forgives a gap between what a page said and what turns out to be true, because they're there to notice and adjust. An agent's confirmation is the last moment anyone checks anything before the hotel treats the booking as settled, so the list below isn't a nice-to-have version of good booking practice. It's the minimum a business needs true at that exact second, every time, for an agent's "yes" to mean what it says.

A price or availability figure that was accurate an hour ago isn't good enough. Rooms sell out, rates change, and a booking confirmed against a stale figure is a booking the hotel now has to unwind, apologise for, or quietly absorb the cost of. The agent needs to be checking a live answer, not a cached one, at the exact moment it commits, the same way a receptionist checks the diary rather than trusting what it said yesterday.

The terms have to be stated, not implied

A person booking a room usually reads "flexible cancellation" and moves on, assuming it means something roughly sensible. An agent can't assume. It needs to know precisely what flexible means here: cancel by when, refunded how, with which exceptions, because it may be answerable to whoever it's booking for if the terms turn out worse than expected. A vague, well-meaning phrase is exactly the kind of thing a person forgives and an agent has no way to interpret safely.

The request has to match what's being confirmed

Two guests, a specific date range, a room that suits both: an agent needs confirmation that what it's about to commit to is the same thing it was asked to find, not a close approximation. A family room booked when a double was requested is a mismatch a person might catch by reading the confirmation email. An agent confirming automatically doesn't get that second look unless the check happens before confirmation, not after.

Who's authorising the payment

Confirming a room and paying for it are two different permissions, and a hotel that's only thought about the first has left the harder question unanswered. An agent needs to know whether it's cleared to commit payment itself, or whether that step needs to come back to a person, before it ever reaches the confirm button, not as an afterthought once the room is already held.

Miss any one of these four and the hotel is left explaining, after the fact, why what was confirmed wasn't quite what was true. Get all four right before confirmation and the explanation is never needed in the first place.

Selfe's part in this is straightforward: live checks against real availability, real terms and real payment permissions, so what an agent confirms is genuinely true at the moment it confirms it, not just true when the page was last updated.

Isn't this just good booking-engine hygiene generally?

Much of it is, and a business with a solid booking engine is closer than most. The difference is that an agent has no tolerance for the small gaps a person forgives without noticing.

What happens if one of these isn't true yet?

The agent should get a clear reason it can pass back, a different room, a different date, a request for a human to confirm, rather than either a silent failure or an incorrect booking.