Chat, Workflow, Agent or Orchestration: What Does Your Hotel Actually Need?

A few months ago, I wrote about the AI agent trap, the tendency in our industry to buy sophisticated agents that cannot see past the vendor ecosystem they were built in. Since then, one practical question has kept coming up: fine, orchestration matters, but how do hotel leaders actually decide what to build, buy or ignore?

The answer starts with something more basic. Not every problem needs an agent.

The uncomfortable truth is that our industry has compressed four very different things into a single word. When a vendor says "agent" today, they might mean a website chatbot answering breakfast hours, a scripted email sequence that runs before every arrival, a genuinely autonomous system that decides whether to grant a late checkout, or a governed layer that coordinates all of those at once across a portfolio. These are not the same product. They do not carry the same cost. And they do not fail in the same way.

Before signing anything, it is worth stopping and asking a simpler question. What mode of AI does this problem actually need?

Four modes, plainly

The first mode is chat. At its simplest, a question comes in and an answer comes back. Chat may retrieve information, including live information, but it does not independently decide what actions to take across operational systems. A guest asks about the spa hours; the model replies. Chat is the cheapest and most predictable option we have. It also has the smallest blast radius when it goes wrong, because "wrong" means the answer was off, not that we accidentally moved someone's reservation.

The second mode is workflow. A pre-defined sequence of steps that runs the same way every time. A pre-arrival email. A review response drafted for staff approval. An invoice that gets read overnight and posted into the PMS. A workflow may use an LLM inside one of the steps, but the shape of what happens is fixed in code by a human. Anthropic's engineering team, in their Building Effective Agents guide, put it plainly: workflows trade some flexibility for predictability, bounded cost, and reliability. In hospitality, most of what we actually want is a workflow. We have just been sold something else.

The third mode is agent. An LLM that decides the path at runtime. It reads live data, reasons about it, chooses which tools to use, can evaluate intermediate results and adjust its approach, and hands back to a human when it cannot finish. An agent that handles a late-checkout request checks the reservation, checks tomorrow's occupancy, checks the housekeeping schedule, applies policy, and either grants, denies, or escalates. Agents earn their keep when the path genuinely cannot be flowcharted in advance. OpenAI's own practical guide is direct about this. Build one only when decision logic is complex, rules are hard to maintain, or unstructured data has to be reasoned about. Everything else is a workflow wearing a more expensive costume.

The fourth mode is orchestration. Multiple agents and workflows working together, coordinated by a governed layer, with clear handoffs to humans. This is the layer I wrote about in the previous piece. It is the level at which a guest-facing agent that resolves a late arrival talks to a staff copilot that reroutes housekeeping, and both are visible to a management view that a general manager actually trusts. The point is that no single agent completes the job. A layer above them coordinates the work, manages the handoffs and provides the governance.

The decision matrix

Two axes decide most cases. First, can you draw the path on a whiteboard before the interaction starts? Second, how many systems must the answer touch, one or many? Populate the four quadrants with hospitality examples and the argument makes itself.

The interesting quadrant is the upper right, not the lower right. Most hotel work is a workflow dressed up as an agent problem. Pre-arrival messages, review responses, standard reporting, night audit checks, invoice posting, these are workflows. They will beat any agent on cost, latency, and reliability, because their shape does not change from run to run. The mistake is not that hotels do not buy enough agents. The mistake is that they buy agents for problems that were always workflows, and pay for autonomy they never needed.

The lower right quadrant, orchestration, is the one hospitality genuinely under-invests in, and it is under-invested for a good reason. It is hard. It requires the underlying systems to talk to each other. It requires someone to own governance, escalation, and rollback. It requires a written answer to the question of who is accountable when the automated decision was wrong. Fixing the integration between PMS, CRS, POS, CRM, housekeeping, and revenue is not an AI project. It is an infrastructure project. AI without that plumbing is a chatbot with a larger vocabulary.

Three questions before you sign

Can you flowchart the happy path? If yes, you are looking at a workflow. Insist on that. A workflow with a good approval interface will outperform an agent for anything routine, because you can inspect it, audit it, and change it without retraining a model. You will also know exactly what it costs to run, every month, without surprises.

How many systems must the answer touch? One system usually means chat or a simple workflow. Two or three suggest a workflow with a light agent inside. Once resolution spans several operational systems, particularly where actions have material consequences, you are moving into orchestration territory whether the vendor calls it that or not. And orchestration is a governance conversation before it is a technology conversation.

What is the cost of a wrong action? If wrong means the answer was slightly off, a chatbot's mistake is cheap. If wrong means we comped a night we should not have, moved a VIP, or told a guest something that is not true about their booking, the mode does not matter. You need a human in the loop with real authority to override, and a written record of who did what and when. A recent Hospitality Net piece, The Wrong Questions, put it bluntly: for every automated decision, someone should be able to say who owns it, who catches it when it drifts, and how many minutes it takes to reach that person. If you cannot answer those questions, you are not ready for autonomy, regardless of what the demo showed.

A rule of thumb, if you want one

These are not hard technical thresholds, but as a practical rule of thumb, I use something like this:

• If less than 20% of cases need real judgment, build a workflow.

• If 20 to 50% of cases need judgment and they touch one or two systems, a single agent with tight guardrails is defensible.

• If more than half need judgment, or if resolution spans several systems with material consequences, you are in orchestration territory. Do not buy an agent for it. Buy the coordination layer, the human-approval gates, and the audit trail first.

The pattern most hotels find works is boring on purpose. Start with a workflow that saves a measurable number of hours or recovers a measurable amount of revenue. Prove it. Only then reach for autonomy where the path genuinely varies. Autonomy is a premium feature. Buy the premium when you need it.

Buy the Simplest Thing That Works

The uncomfortable truth about the chatbot-versus-agent debate that has filled our trade press for two years is that it has skipped the two options in the middle. Chatbots are being retired because they answer without acting. Agents are being over-bought because they act without governance. Between them sits the boring, well-understood territory of workflows, and above them sits the governed orchestration layer where hospitality's real operational leverage is going to accrue.

The next generation of hotel AI will not be decided by which agent is smartest. It will be decided by which operators are disciplined enough to buy the simplest thing that works, and honest enough about their own systems to know when orchestration is a plumbing problem, not a model problem.

Start simple. Prove value on one workflow. Add autonomy only when the path cannot be drawn. Add orchestration only when your systems can actually talk to each other and when governance is written down somewhere a new hire could find it. Everything else is buying capability you cannot yet operate.