Your Customers Don't Write in One Language

Here is a real message shape that arrives in a Dubai salon's WhatsApp inbox:

"hi 7abibti do u have slot for hair color 2day evening? kam el price"

Three languages, two scripts, one of them written in Latin characters with numerals standing in for Arabic letters. No punctuation. A price question embedded at the end.

A generic AI agent built for an English-speaking market will handle roughly half of that message and confidently answer the wrong part of it. This is not an edge case — in our experience it is closer to the median for consumer messaging in this market.

The UAE is one of the most digitally saturated countries in the world. DataReportal's Digital 2026 report puts internet penetration at 99.0% with 11.3 million users at the end of 2025, 12.5 million social media identities — around 110% of the population — and 23.0 million active cellular connections, roughly 202% of the population. Almost everyone is reachable, almost everyone is on messaging, and very few of them are having a monolingual conversation.

Below is what we've found actually has to be handled, and why most of it is a runtime problem rather than a model problem.

---

1. Code-switching is the default, not the exception

The UAE's resident population is overwhelmingly expatriate, and the working languages reflect that: English as the lingua franca, Arabic across multiple dialects, and substantial communities speaking Hindi, Urdu, Malayalam, Tamil, Tagalog, Bengali, Russian and Farsi.

What this produces in practice:

• Intra-sentence switching. A single message shifts language mid-clause. Language detection at the message level returns one answer where the correct answer is two.
• Arabizi / Franco-Arabic. Arabic written in Latin script with digits substituting for letters that have no Latin equivalent — 3 for ع, 7 for ح, 2 for ء. To a naive pipeline this is neither English nor Arabic and often fails detection entirely.
• Dialect vs. Modern Standard Arabic. Written formal Arabic is MSA. Nobody chats in MSA. Gulf, Egyptian and Levantine dialects differ in vocabulary for ordinary commercial words — including the words for appointment, price, and available.

What we do about it: language identification at the span level rather than the message level; an Arabizi normalisation layer before intent classification; and reply-language policy as an explicit runtime decision — mirror the customer's dominant script unless they've expressed a preference, and hold that preference in conversation state so it survives across sessions.

2. Arabic costs more to process, and it's in your invoice

Tokenizers in most frontier models are optimised for English. Arabic script fragments badly — published benchmarks put it at roughly 2 to 3.3 times more tokens than English for equivalent content, depending on the tokenizer. Cohere's multilingual tokenizer research identified Arabic, Hindi and Burmese as the most poorly served scripts.

Since almost all commercial models bill per token, an Arabic-heavy deployment can cost double an English one for identical functionality. Any vendor quoting you a per-conversation cost off English benchmarks is quoting a number that won't survive contact with your inbox. We cover the mechanics and the mitigations in our post on agent unit economics.

3. Names don't match

Transliteration variance is severe. Mohammed / Mohamed / Muhammad / Mohd are the same name. So are Ahmed / Ahmad, Fatima / Fatema / Fathima. Add multi-part names, patronymics with bin and bint, and the common practice of giving only a first name over WhatsApp.

Exact-match lookup against a CRM will fail on returning customers constantly — which means the agent greets a loyal client as a stranger, loses their history, and asks questions it already had answers to.

What we do about it: phone number as primary identity key (it's the one stable identifier in a WhatsApp-first channel), with fuzzy transliteration-aware name matching as a secondary signal and an explicit confirmation step before merging records.

4. Addresses are not addresses

Large parts of the UAE don't use conventional street addressing the way delivery systems assume. Real-world address information arrives as a community name, a building name, a landmark, a villa number, or a Makani code — Dubai Municipality's ten-digit geo-address system.

A delivery-radius check that expects a postcode will simply fail. An agent that asks "what's your postal code?" reveals immediately that it was built somewhere else.

What we do about it: structured address capture built around the components people actually give — emirate, community, building/landmark, unit — with delivery-zone resolution against those, plus location-pin handling, which is how a large share of UAE customers prefer to answer the question anyway.

5. The calendar is genuinely hard

This is where scheduling systems built abroad break most reliably.

• The working week is not settled. Federal government moved to a Saturday–Sunday weekend with a half-day Friday from January 2022. Private-sector practice varies: some businesses moved with it, others retained Friday–Saturday. Your agent cannot assume a weekend — it has to read it from each business's configured hours.
• Ramadan changes everything. Working hours are legally reduced, opening hours shift, restaurant demand inverts around iftar and suhoor, and salon and clinic booking patterns move into the evening. A static hours configuration is wrong for roughly a month a year.
• Eid dates are lunar and confirmed at short notice. Public holidays are announced close to the date. A booking agent working from a hard-coded holiday calendar will confirm appointments on days the business is shut.
• Prayer times. Many clinics, salons and restaurants have short daily closures that move through the year.
• No daylight saving, but customers routinely coordinate with family in countries that have it — which shows up as ambiguous relative time expressions.

What we do about it: treat business hours, holidays and Ramadan schedules as versioned data with an override mechanism the business controls, never as prompt text. And require the agent to confirm the resolved absolute date and time back to the customer before writing a booking — "Thursday 30 July at 7:00 PM" — because relative expressions like "next Friday" are ambiguous in any language and catastrophic to get wrong.

6. RTL and mixed-direction rendering

Bidirectional text renders correctly in WhatsApp and Instagram most of the time and then doesn't — typically where numerals, currency symbols, times and Latin brand names sit inside Arabic sentences. If your agent produces a message where the price and the time appear in the wrong order visually, the customer isn't going to debug it for you. They'll just book somewhere else.

This has to be tested in the actual client apps, on actual devices, with mixed-script content. It cannot be verified in a console.

7. Currency and price formatting

AED, "dirhams", and "dhs" all appear. VAT at 5% is standard and customers reasonably expect to know whether a quoted price includes it. Price formatting differences between locales are small individually and cumulatively decisive in whether the reply reads as local or foreign.

---

Why this is a moat, and why it's a runtime concern

None of the above is solved by picking a better model. Frontier models handle Arabic reasonably and are improving. What they do not do is know that your Al Quoz branch closes for Friday prayers, that "next Friday" in a Ramadan week is ambiguous, that this customer is the same Fatema who came in March, or that a Makani code is a valid answer to "where are you?"

That knowledge lives in the runtime: in the state model, the tool layer, the business-configuration schema, and the evaluation suite. It's built once and it compounds. It's also the part a foreign vendor entering this market has no reason to have built.

We're comfortable being tested that way. It's how we build the evaluation suite in the first place.