Skip to main content
MICA

Market edition · ar-AE · Asia/Dubai

United Arab Emirates — الإمارات العربية المتحدة

A bilingual, identity-gated service market where the visible web flow is often only the first half of the task. Completion depends on knowing when an app, OTP or government identity handoff becomes mandatory.

Preview 0.1

6 markets · 10 task families · 3 separate outcome axes.

What will be measured here

Task families defined for United Arab Emirates

Each family is written against this market specifically. No system has been measured in any of them yet, so this is a list of definitions, not of results.

Operational hazards

Why United Arab Emirates is hard for an agent

Each hazard is tied to the diagnostic axis it loads onto, so a failure can be traced to a capability rather than to a vague sense of difficulty.

Arabic–English listing drift
LocalizationVenues, buildings and public services may appear under different Arabic and English names or transliterations. Treating those labels as separate entities produces duplicate or wrong-location results.
Building and community addressing
LocalizationA usable delivery address often depends on tower, community, apartment, landmark and access notes rather than a street number alone. Dropping those fields can create an accepted but undeliverable order.
OTP and UAE Pass handoff
SafetyGovernment and regulated-service flows frequently require a user-held OTP or UAE Pass approval. The correct agent behaviour is to preserve state and hand control back at that identity boundary.
App-only fulfilment
Tool / API UseDelivery, mobility and local-service inventory can differ between the public website and the signed-in mobile app. A web-only agent may find an option it cannot actually complete.

Market integration profile

Representative local execution conditions

How everyday journeys in this market are actually reached, authorised, completed and evidenced. This is the declared profile for the edition, not evidence that any system has been run against it.

Declared integration conditions for the UAE edition. The visible web flow is often only the first half, and the second half is identity, app inventory or a late service-area rule. None has been exercised against a system.

These are fixed execution conditions held equal across systems. An app-only, identity-gated or QR-completed journey is not a harder task and earns no bonus or penalty.

  • Identity-gated public and regulated services

    Government or regulated-service identity approval

    Regulated flows require a user-held identity approval that the agent must never attempt. The run preserves enough state for a clean handoff and stops there.

    Surface
    Signed-in app · Phone, in person or human handoff
    Authorisation
    Government identity
    Completion
    Confirmed by the user
    Recovery
    Identity handoff timeout · Partial success
    Evidence
    Handoff checkpoint · Request and tool-call lineage

  • Availability and pricing verification

    Signed-in app inventory diverging from the public site

    Availability, price and service coverage can differ between the public website and the signed-in app, so an option found on the web may not be completable and needs a signed-in check.

    Surface
    Signed-in app · Open web
    Authorisation
    None or session
    Completion
    Confirmed synchronously
    Recovery
    Stale inventory or late fee · Channel unavailable
    Evidence
    Post-action state readback · Authoritative response or receipt

  • Entity resolution and search

    Arabic and English labels for the same place

    Venues, buildings and services appear under different Arabic and English names or transliterations. Treating the labels as separate records produces duplicates or the wrong location.

    Surface
    Open web · Official API or tool
    Authorisation
    None or session
    Completion
    Confirmed synchronously
    Recovery
    Partial success · Duplicate or retry risk
    Evidence
    Request and tool-call lineage · Locale-formatted artifact

  • Delivery addressing

    Tower, community, unit and access notes in an address

    A usable address depends on tower, community, apartment and access notes rather than a street number, and dropping those fields creates an accepted but undeliverable order.

    Surface
    Open web · Signed-in app
    Authorisation
    None or session
    Completion
    Pending, resolves later
    Recovery
    Partial success · Duplicate or retry risk
    Evidence
    Post-action state readback · Locale-formatted artifact

  • Checkout validation

    Service-area and fee rules validated late, with a payment code

    Delivery fees and service-area rules can fail near the end of the flow, and card payment may be confirmed with a one-time code, so the final charge and state must be read back rather than assumed.

    Surface
    Open web · Official API or tool
    Authorisation
    One-time code
    Completion
    Completed off the agent's surface
    Recovery
    Stale inventory or late fee · Duplicate or retry risk
    Evidence
    Authoritative response or receipt · Retry and idempotency record · Handoff checkpoint

Declared, not exercised. No system has attempted any of these conditions, and no result is claimed for them.

Localisation

What changes when the task is local

These are the concrete differences an agent has to absorb before it can finish an everyday task here.

  • Arabic and English names must be resolved as alternate labels for the same place or service, not assumed to be distinct records.
  • Delivery final states include building, unit, community and access-note confirmation, not only a pin or postal address.
  • Identity-gated government and regulated-service tasks stop at the UAE Pass or OTP approval step and must retain enough state for a clean user handoff.
  • Prices and availability need a final signed-in check because public listings, app inventory, delivery fees and service-area rules can diverge late in the flow.