Setting up an AI agent for one hotel task: data, permitted actions and a person who approves

An AI agent is software that works toward a goal in steps and uses your systems to do it. Setting one up for a hotel is mostly writing, not code: one task, the data it may read, the actions it may take, who approves each, plain instructions, a test set and an off switch.

A general manager asks for an AI agent, and the first quote that arrives is a developer's plan for an integration project. The part that decides whether the agent is useful or dangerous is not in that plan. It is a one-page sheet naming the task, the fields it may read, the three things it may do and the person who signs off. This article is that sheet: after reading it, you will be able to write the setup for one hotel task, test it, and know exactly when a person stays in the loop.

What is an AI agent, and what does it mean in a hotel?#

An AI agent is software that is given a goal, takes steps toward it and uses the hotel's systems along the way, instead of answering one question and stopping. In a hotel the useful version is narrow: one task, one owner, one result a person can check.

The difference from a chatbot is the outcome, not the conversation. A chatbot returns text; an agent returns a finished piece of work, and to get there it reads records and calls actions. The loop, in plain words: read the data, decide the next step, take it, look at the result, repeat until the finish line or until it must ask a person.

The value comes from the steps it takes without being asked, not from the absence of a person. An agent with no approver is not more advanced, it is less controlled. Before anything is connected, four things are written down: the task, the data it may read, the actions it may take, and the person who approves each action. Everything else is detail.

This is a writing job before it is a technical job. The hotel knows the task and the exceptions; a developer or vendor knows the connection. The setup sheet belongs to the hotel. If you are new to the vocabulary, start with a plain-word glossary of agents, assistants and chatbots.

One point that saves confusion later: you are not training a model on your property. The agent works from the instructions you write and the data it reads at the moment of the task. That is why the instructions and the data list carry so much weight.

Which hotel task should you give an agent first?#

Pick a task that repeats, has a clear end, already has a named owner and produces a result someone can check by hand in a few minutes.

Run four tests, in order. Does it repeat often enough to be worth setting up? Does it end with something concrete? Can a person verify the output quickly? And what happens if it is wrong and nobody notices?

Good first tasks live close to the front desk. Checking tomorrow's arrivals for missing details and drafting the messages a receptionist sends. Matching a group's rooming list against the booking. Drafting answers to the five questions guests ask before arrival. For a wider view of the paperwork side, see reservation paperwork tasks suited to AI assistance.

Bad first tasks: pricing, refunds, KBS guest identity notifications, invoices, and anything that reaches a guest without a person reading it first. These are not harder to build. They are harder to survive.

Write the task as one sentence with a finish line. For example: by 16:00, list every arrival tomorrow with a missing passport number or a missing phone number, and draft one message per booking for the front desk to send. Name the owner as a person, not a department, and name the person who checks the output. If those are the same person, say so and accept that the check is weaker.

Describe a wrong output before you start. If you cannot say what wrong looks like, the task is still too vague to hand over.

Is this a good first task?

What data may the agent read?#

The minimum needed to finish the task, from systems the hotel already controls, read-only at first, and listed field by field.

List fields, not systems. "Guest name, arrival date, room type, whether a passport number is on file, whether a phone number is on file" is a data list. "Access to the property management system" is not. Read-only first: an agent that can only read cannot damage a record, which is why the first version of almost every hotel task needs no write access at all.

Personal data sits inside almost every hotel task. In Türkiye a stay involves personal data under KVKK (kişisel verilerin korunması kanunu), so the hotel decides what the agent may see and confirms its own position with a legal adviser. Say how fresh the data must be, too. A list pulled at midnight and used at four in the afternoon produces confident, wrong drafts, and the agent has no way to know it is looking at the past.

Instruct the agent to report "not on file" rather than infer. Missing data is the most common failure in hotel work, and guessing is what turns a gap into a wrong message. Keep the data inside systems the hotel controls, and ask where the processing happens. Do not paste guest exports into a consumer tool because it was quick.

Write the hotel's own facts down separately: check-in time, policies, what the hotel does and does not offer. Without them the agent fills the gap from general knowledge, which is how an invented promise reaches a guest. A hotel fact sheet written for AI assistants is the natural companion to this step.

What may the agent do, and what always waits for a person?#

