How I Automated 100+ Hours a Month for Two Boutique Hotels

Two boutique properties, 24 rooms each, in Bareilly and Ramnagar. Before this system existed, that meant a front desk fielding the same three questions on repeat — is a room free tonight, what's the rate, can I get the confirmation resent — while also trying to remember which returning guest wanted the corner room last time and which one asked for an extra pillow. None of that is hard. All of it is relentless, and it doesn't stop at 11pm.

The obvious fix is "put a chatbot on it." The actual work was making sure that chatbot never says something false with total confidence — which, if you've used any LLM for more than five minutes, you know is the default failure mode.

Why tool-calling, not just a chat prompt

The first version was a single system prompt describing the hotel's rooms, rates, and policies, fed straight into Gemini. It worked in demos and broke in production, because a general-purpose language model will always answer a question rather than admit it doesn't know — inventing an available room on a night that was actually fully booked isn't a hallucination bug, it's exactly what the model was trained to do.

The fix was building this as a ReAct-style tool-calling agent instead of a free-text chatbot: the model can reason about what it needs, but it's only allowed to state availability, rates, or booking status by actually calling a function that reads the live Supabase table. If the tool call fails or returns nothing, the agent is instructed to say so — not to fill the gap with something plausible.

What the agent actually does

• 01 Booking confirmations, grounded. Every confirmation the agent sends is generated after a real read of room and rate tables — not from a cached description of "what the hotel generally offers."
• 02 Guest memory via RAG, not a static CRM field. Past stays, preferences, and special requests are indexed and retrieved per-guest, so a returning guest gets recognized without a human having to look anything up.
• 03 Telegram alerts only on real thresholds. Occupancy drops, payment delays, anything that actually needs a human decision gets pushed instantly. Everything else — the routine 90% of guest interactions — never reaches the owner's phone at all.
• 04 A local Ollama fallback for when the cloud isn't there. Gemini 2.0 Flash is the primary reasoning engine, but internet drops happen in tier-2 India on a normal Tuesday. The fallback path keeps basic booking logic running locally instead of the whole system going dark.

The model doesn't need to be smarter to be trustworthy. It needs to be structurally incapable of answering without checking first.

The actual lesson

Most "AI automation" pitches sell the model. The reliability — the thing that actually lets an owner stop checking bookings manually — comes from the boring architecture decisions around the model: what it's allowed to say without a tool call, what happens when a tool call fails, and what triggers a human alert versus what gets handled silently. Gemini 2.0 Flash is fast and cheap enough to run this at scale; the ReAct tool-calling discipline is what makes it safe to actually deploy in a business that depends on it.

That's the same principle behind the schema-drift audit I ran on this same system's database — trust the source of truth, not what the code (or the model) assumes about it.