Ask Abu Dhabi: Building a Tourism Chatbot That Doesn't Make Things Up

This is the project I'm on right now at EdgeFirm, working alongside Create in Dubai, and it's probably the one I care most about. The stakes are just different from a typical internal tool. When the thing recommends restaurants, hotels and itineraries to actual visitors, "the AI made something up" isn't a fun bug. It's someone standing outside a closed restaurant at 9pm.

The brief

UAE's Department of Culture and Tourism wanted an assistant that could answer real questions. Where to eat, what to do with kids, how far the Louvre is from a given hotel, build me a two day itinerary around this event. And it had to feel like talking to someone who actually knows the city, not a search bar with a chat bubble stuck on top.

Why we didn't just wire a model to a chat box

That takes a week and produces something useless. The moment the model doesn't have a place in its training data, or the place shut down last year, or a new attraction opened last month, it either says "I don't know" or it confidently invents something. Neither is acceptable when a person is planning their trip around the answer.

So the real work was retrieval. We built a pipeline that pulls content out of Azure Blob Storage, PDFs, documents and structured listings, extracts and chunks it, embeds it into pgvector on top of Postgres, and re-ingests on a schedule so the knowledge base doesn't quietly go stale. When someone asks a question the model isn't answering from memory. It's answering from what we actually gave it, and it has permission to say "I don't have that" rather than guess.

The orchestration layer

We used LangGraph to structure the conversation as a graph instead of one enormous prompt. There's a node that classifies the query so we know whether it's a factual lookup, an itinerary request, or something that needs a distance or directions tool. There's a dedicated node that tests for prompt injection before anything else runs. That last one matters more than people expect. Public facing bots get poked at constantly, and a careless one will hand over its system prompt to the first person who asks nicely.

On top of that the agent gets real tools. Google Maps for distance and routing, an itinerary builder, category filters, moderation. So when someone asks what's near their hotel that works for kids, it isn't guessing geography, it's calling something that knows.

Getting it into an existing website

The trickiest part wasn't the AI, it was the integration. Visit Abu Dhabi runs on a legacy Sitecore and React stack, completely separate from the newer Next.js dashboard we built for managing the bot. I built the chat widget as a self contained embed, with its own state and its own SSE streaming hook, talking to our FastAPI backend directly and never touching the CMS content. That decoupling was deliberate. It means the widget can drop onto other DCT properties without dragging Sitecore along with it.

What I'd tell someone building the same thing

Spend far more time on retrieval and evaluation than on the prompt. The prompt is the easy twenty percent. Getting the right chunks back, keeping the knowledge base current, catching injection attempts, and having real observability into what the model actually did in production, that's the difference between a demo and something a government tourism board will put their name on.