Operators stay in control when agents act, by design rather than by promise. The structure is simple: people decide what the outcome is and where the limits sit; agents work inside permissions and approvals the business has set; every action is traceable. Remove any part of it and autonomy stops being something an operator can trust.
Outcomes and limits are human decisions
An outcome says what the business wants. A limit says what it will not accept on the way there. Both carry judgment about the property: its guests, its standards and how much risk it is willing to take. We do not think any of that can be read safely from data, which is why both decisions stay with people.
Suppose, as an illustration, the outcome is to fill the remaining rooms on a quiet weekend. The limits keep that pursuit within bounds: a lowest rate the hotel will accept and promises to guests it will not break. An agent can pursue the outcome, but only the business can say where the edges are.
Keep people in control is one of the four principles on our About page. The same page places permissions, human approval and understandable actions inside the product design. We take that literally: control is something we build, the same way we build any other part of the product.
Deciding outcomes and limits is real work that reshapes an operator’s day. What that work involves is the subject of the operator’s new job.
Permissions before autonomy
Permissions come first because they define the space an agent can act in at all. Specialized agents make this easier to express. An agent that works through payments and the ERP needs different permissions from one that works through email and the CRM, so it makes sense to limit each to what its role requires.
Building it the other way around is tempting: give an agent broad access, watch what it does and narrow it after a mistake. That puts the cost of learning on the hotel and its guests. Setting permissions first means the worst case is bounded before the first action instead of discovered after it.
Autonomy, in our view, is the room left inside those permissions. Like the product itself, it should start narrow and widen only when real use gives a clear reason. A system that answers questions and prepares drafts commits the business to nothing until a person decides. That is a sensible place for trust to start.
Approvals where the stakes are
Approvals need to be placed with care. Put none anywhere and the operator has handed over judgment the business never meant to delegate. Put an approval on every step and the operator is back to doing each step personally, which is the copilot model of control rather than one where agents act within set limits.
Approvals belong where an action is hard to undo, speaks for the hotel in public or commits the business in a way a person should own. Elsewhere, well-set limits can do the job. Too many approvals train people to click through them, which is worse than fewer approvals that get real attention. An approval should also be easy to give well, with what will happen and why stated in plain language.
In Guester, review responses are the clearest case. A reply speaks for the hotel in public, so Guester AI prepares a draft and the hotel reviews and approves it.
Every action leaves a trace
Traceability is what makes the rest adjustable. Every action is traceable, so a business can find out whether a limit was too loose, an approval was missing or an outcome was badly phrased. In our view, a trace that shows the action without the reasoning answers only half the question.
A trace also has to be understandable to be useful. A record only an engineer can read does not keep an operator in control.
Traces matter to the whole team, not only the operator. When a department head asks why a booking, a message or a task changed, the answer should be something to look up rather than reconstruct from memory. Shared traces let a team argue about decisions instead of about what happened.
Control does not mean nothing ever goes wrong. It means that when something does, a person can find out what happened, see why and change the limits so it does not happen the same way again.
The result is a different kind of trust. Operators are not asked to trust that an agent is clever. They are asked to trust a structure they set up themselves: outcomes they defined, limits they chose, approvals they placed and a trace they can read.