Split every action into three tiers: read, draft and change. Start with read and draft only; a change waits for a person, and money, fiscal documents, KBS notifications and guest messages always do.

Read has no side effects and needs no approver, only a log. Draft produces something a person sends or approves, so a wrong draft costs a correction rather than an incident. Change writes to a record: allow only reversible changes, and only after the log and the undo path have been tested on real cases.

Some steps always keep a person in the loop. In Türkiye every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK). These are the steps where a mistake is not repaired by an apology.

The agent must never be able to approve its own action. Where staffing allows, the approver is a different person from the one who wrote the instructions. One approval for most changes, two for the most sensitive; two approvals only work if the second person actually reads the output, so keep that list short.

Decide this on paper, action by action, before the first connection is built. A list written afterwards describes what the system already does, not what the hotel decided.

For a deeper treatment of the approval question, see which hotel AI actions need a person to approve them.

How do you write the instructions?#

Write them as a job description a new receptionist could follow: the goal, the finish line, the fields to use, the fields to ignore, and what to do when something is missing.

A workable order is this. Goal in one sentence. Inputs by field name. Steps in order. The finish line. What to do when unsure. The tone and length of drafts. What must never appear in a draft, such as prices that are not on file, promises, or identity details.

Attach the hotel's facts to the instructions rather than trusting general knowledge. Opening hours, check-in time, what is included in the rate and what is not, belong in writing, dated. Keep the whole thing short enough that a person can read it aloud in two minutes. Long instructions hide contradictions, and a contradiction is where the agent chooses for you.

Version and date it. When a policy changes, the instruction changes the same day, or the agent keeps applying last season's rule with perfect confidence. And delete advice like "be helpful" or "use good judgment". Write the actual rule, because the agent cannot infer which of two good intentions the hotel prefers.

How do you test it before real use?#

Run it on the hotel's own past cases where the right answer is already known, score the output by hand, and write the pass line down before you look at the results.

Build the set from last month's real work. For example, twenty to thirty cases taken from actual bookings is enough to start, and they must come from the hotel, not from a demo. Include the traps on purpose: a booking with no passport number, a duplicate reservation, a group whose rooming list does not match the block, a returning guest, a name the system handles badly.

Score three outcomes, not two: right, wrong, and asked a person. Asking is a correct result, and a set that punishes it teaches the agent to guess.

Run a shadow period: the agent produces the output, a person does the real work as usual, and someone compares the two. Fix the instructions, not the test. Set the pass line first, in writing. For example: no output that would have reached a guest with a wrong fact, and no invented detail. Then measure against it. Keep the set: it becomes the regression test every time the instructions change, and it is the only evidence the hotel will have that a change did not break the task. The full method is in how to test a hotel AI assistant before staff or guests use it.

What do you log, and how do you switch it off?#

Log every step: what the agent read, what it decided, what it produced and who approved it. Then make sure a duty manager can stop the task without calling anyone.

The log holds the time, the task, the inputs used, the output, the approver and the outcome. That is enough to answer "why did this message go out" a week later. The log belongs to the hotel, not to the vendor. If it cannot be read without a support ticket, it is not a log the hotel owns.

Review weekly: read a sample of outputs, count the corrections, and look for the same mistake twice. A repeated mistake is an instruction problem, not a model problem. The weekly review checklist for a hotel AI assistant covers this in detail.

One off switch, named in the document, tested before day one, reachable by the duty manager at two in the morning. A switch that needs a developer is not an off switch. Know which actions can be undone: a note on a reservation can be removed; a message already sent to a guest cannot, which is why that step stays with a person. Decide what happens when the agent stops mid-task: the person takes over and the task does not wait. Write that down before it happens at a busy check-in.

What to do next#

Write the one-page setup sheet this week for a single task, and take it to the person who already does that task by hand. The sheet holds: the task in one sentence with a finish line, the fields the agent may read, the actions with their tiers, the named approver, the instructions, the test set, the log and the off switch.

The pieces fit in one order. The task decides the data, the data decides the actions, the actions decide who approves, and the test set decides whether any of it goes near a guest. Everything after that is review.

For reference, AI Otel's PMS assistant is built: it answers questions about a hotel's own property in plain language, carries out routine actions, and a person confirms anything sensitive. It is working software, ahead of launch. If you want to see how this structure looks in a real system, request a briefing.