I spend a lot of time tracking where AI is actually moving in hospitality. Not the press releases - the actual shifts. What vendors are shipping versus relabelling. Which research is worth reading. What operators are starting to ask about that they weren’t asking about last month.
The problem is that the source landscape is fragmented. PhocusWire covers hotels and travel. Restaurant Dive covers restaurants. BCG and Deloitte publish substantive research but irregularly. Mews and Toast blog at length but they’re vendors with positions to defend. Hacker News occasionally surfaces something useful but it’s noisy. Reading all of this daily is impractical. Missing it means writing about AI in hospitality from outdated assumptions.
A few weeks ago I built a tool to do the gathering for me. A scheduled Claude agent that scans a defined source list, clusters what it finds by theme, flags genuine AI capability versus rebadged features, and publishes a briefing to a public site three times a week. The site is at briefings.inverisla.com. It now costs about ten dollars a month to run. The story of getting there is more interesting than the tool itself, because most of it is about constraints - and constraints are the thing operators and executives most consistently misjudge about AI.
The first version ran daily and cost about fifty dollars a month. The output was fine but the cost was not, given that I’m one person reading one briefing. Worse, the briefings were hotel-heavy because the source list I’d given it skewed that way - in the prompt I’d described what I read, but at that point in time I read more hotel coverage than restaurant coverage, and the agent was just reflecting that back at me. It was working as designed. It just wasn’t producing what I needed.
The first improvement was structural - I cut the frequency to Monday, Wednesday, Friday. Hospitality tech doesn’t move daily - though it’s moving faster than it used to - and forcing a daily briefing meant some editions got padded with thin material. Three times a week with a two-or-three-day lookback produces denser, better briefings and costs sixty percent of the daily run rate. The lesson here was generalisable: AI tools don’t earn their keep by running constantly. They earn it by producing useful output at the right cadence for the problem.
The second improvement was about source balance and prompt discipline. I rebalanced the source list explicitly toward restaurant coverage to match my actual audience, and I tightened the prompt to force a single research pass - one round of searches, one round of fetches, then write. The original prompt let the agent iterate, which sounds intelligent but mostly just compounded cost. Agent loops are expensive precisely because they keep re-reading their accumulated context on every turn. Constraining them to one pass changes the economics significantly.
The third improvement was operational and this is where it got interesting. The tightened agent obediently completed one search round and one fetch round. Then it hit a rate limit and died, leaving me with a charge of about a dollar for no output. The diagnosis took a minute. I was on the lowest API tier, which caps how many tokens per minute can flow through. Twelve articles fetched in parallel produced enough accumulated context that the final synthesis call exceeded the per-minute ceiling. The agent was behaving perfectly. The infrastructure underneath it was the bottleneck.
Top up the account, move to the next tier, problem disappears. The cost per run is now around seventy-five cents. The site updates on schedule, though not perfectly - stories sometimes appear in two consecutive editions when the news cycle hasn’t moved on, and the agent doesn’t yet track what it’s already covered. That’s the next thing to fix. The briefings have improved markedly with the rebalanced sources.
So what does any of this matter to a hospitality operator or executive looking at AI?
A few things, I think.
The cost story is the most important. The first version cost five times what the current version costs and produced worse output. Every iteration improved both. This is what applying AI in operational contexts actually looks like - not “deploy the tool and reap the rewards” but a sequence of small adjustments where you learn what the tool is actually doing, where it’s wasteful, where its defaults are wrong for your context. Vendors selling AI features into your business have an incentive not to mention this part. The default configuration is rarely the right configuration.
The architectural choice matters too. I could have built this as a deterministic pipeline - a Python script pulls articles from a defined source list, hands a structured input to a single Claude API call, writes the output. That would be cheaper still, probably two dollars a month rather than ten, and would avoid the rate limit issue entirely because there’s exactly one inference per run. I haven’t done that yet because the agent version works and the marginal saving isn’t worth the engineering time right now. But the question - agent loop versus pipeline - is one operators will increasingly face. Agents are convenient when the path is genuinely non-deterministic and decisions need to be made mid-flight. They’re wasteful when the job is mechanical and predictable. Most of what operators are sold as “AI agents” is actually pipeline work in agent clothing, priced accordingly.
The rate limit story matters because it’s the kind of thing nobody mentions in a vendor demo. Real AI systems have real constraints. The cost of running them isn’t just the model price per token - it’s the per-minute ceiling, the failure modes, the silent failures where you pay for inputs and get no output. None of this means AI tools aren’t useful. They are, demonstrably. But the gap between the demo and the operational reality is wide, and operators who’ve never built anything themselves don’t always know where the gap sits.
The tool itself is at briefings.inverisla.com. The briefings are public. Use them, critique them, suggest sources I’ve missed, ignore them as you prefer. I’d genuinely value the feedback. The source code for the workflow is in a public GitHub repo if you want to look at the underlying architecture. There’s nothing especially clever about it. The interesting part is what it took to make it cheap and reliable, not the construction.
If you’re a hospitality operator wondering how to start applying AI in your own business, the most useful thing you can do is build something small yourself. Anything, really. Pay attention to what surprises you. The surprises are where the operational knowledge lives. People who’ve built or shipped something have a different relationship with AI vendor claims than people who’ve only been pitched to.