# Qantara: the whole site > Qantara puts AI to work inside Gulf companies in logistics, distribution, manufacturing and automotive, starting with work that still runs on paper, phone calls and WhatsApp. Named engineers work on site inside the operation, build agents around the systems already there, in Arabic and English, and stay until the team runs it. Through partners, AI from Silicon Valley is deployed in Gulf companies. Based in Muscat, working across the Gulf. Every page of https://qantara.systems, as Markdown, in the order of https://qantara.systems/llms.txt. Each page ends with its canonical address; cite that, not this file. --- # We put AI to work inside Gulf companies. Qantara sends engineers into the companies that run the Gulf's logistics, distribution, manufacturing and automotive work, to build AI into the operation itself, in Arabic and English. We stay until it runs on the real workflow. We are based in Muscat and work across the Gulf. [Talk to the team](https://qantara.systems/contact) ## Qantara at a glance - Based in: Muscat, Oman - Works in: Across the Gulf - Industries: Logistics, distribution, manufacturing and automotive - Languages: Arabic and English, on the same document - How we work: Engineers on site, inside the operation - Security: ISO/IEC 27001, ISO/IEC 42001 and SOC 2 Type II in progress - Hiring: Five open roles - The name: Qantara is Arabic for arch, or bridge ## What we do 1. Engineers inside the operation: A named engineer works on your premises beside the people who run the process, and writes down how it really runs before anything changes. 2. AI built on how you run: Agents work inside your ERP and on the channels your customers already use, and every one writes to a single record of your operation. 3. The best of Silicon Valley, brought in: Through our partners, the AI being made in Silicon Valley reaches Gulf companies, deployed under each country's rules and supported on the ground. The work of the Gulf still runs on paper, phone calls and spreadsheets. We put AI inside it, on site, in Arabic and English. ## How we work From the first morning on site to the day your team runs it without us. Four steps, the same at every company. ### Embed: A named engineer, on your premises - Sit with the people who run it: From the start of their working day, beside the team that does the work, in the systems and on paper. - Write down how it really runs: Every step, every exception and every message, the way the work is done rather than the way it is described. - Record the baseline: How long it takes, how often it goes wrong and what it costs, before anything changes. - Choose the first process: The one that costs the most time, agreed with you before anything is built. ### Build: Agents built around your systems - Connect what you already run: Your ERP, WhatsApp and email, reached where the data already is. Nothing is replaced. - Set your thresholds: What the agent may do alone, and above which limit a person on your team approves. - Arabic and English, from the start: Voice notes, messages and documents read in the language they arrive in. - Tried on real cases: Your team tries it on past cases as it takes shape, and marks what good looks like. ### Measure: Read on your own numbers - The same reading as the baseline: The results are read the same way as before anything changed, so the comparison is fair. - With the people who run the work: Reviewed every week with your team, not presented to it. - Tuned until they move: The agent is adjusted where the results fall short, and its limits widen only when they hold. - Every action on the record: What the agent did, who approved it and what happened next, kept in your country. ### Hand over: It runs without us - Your team runs it: Approvals, thresholds and exceptions handled by the people who own the work. - Written down: How it works, what it reads and what to do when something changes, in your language. - The next process: The second agent starts from what the first agent wrote, so it is built on what the record already knows. - Then the branches: Branches and group companies follow, one at a time. ## What we believe The mindset we hire for, and hold each other to. > The best AI in the world is worth nothing until it works at seven in the morning, in Arabic, for the person who has to use it. 1. Start where the work is: The answers are on the warehouse floor and at the branch counter, not in the meeting about them. We go there first. 2. Do the simple thing that works: The smallest agent that removes real work, shipped and used, beats the ambitious one still being planned. 3. Their numbers, not ours: We are judged on the customer's own figures, read the same way before and after. Nothing else counts as done. 4. Arabic is not a translation: The way people really write and speak in the Gulf is the product, not a setting added at the end. 5. Say it plainly: We tell people what will work and what will not, before they pay for it, and write down what we promise. 6. Leave it running: We are finished when the team runs it without us, and the next process starts from what we left behind. ## Two sides of one bridge - Partners: Silicon Valley and frontier technology companies whose AI belongs inside Gulf operations, and who want it deployed properly, in Arabic, under each country's rules. - Gulf partners: The companies that run the Gulf's logistics, distribution, manufacturing and automotive work, where much of it still runs on paper, phone calls and spreadsheets. ### The partner program Technology partners embed their products in the work we deploy. We make the introductions, integrate and deploy their technology inside Gulf companies, in Arabic and English and under each country's data rules, and support it on the ground. They reach a market they could not reach alone; Gulf companies get the best AI, working on their own data. [Apply to the partner program](https://qantara.systems/contact?topic=partners) ## Tell us where to start. Write to our team about the work you would fix first. [Talk to the team](https://qantara.systems/contact) Canonical: https://qantara.systems/company --- # The hardest deployments are not in San Francisco. We put engineers inside Gulf companies that never ran on software, and stay until the work runs on AI. We are hiring engineers, deployment specialists and business development, in Muscat. [See open roles](https://qantara.systems/company/careers#roles) ## Open roles Five roles, all full-time. Apply to the one closest to what you have done. ### Engineering and deployment - Founding forward-deployed engineer: Full-time, on site. Muscat, with time across the Gulf. Lead deployments end to end, set how we build, and help hire the engineers who follow. - Forward-deployed engineer: Full-time, on site. Muscat. Build agents inside a customer's operation, from the first morning on site until they run without you. - Deployment specialist: Full-time, on site. Muscat. Map how the work really runs, train the people who use the agents, and keep them running after handover. ### Business development - Founding business development representative: Full-time. Muscat. Open our first doors in the Gulf, and build how we find and start every engagement. - Business development representative: Full-time. Muscat. Find the companies whose operations we can fix, and start the conversation with the people who run them. ## The work Three kinds of work, one team. Each starts inside a Gulf company's day, and ends when the work runs on its own. ### Engineers: Build it where the work happens - Sit with the people who run it: On site from the start of their working day, writing down how the process really runs, in the systems and on paper. - Build the agent around their systems: Connections to the ERP, WhatsApp and email, the thresholds the team sets, and the Arabic and English the work arrives in. - Test it on their past cases: Before anything goes live, the agent runs on real past cases, and the team marks what good looks like. - Stay until it runs without you: Measure against the baseline, tune until the numbers move, hand over, and start on the next process. ### Deployment: Make it part of the day - Train the people who use it: In their language, on their own cases, until approving an agent's work is part of the day. - Read the numbers every week: The results read the same way as the baseline, with the people who run the work. - Catch what changes: A new price list, a new branch, a new supplier: you see it first, and the agent is adjusted. - Be the person they call: The named contact after handover, in their time zone and their language. ### Business development: Open the right doors - Find the companies: Distributors, freight firms, manufacturers and dealer groups across the Gulf whose work still runs on paper, calls and spreadsheets. - Start with an introduction: Most engagements here begin with one. You earn them, follow them up and keep them. - Learn the operation before the pitch: Ask how the work runs today, who does it and where the time goes, and bring an engineer to the second meeting. - Hand over a clear first scope: The process to start with and the numbers it will be measured on, agreed before anyone visits. ## Who we are looking for People who have made something work inside someone else's operation, and want the harder version of the problem. 1. You have shipped software into someone else's operation and stayed until it worked. 2. You can sit with an operations manager at seven in the morning and with a model at midnight. 3. You care about the outcome more than the stack. 4. You would rather be on site than on a call, and you listen before you build. 5. You write things down, so the next person starts from what you learned. 6. You say plainly what will work and what will not, to the person who owns the decision. 7. Arabic helps in every role, and matters most for our Muscat team. ## How we work A small team, close to the work. Four habits we hire for and keep. - On site, not on slides: We do the work where it happens: at the branch, in the warehouse, beside the people who run the process. - Measured on their numbers: We are judged on the customer's own figures, read the same way before and after, never on what we shipped. - Written down: Every decision is in the record, the code and the notes, so the next person starts from what we already know. - Two languages, one standard: Arabic and English get the same care: in the product, in the documents and in the room. ## What candidates ask ### Which role should I apply for? The one closest to what you have done. Tell us in your answer if another role would suit you better. ### Do I need to speak Arabic? English is required for every role. Arabic helps in all of them, and matters most for our Muscat team. ### How much of the work is on site? Most of it, for engineers and deployment specialists: the work happens inside the customer's operation. Business development is in meetings with the people who run it. ### How long should my answer be? As long as it takes to show what you made work, the people who ran it, and what changed. Most good answers fit on a page. ### Can I use AI to write it? Use AI the way you would on the job, and tell us where you did. ## Apply Four short fields and one question. Our team reads every application. - Name (required) - Email (required) - LinkedIn or GitHub (optional) - Role (required): Founding forward-deployed engineer, Forward-deployed engineer, Deployment specialist, Founding business development representative, Business development representative - Describe the hardest thing you made work inside someone else's operation. (required) Apply at https://qantara.systems/company/careers#apply. We never ask candidates for payment, at any stage. Canonical: https://qantara.systems/company/careers --- # Your data, held for you. Operations data is the most sensitive data a company has. We deploy AI inside your systems and in your country, under your rules, and put what we commit to in writing. [Send us your questionnaire](https://qantara.systems/contact?topic=security) ## Certifications and frameworks - ISO/IEC 27001:2022 (Information security): In progress. Our information security management system, built to be audited by an accredited certification body. - ISO/IEC 42001:2023 (AI management): In progress. How we govern the AI we deploy: risk, testing, human oversight and change. - ISO/IEC 27701:2025 (Privacy): In progress. Privacy information management, mapped to the Gulf's personal data laws. - SOC 2 Type II (Independent attestation): In progress. An examination of our controls over a period of time, by an independent CPA firm. - CSA STAR Level 1 (Cloud security): In progress. Our answers to the Cloud Security Alliance questionnaire, for its public registry. The laws we deploy under: Oman, Personal Data Protection Law, Royal Decree 6/2022; Saudi Arabia, Personal Data Protection Law; UAE, Federal Decree-Law 45 of 2021 on personal data; Qatar, Law 13 of 2016 on personal data privacy. ## Protection in layers. Control in your hands. - Protection in layers: Controls at every stage your data passes through: where it is kept, who reaches it, what each agent may do, and what is written down. - Your data, your rules: You own the record and decide what is kept, for how long and who reads it. It is never used to train a model for anyone else. - Deployed where you need it: In a cloud region in your country, in your own cloud account, or on hardware in your building. ## In your country by default. In your building when you need it. Every deployment lives in one place, agreed with you in writing before anything is built. The record, the documents it was written from and the log of every action stay there together. - In-country cloud: A cloud region inside your country, run for you by our engineers. The default, and the fastest way to start. - Your own cloud: Inside your account on AWS, Microsoft Azure, Google Cloud or Oracle, in their in-country regions. You hold the account and the keys. The provider's certifications cover its infrastructure, not our work. - Your building: On hardware in your data centre, for work that must never leave it, with a model that runs there too where the work allows. - One customer per deployment: Every deployment is its own. Your data is never pooled with another customer's. ## Encrypted everywhere. Reached only by name. Each person and each agent reads the part of the record its work needs, and nothing else. Every look and every change is a line in the log. - Encrypted in transit and at rest: TLS 1.2 or higher on every connection, and AES-256 for everything stored: the record, the documents and the log. - Behind your single sign-on: Your people sign in through your identity provider, with roles your IT team sets: who may read, approve, change or export. - Agents with a login of their own: Each agent signs in with credentials of its own, never a person's, scoped to one deployment and yours to revoke at any time. - Our engineers, logged like an agent: Our engineers' access is scoped to the deployment, approved by you, and recorded line by line. ## Agents tested on your work before they touch it. A model reads the work in order to do it. Before any agent goes live, you get in writing what it reads, which of it is personal data, and where that model runs. - Run on your past cases: Each agent is run on your past cases first, in Arabic and English, with your team marking what good looks like. - Tested against hostile input: Messages and documents can carry instructions meant for the agent. Every agent is tested against them, and what it reads is treated as content, never as a command. - A person above every threshold: It starts with a low threshold and a person on every case. Its limits widen only when the results hold. - Never trained on your data: No model is trained on your data, and each workflow's model is chosen for it and named before it goes live. ## How agents reach your systems. Agents read your ERP, your e-invoicing provider, WhatsApp and email where the data already is, and write back only what you allow, after the checks you set. - Scoped and revocable: Credentials are scoped to one deployment and yours to revoke at any time. - Authenticated and encrypted: Every call between an agent and your systems is authenticated and encrypted, over private connections where your network allows. - Every read and write logged: Every read and every write is a line in the log, kept in your country and sent to your own systems when you want it. - Nothing replaced: Your systems stay where they are. Agents work inside them, with the permissions your IT team chooses. ## For regulated industries and markets Banks, health providers, government-linked groups and anyone holding personal data answer to rules of their own. Bring them, and the deployment is built inside them. - Oman: Royal Decree 6/2022, regulated by Ministry of Transport, Communications and Information Technology. In Oman, unless you agree otherwise in writing. - Saudi Arabia: Personal Data Protection Law, regulated by Saudi Data and AI Authority. In Saudi Arabia, unless you agree otherwise in writing. - UAE: Federal Decree-Law 45 of 2021, regulated by UAE Data Office. In the UAE, unless you agree otherwise in writing. - Qatar: Law 13 of 2016, regulated by National Cyber Security Agency. In Qatar, unless you agree otherwise in writing. Sector rules reach suppliers through your contracts: the NCA's controls and SAMA's framework in Saudi Arabia, DESC's regulation in Dubai, ADHICS for health in Abu Dhabi. Bring yours to the first conversation. ## The controls we hold ourselves to Grouped by area. Each is in place or being put in place as part of our ISO/IEC 27001 work, and is part of what the auditors will examine. ### Infrastructure security - Data encrypted at rest: AES-256 for the record, the documents and the log. - Data encrypted in transit: TLS 1.2 or higher on every connection. - One deployment per customer: No customer's data is pooled with another's. - Production access restricted and logged: Only named people, with your approval, every session recorded. - Multi-factor authentication for our staff: On every system that reaches a deployment. - Network access limited to need: Each service reaches only what it must. ### Organizational security - Confidentiality agreements: Signed by every employee and contractor. - Security training: On joining, and every year after. - Background checks: Where the law of the country allows. - Managed, encrypted laptops: Every device that reaches a deployment. - Access removed on leaving: The same day someone leaves. ### Product security - Agents run on past cases before going live: Marked by your team, in Arabic and English. - Tested against hostile input: Instructions hidden in messages and documents. - A person above every threshold: Actions above your limits wait for approval. - Independent penetration test: By an outside firm, with findings fixed and retested. - Vulnerability scanning: Continuous, with critical findings fixed first. ### Internal security procedures - Information security policies: Written, owned and reviewed every year. - Incident response plan: Written and tested, with notice to you in writing. - Backups and continuity: Backups in your country, restores tested. - Risk assessment: Every year, and before every new kind of deployment. - Supplier reviews: Every subprocessor reviewed before it is used. ### Data and privacy - Your data is yours: The record's contents belong to you, and leave with you. - Kept in your country: Where exactly is agreed in writing before anything is built. - No training on your data: Never pooled, never sold, never used to train a model. - Return and deletion at the end: In standard formats, then deleted and confirmed in writing. - Retention rules: How long each kind of data is kept, set with you. ## Subprocessors The companies that process data in a deployment, the cloud region and the models it calls, are named in your contract before anything is built, with where each one runs. ## What reviewers ask ### Are you certified? Not yet. ISO/IEC 27001, ISO/IEC 42001 and SOC 2 Type II are in progress, and we will publish each certificate or report when it is issued. ### Do you train on our data? No. No model is trained on your data, and it is never pooled with another customer's or sold. ### Where is our data kept? In your country: in a cloud region there, in your own cloud account, or in your building. Where it runs answers it country by country. ### Who at Qantara can see our data? Only the engineers named on your deployment, with access you approve, scoped to it and logged line by line, like an agent's. ### Will you complete our security questionnaire? Yes. Send it before anyone visits: SIG Lite, CAIQ or your own. We answer in writing. ### Who do we tell if we find a vulnerability? Write to us through Contact and choose the security question. Leave customer data, passwords and access keys out of your message. ## Report a problem If you find a vulnerability, or something that looks wrong, tell us through Contact and choose the security question. Leave customer data, passwords and access keys out of your message. [Report it to us](https://qantara.systems/contact?topic=security) ## Bring your data rules. Send your questionnaire before anyone visits. We answer in writing. - [Where it runs](https://qantara.systems/platform/where-it-runs) - [Control: the thresholds and the log](https://qantara.systems/platform/control) - [The operating record, and how it leaves with you](https://qantara.systems/platform/record) Canonical: https://qantara.systems/company/trust --- # Talk to the team. Your message goes to our team. Tell us what costs your team the most time, and choose how we reply: email, WhatsApp or a call. Offices: Muscat (Sunday to Thursday). ## What brings you here? - I want to fix something in my company's operations. - I represent an AI company and want to reach the Gulf. - I want to work with Qantara. - I have a security, data or procurement question. - I am a journalist. ## Your message to the team Start with the work. Your name and how to reach you come after. - What would you fix first? (required) - Your name (required) - Company (optional) - How should we reply? (required) - Email (required): email - Phone number, with country code (required): whatsapp or call - Who introduced you? (optional) Send at https://qantara.systems/contact. Email: hello@qantara.systems. Prefer to be introduced? Ask anyone who knows us to forward this page. We use what you send only to reply. We never name a company that writes to us. ## What happens after you write From your message to the first day on site, in this order. ### 1. Our team reads it Your message goes to our team, not to a call centre. One of us reads it and answers on the channel you chose: email, WhatsApp or a call. ### 2. A conversation about the work We ask how the work runs today: who does it, in which systems, and where the time goes. The engineer who would build it with you joins the conversation. ### 3. Scope and price, in writing After the first conversation we send scope and price in writing: the process we start with, what we build, and how it is measured against your own numbers. ### 4. Engineers on site A named engineer works on your premises beside the people who run the process, writes down how it really runs, and records the baseline before anything changes. [How the engineers work](https://qantara.systems/platform/engineers) ## What owners ask before they write ### Who will I talk to? Our team. The engineer who would build with you joins the conversation about the work. ### Do we need an introduction? No. Most engagements begin with one, and the form asks who introduced you, but you can write to us directly. ### Where does our data go? Bring your data rules. Where it runs explains where the records and the models run, country by country. ### Can our IT team review you first? Yes. Data security lists what we put in writing and how to run your review, before anyone visits. ### What does it cost to start? We send scope and price in writing after the first conversation. There is no price list. ### Will you name our company? No. We use what you send only to reply, and we never name a company that writes to us. ## Read how we work before you write - [How the engineers work](https://qantara.systems/platform/engineers) - [Where it runs](https://qantara.systems/platform/where-it-runs) - [The thesis](https://qantara.systems/thesis) Canonical: https://qantara.systems/contact --- # Pick the work that costs your team the most time Start from your industry or from the process behind it. Every engagement begins with engineers on site and ends with results measured against your own numbers. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) In every company, one process eats more of the week than it should. We start there. Each process after it begins where the last one ended. ## By industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. Processes: quotes and bookings, orders and confirmations, customer inquiries, e-invoicing and compliance, collections, supplier follow-ups. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. Processes: quotes and bookings, orders and confirmations, customer inquiries, e-invoicing and compliance, collections, supplier follow-ups. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. Processes: quotes and bookings, orders and confirmations, customer inquiries, e-invoicing and compliance, service bookings. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. Processes: orders and confirmations, customer inquiries, e-invoicing and compliance, collections, service bookings, supplier follow-ups. ## By process The work that repeats every day, across every industry we serve. - [Quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) (sales): How fast does a request become a confirmed booking? The agent: draft the quote from your rates. - [Orders and confirmations](https://qantara.systems/solutions/orders) (sales): How many messages does one order take? The agent: capture the order into your ERP. - [Customer inquiries](https://qantara.systems/solutions/customer-inquiries) (customer support): How many calls a day are about where an order is? The agent: answer the status question before the call. - [E-invoicing and compliance](https://qantara.systems/solutions/e-invoicing) (finance): Is every invoice checked before it goes out? The agent: check the invoice before it is issued. - [Collections](https://qantara.systems/solutions/collections) (finance): Which payments are late, and who has been told? The agent: send the reminder on the due date. - [Service bookings](https://qantara.systems/solutions/service-bookings) (customer support): What happens to the calls your branches miss? The agent: book the slot and set the reminder. - [Supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups) (operations): Which late delivery stops production next week? The agent: chase the delivery before it is late. ## Every door opens onto the same record Each agent reads from and writes to one operating record: what moved, where, when, for whom and at what cost. Whichever process you start with, the next one begins with what the last one learned, and what works in one company carries to the next. ## Built around the systems you run Nothing has to be replaced to start. Agents connect to what your teams already use and work inside it, so there is no new tool to learn. - ERP and accounting - Customs single windows - CRM - E-invoicing providers - Forwarding and transport software - Spreadsheets - Email - WhatsApp Business - Supplier and customer portals - Banking feeds - Dealer management systems - Plant and MES systems ## What every engagement includes - **Engineers on site.** Our engineers sit with the people who run the process and record how it runs today before anything changes. - **Nothing replaced.** Agents are built around your ERP, CRM, customs, e-invoicing and messaging. Your team keeps the tools it knows. - **A person above your thresholds.** You set the limits. Above them, an agent prepares the case and a person decides. - **Every action logged.** What the agent read, what it did, who approved it and what happened next, on your record. - **Measured against your baseline.** Results are tracked against the numbers we recorded together, and reviewed with the people who run the work. - **One record, compounding.** Each process starts where the last one ended, and what works in one company carries to the next. ## From Muscat, across the Gulf Engineers on site in Oman, and the same team, the same agents and the same record wherever your branches are. - Oman - Dubai - Abu Dhabi - Qatar ## Where do you want to start? Tell us which part of the business costs your team the most time. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions --- # Every shipment quoted, confirmed and documented on time For forwarders, carriers and logistics providers. Our engineers build agents around the systems you already run, from the first rate request to the final invoice. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) One shipment, today and with agents. The same six stations twice. The blue lane stops where today waits for replies and documents; the orange lane, with agents, runs straight through. In freight, every hour between a request and an answer costs margin. We put agents on the conversations and documents that decide how fast cargo moves. ## What the agents do in freight Five teams, five workflows, for forwarders, road carriers and logistics providers, around the systems you already run: your forwarding or transport software, the single window of each country you file in, your e-invoicing provider, WhatsApp and email. All of it writes to one shipment record. ### Sales: Quote every request before the customer asks twice How fast does a rate request become a confirmed booking? - **Read every rate request.** WhatsApp, email and portal requests captured into one queue with the lane, the cargo, the terms and the dates, in Arabic or English. - **Draft the quote from your rates.** Sea, air and road legs from carrier contracts and rate sheets, local charges at both ends, and the margin rule you set. - **Route it to pricing.** Above your threshold a person approves with the draft and the rates in front of them. Below it, the quote goes out. - **Follow up and convert.** The open quote is chased on the customer's channel. The acceptance becomes a booking in your forwarding system, and the shipping instructions are requested. [See quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) ### Operations: Bookings confirmed before the cut-off, containers and trucks moved on time Is every booking acknowledged before the cut-off, and who is chasing the carrier that has not replied? - **Confirm every booking before the cut-off.** The carrier's confirmation read and matched to the booking, the cut-off and the free days noted, your forwarding system updated. - **Chase the carrier that has not replied.** Open requests followed up on schedule, on WhatsApp and email, and the reply recorded against the shipment. - **Arrange the container and the truck.** Release, pickup and return inside the free days, the trucker told the slot, the delivery order chased. - **Prepare the border file for road legs.** The papers the driver carries to the crossing checked against the shipment before the truck leaves, so the wait at the border is the queue and nothing else. [See supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups) ### Customer support: Every delay announced before the customer asks Do customers hear about a delay before they ask, or do they call? - **Tell the customer before they ask.** A vessel delay, a rerouting or a queue at the border goes out on the channel the customer uses, in their language, with the new date. - **Answer where the container or the truck is.** From the shipment record, on WhatsApp or email, instead of a call to operations. - **Send the documents they ask for.** A copy of the bill of lading, the delivery order status, the invoice, found on the record and sent. - **Hand the exceptions to a person.** A claim, damaged cargo or an angry customer goes to your team with the whole thread. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ### Compliance: Every declaration complete before the cargo arrives Is every declaration complete before the cargo arrives, or does the demurrage clock start first? - **Check the file before it is filed.** Invoice, packing list and bill of lading read together: consignee, values, HS codes and model numbers that agree, because a name that differs is what gets a container held. - **Prepare the declaration in the single window.** Drafted from the shipment record for the national window of the country you file in, ready for your licensed broker. - **Chase the certificates.** Certificate of origin, the conformity certificate where the destination asks for one, attestations, linked to the shipment before the vessel arrives. - **Hold what is not ready and say why.** What is missing, named, to your team, while there is time. Nothing is filed without a person above your threshold, and the demurrage clock is in the picture. ### Finance: The invoice out on delivery, compliant and paid How soon after delivery does the invoice go out, and who checks the carrier's? - **Issue the invoice on delivery.** From the shipment record, checked against the e-invoicing rules of the country it is issued in, through your provider. - **Audit the carrier's invoice.** Matched to the quote and the booking. Demurrage, detention and storage charges checked against the dates on the record before anyone pays them. - **Follow up the payment on schedule.** Reminders on the due date, in the customer's language, each promise to pay recorded. - **Escalate with the thread.** Disputes and silence go to your team with everything that was said and every document that was sent. [See e-invoicing and compliance](https://qantara.systems/solutions/e-invoicing) ## How it works in freight 01 **Embed.** Our engineers sit with sales, pricing, operations and documentation and record how each desk works today: where requests arrive, where the rates live, what is re-typed, and how long a quote takes from request to reply. That is the baseline. 02 **Build.** An agent reads each rate request, pulls rates from your rate sheets, carrier contracts and the customer's history, drafts the quote in Arabic or English and routes it to pricing. The accepted quote becomes a booking in your forwarding system. 03 **Scale.** The same record extends to bookings, status updates and customs documents, then to the next company in the group, which starts with everything learned in the first. 04 **Measure.** Quote turnaround, hours on quotes and days from delivery to invoice, each against the month before we start, reviewed with the people who run the work. ## Two filings, one record Declarations go through national single windows, and every invoice has to meet the e-invoicing rules of the country it is issued in. Agents prepare both from the same shipment record, so nothing is typed twice. One shipment record, two filings. The documents feed one record. The declaration and the invoice each pass their own checks, at the orange ring, before they leave. ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your forwarding software, your ERP and the customs and e-invoicing windows you already file through. - Forwarding and transport software - Customs single windows - ERP and accounting - E-invoicing providers - Email - WhatsApp Business - Carrier and port portals - Spreadsheets ## What forwarders ask us **Do you replace our forwarding software?** No. Agents read from and write to the forwarding, transport and accounting systems you already run, through their own interfaces. Your team keeps the screens it knows, and nothing is migrated. **Who approves a quote before it goes out?** You set the rule: a margin, a lane, a customer, an amount. Below it the quote goes out; above it a person in pricing approves, with the draft and the rates in front of them. Every quote is logged either way. **Can agents handle Arabic and English documents?** Yes. Requests, confirmations and customer messages are read and answered in Arabic or English, whichever they arrive in. Documents for customs and invoicing are prepared in the language the recipient expects. **What happens when a declaration is incomplete?** The agent holds it, says what is missing (a packing list, an HS code, a value) and tells your team. Nothing is filed with an authority without a person above the threshold you set. **What about our carriers and customers who only use WhatsApp and phone?** That is where most of the work is. Agents read and answer WhatsApp and email, and record every call and promise on the shipment record, so a carrier who confirms by message is as logged as one who confirms in a portal. **Do you file customs declarations yourselves?** No. Your licensed broker files, as today. The agent prepares the file from the shipment record, checks that the invoice, the packing list and the bill of lading agree, chases the certificates, and holds anything that is not ready with a note on what is missing. **Where do we start?** Most forwarders start with quotes: the turnaround from request to reply is the easiest number to record on day one, and the easiest to move. Bookings, status updates and customs documents follow on the same shipment record. ## Other industries - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with one shipment Tell us where a shipment waits longest today: the quote, the booking, the documents or the invoice. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/logistics --- # Orders confirmed, delivered and collected without the chase For distributors and trading companies with many customers, products and routes. Agents take the messages around every order, from the first WhatsApp to the payment, inside the systems you already run. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) A morning of messages, sorted. The agent reads each message in the order it came and sends it to where its work gets done. The orange one needed a person. Distribution runs on thousands of small messages, and together they decide your margin. We put agents on every one, so no order waits in someone's phone. ## What the agents do in distribution Five teams handle an order between the first message and the payment. Agents work alongside each of them, inside your ERP and on the channels your customers and salesmen already use. ### Sales: Every order entered the day it is sent How many messages does one order take? - **Take orders the way they arrive.** Customers order on WhatsApp, by voice note, with a photo of a handwritten list or through the salesman who visited them. The agent reads each one, in Arabic or English, and turns it into order lines. - **Match their words to your item codes.** “The usual rice” and “oil, the big tins” become the right items and pack sizes,, taken from what that customer has bought before and the names your salesmen use. - **Check stock and credit before confirming.** Each line is checked against stock on hand and the customer's account in your ERP. A line that cannot ship is offered as a substitute or a later date before the order is confirmed. - **Enter the chains' purchase orders.** Supermarket and hypermarket chains send purchase orders through their supplier portals or by email. The agent picks them up, checks the prices against your agreed list and enters them, so a mismatch is caught before the truck leaves. [See orders and confirmations](https://qantara.systems/solutions/orders) ### Customer support: Every customer answered from the record How much of the day goes on calls asking where an order is? - **Say where the order is.** From the order, the pick list and the van's route, on WhatsApp or email, in the customer's language, without anyone calling the warehouse. - **Say what is in stock, and when more arrives.** Stock on hand at the branch that serves the customer and, when an item is out, the date the next delivery from the supplier is due. - **Send the papers they ask for.** A copy of an invoice, the statement of account or the delivery note signed at the door, found on the record and sent. - **Put a complaint where it gets settled.** A short delivery, a damaged carton or a wrong price reaches the person who can settle it, with the order and the photos, and the customer is told who has it. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ### Operations: Every delivery booked into the store's receiving window Is every delivery slot confirmed the day before? - **Book the slot at the store.** Distribution centres and large stores receive at set hours, often by appointment. The agent books the slot, sends what the appointment asks for and moves the delivery when a slot is lost. - **Turn orders into pick lists and drops.** Confirmed orders become pick lists in the warehouse and drops on the right van, in the order of the route, with each customer's receiving hours. - **Close each delivery with its proof.** The signed delivery note or the driver's photo is read and matched to the order, and a short or refused line is recorded the same day. - **Collect returns and near-expiry stock.** Damaged, expired and near-expiry goods agreed with the customer are put on the next run, counted on collection and passed to finance for the credit note. ### Finance: Every payment followed until it is in Which payments are late, and who has been told? - **Invoice what was accepted.** The invoice follows the signed delivery note, and returns, short lines and agreed price corrections get a credit note against the original, so the customer's statement matches what they received. - **Remind before the due date and after it.** Statements and reminders go out on the customer's channel and in their language. Each promise to pay is recorded and checked on the day it was due. - **Keep track of post-dated cheques.** Cheques handed to salesmen and drivers are logged with their dates and banks, deposited on the day they fall due and matched when they clear. A returned cheque reaches credit control and the salesman the same day. - **Release held orders on a decision.** An order held for credit goes to the credit controller with the balance, what is overdue and the last payment, and it is released the moment it is approved or paid. [See collections](https://qantara.systems/solutions/collections) ### Purchasing: Every reorder placed before the shelf is empty Are reorders placed before stock runs out? - **Watch stock against what is selling.** Stock on hand, open orders and what each item sells week by week, read from your ERP, so the reorder point moves with demand, ahead of Ramadan and Eid as much as in the summer. - **Draft the purchase order.** Quantities for each supplier from the reorder rules you set, in the supplier's pack sizes and minimums, for your buyer to approve. - **Chase the supplier's confirmation.** The order is acknowledged, the ship date confirmed and the documents asked for. A date that slips is flagged with the customer orders it affects. - **Tell sales what is coming.** When stock is short, the salesmen and the customers waiting for it hear the arrival date, so nobody promises what is not there. [See supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups) ## Beyond the five teams Some of the work around an order happens on the road, with the brands you carry and before a customer has an account at all. - **The van's day, reconciled.** A van salesman loads stock in the morning, sells, collects cash and cheques and brings back what did not sell. The agent reconciles the load, the sales, the returns and the money each evening, and names what does not add up. Every van closed the same evening, with the gaps named. - **Reports for the brands you carry.** Principals ask for sell-out by outlet, stock cover and promotion results, each in their own format. The agent builds them from your ERP on their schedule and sends them for your sign-off. Your brands get their numbers on time, from one record. - **Near-expiry stock sold, not written off.** Stock coming close to its date is found in the warehouse and offered to the customers who buy it fastest, at the price you allow, before it has to be collected back. Less stock written off, sold while it can be. - **New accounts opened with their papers.** A new shop asks to buy on credit. The agent asks for the trade licence, the tax certificate and the credit application, checks they are complete and readable, and opens the account for credit control to approve. New customers ordering in days, with complete files. ## How it works for distributors 01 **Embed.** Our engineers sit with sales, the warehouse and finance and follow a week of orders through: every message each one took, who answered it and where it waited. That becomes the baseline, and the longest wait is where we start. 02 **Build.** The agent matches the customer's own words to your item list, asks once when two items could fit, checks stock and credit, and enters the order in your ERP before it confirms. 03 **Scale.** Every word a customer uses for your items, once matched, stays on the record. The next branch and the group's other companies start from it, and only what is new is asked. 04 **Measure.** Messages per order and the days from order to confirmation, delivery, invoice and payment, each against the month before we start, counted with your team. ## A price change needs its reasons Landed costs moved this year: freight, insurance and lead times changed from one booking to the next. When your costs rise, your prices have to follow, and for essential goods a rise can need the regulator's approval first, argued from the supplier's invoice, the freight and the duty. Agents keep each item's landed cost on the record as those documents arrive, so the case for a new price is ready when you need it, and the price reaches every list and open order on the day it applies. The landed cost behind a new price. Each grey column is one cost of landing the item, built on the last; the orange one is what rose since the last shipment. ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your ERP and warehouse system, read your price lists and stock, and answer on the channels your customers and salesmen already use. - ERP and accounting - Warehouse system - Van sales and route apps - Price lists - Email - WhatsApp Business - Retailers' supplier portals - Banking feeds - Spreadsheets ## What distributors ask us **Our customers order through salesmen, not systems. Does that still work?** Yes. Most orders start as a visit, a call or a voice note. The salesman sends it the way he does today and the agent enters it, so he keeps the customer and stops typing. **Does this work with our ERP?** Agents read from and write to the ERP you run, through its own interfaces: orders, stock, credit, invoices and receipts. Nothing is migrated, and your team keeps the screens it knows. **Will customers know they are talking to an agent?** If you want them to, and the agent says so whenever it is asked. It writes in your company's name and the customer's language, and passes anything that needs a person to the salesman or the account manager with the whole thread. **What if our item list is a mess?** Most are. The first weeks clean it with your team: duplicate codes, missing pack sizes and the names customers really use. The agent works from that list, and anything it cannot place still goes to a person. **Do agents take orders by phone?** Calls your team takes stay with your team, and what was agreed reaches the order from their note or voice message. **Can agents chase payments without upsetting customers?** They follow the terms the customer agreed, in your tone, and stop the moment a payment or a promise comes in. A dispute or a long-standing account goes to the person who owns the relationship. **Where do we start?** Most distributors start with orders, because the messages one order takes are easy to count with your team and the quickest to cut. Collections and reorders follow on the same record. ## Other industries - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with one day of orders Tell us where orders come in today and who types them up. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/distribution --- # Every booking, parts request and customer followed up For dealers and distributors of vehicles and heavy equipment. Agents answer customers on the channels they write on, fill service bays, chase parts and follow up every lead and claim, across every brand and branch. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) A day of calls at your branches. Each dot is a call: grey if a branch answered, hollow blue if nobody did. Every missed call is written back to along the orange line. A missed call is a missed booking. We make sure every customer, branch and machine gets an answer. ## What the agents do at a dealer group Five teams look after a customer between the first enquiry and the next service. Agents work alongside each of them, inside your dealer management system, the manufacturers' portals and the channels your customers already use. ### Service: Every bay filled, every customer reminded What happens to the calls your branches miss? - **Write back to every missed call.** A customer who could not get through gets a message on WhatsApp straight away, in their language, with the slots open at their branch. - **Book the job, not only the time.** The booking carries the vehicle, the work asked for and the parts it needs, so the bay, the technician and the parts are ready when the car arrives. - **Remind at the right moment.** Service due by date or by mileage, the day before the visit and on the morning, each on the channel the customer answers. - **Keep the customer told while it is in.** Extra work found on inspection goes to the customer with the estimate for a yes, and the car's progress is sent without anyone having to call. [See service bookings](https://qantara.systems/solutions/service-bookings) ### Parts: Every parts question answered from stock How long does a parts enquiry wait for an answer? - **Answer from the catalogue and the shelf.** A part asked for by photo, by name or by chassis number is identified from the brand's catalogue and checked against stock at every branch. - **Order what is not on the shelf.** A part that is not in stock is ordered from the brand with the right urgency, and the customer is given the date the brand confirms. - **Chase the back orders.** Orders the brand has not shipped are followed up every day, oldest and most urgent first, and the workshop hears when a part is on its way. - **Serve the trade counter.** Workshops and fleet buyers who order parts every week get their prices, their stock answers and their invoices without waiting at the counter. [See orders and confirmations](https://qantara.systems/solutions/orders) ### Sales: Every lead answered the day it comes in Is every test drive and quote request followed up? - **Answer the lead while it is warm.** Enquiries from the brand's site, your own site, social media and the showroom are answered the same day, with the model, the price and a test drive offered. - **Book the test drive.** The car, the salesperson and the time are booked, and the customer is reminded on the day. - **Follow up every quote.** A quote that has not been answered is followed up, and a lost deal is asked why, so the brand's lead report says what really happened. - **Pass on the fleet enquiries.** A company asking for several vehicles goes to the fleet team with what was asked, the models and the quantities, the same day. [See quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) ### Warranty and recalls: Every claim complete, every owner reached Is every claim complete before it is submitted? - **Check the claim before it goes.** The job card, the chassis number, the mileage in and out, the photos and the failed part's tag are checked against the brand's rules before the claim is submitted on its portal. - **Keep the failed part until it is released.** Each part kept for a claim is logged with its location, so it is there when the brand asks for it and scrapped only when the brand says so. - **Do the campaign work in the same visit.** A car booked for a service that is also in an open recall or service campaign gets the campaign work on the same visit, with the parts ordered ahead. - **Report the campaign's progress.** How many have been reached, booked and repaired, by branch, ready for the brand and for the authority that asks for it. ### Fleet and equipment: Every machine serviced before it stops Do fleet clients know when each machine is ready? - **Service by the hour, not the calendar.** Machine hours and mileage reported by the customer or the telematics trigger the service the contract covers, booked before the interval runs out. - **Send the technician with the parts.** A field visit is booked with the technician, the parts kit and the site's access rules, so the machine is serviced in one trip. - **Keep the fleet manager told.** Which units are in, what was found, when each is ready and what is due next, in one message, without the fleet manager having to chase. - **Bill the contract correctly.** Work inside the maintenance contract and work outside it are separated on the job, so the invoice matches what the contract says. ## Beyond the five teams Some of the work happens between visits: a trade-in to value, a registration to renew, cover that is about to end, and the survey the brand sends after every service. - **Trade-ins, valued and followed up.** A customer asks what their car is worth. The agent collects the details and photos for your used-car team's appraisal and follows up the offer. Every trade-in request gets an offer. - **Registrations renewed on time.** Where your branches renew registrations, the agent reminds the owner before the date, books the inspection and asks for what the renewal needs. Renewals done before they lapse. - **Cover that is about to end.** Owners whose warranty or service plan is about to end hear what it covers, what it costs to extend and what is due before it ends, if they have agreed to hear from you. Owners decide before the cover runs out. - **Feedback before the brand's survey.** After each visit the customer is asked how it went, and anything that went wrong reaches the service manager before the brand's own survey does. Problems fixed before they become a score. ## How it works at a dealer group 01 **Embed.** Our engineers sit with your service, parts and sales teams for a week and follow every enquiry to where it ended: answered, booked, called back, or dropped. That becomes the baseline and shows where to start. 02 **Build.** An agent reads what the customer wrote, then rules out every slot that will not do: the wrong bay for the job, no technician trained on the brand, the part not in stock before then. It offers what is left, and books the one the customer picks. 03 **Scale.** Brands, branches and customers sit on one record, so a campaign reaches every affected owner at once, wherever they bought and whichever branch they use, and each branch sees its own share of the work. 04 **Measure.** Missed calls, booked hours and the time a lead waits for its first answer, each against the week before we start, counted with your service and sales managers. ## A car waiting for a part is on the clock Rules in the Gulf already say how quickly an agency must find a part, when a customer gets a car while theirs is in the workshop, and how every owner in a recall must be reached, and regulators check them. The risk is not only the fine: it is the brand itself. Agents keep every vehicle off the road on the board: the part chased with the brand, the replacement car offered when the repair runs late, and the customer told each day. Vehicles off the road, waiting for parts. Each card is a vehicle, moving a column along as its part is found and fitted. The orange one is still waiting, with a replacement car given. [See service bookings](https://qantara.systems/solutions/service-bookings) ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your dealer management system and the manufacturers' portals, and answer customers on the channels they already use. - Dealer management system - Parts catalogues - Manufacturer portals - Telematics - WhatsApp Business - Email - CRM and leads - Workshop planning - Spreadsheets ## What dealer principals ask us **Can agents take phone calls?** Calls your branches answer stay with your team. A call they miss gets a message on WhatsApp straight away, in the customer's language, with the slots open at their branch. **Does it work across several brands?** Yes. Each brand keeps its own rules, catalogue, warranty terms and portal, and the agents work inside each one's, while customers and vehicles sit on one record across the group. **Do you connect to our dealer management system?** Yes, through its own interfaces, and to the manufacturers' portals your teams already use. Nothing is migrated, and your teams keep the screens they know. **Does the agent submit warranty claims?** No. It checks each claim against the brand's rules and prepares it, and your warranty administrator submits it on the brand's portal. **Will this replace our service advisers?** No. Advisers keep the customer at the counter and the decisions on the car. The agent takes the messages, the bookings and the reminders that keep them from the customer in front of them. **We sell machines, not cars. Does it fit?** Yes. Machines are serviced by the hour and often on site, so the agent books by hours and field visits instead of bays, with the same follow-up for the fleet manager. **Where do we start?** Most dealers start with service bookings at one branch, because missed calls and empty bays are easy to count with your team in a week. Parts and leads follow on the same record. ## Other industries - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with the calls your branches miss Tell us how bookings, parts and leads come in today and who answers them. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/automotive --- # Suppliers, schedules and the line kept moving For manufacturers and industrial companies. Agents chase suppliers, keep the plan current, keep every certificate on file and answer customers about their orders, around the systems that run your plant. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) One late part, two outcomes. Above, the slip is found on the day and pushes every step past the customer's date. Below, it is flagged in orange the day it moved, and nothing after it shifts. A late component is never just one delay. Agents catch it early, tell the right people and keep the plan current. ## What the agents do at a manufacturer Five teams carry an order from the supplier's part to the customer's site: procurement, planning, quality, sales and customer service, and, for makers of equipment, after-sales. Agents work alongside each of them, around your ERP, your plan and your lab. ### Procurement: Every input chased before the line needs it Which late delivery stops production next week? - **Chase by the production date.** Inputs are followed up by the day the line needs them, not the day the order was placed, so the resin for next week's run is asked about first. - **Watch the imported inputs.** Additives, films, spares and machine parts from Europe and Asia are followed through the forwarder as well as the supplier, so a ship that slips is seen early. - **Keep a second source ready.** For inputs that have stopped a line before, the second supplier's price and lead time are kept current, so switching is a decision, not a search. - **Plan around the closures.** Eid, the summer months and the holidays at your suppliers abroad are written into the follow-ups, so orders go out early enough. [See supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups) ### Planning: One plan everyone reads the same way Does everyone see the same plan today? - **Keep the plan current.** A part that slips, a machine that is down, an order that grows: each change reaches the plan the hour it happens, from wherever it was reported. - **Show what a change touches.** When a run moves, the planner sees the customer orders, the shifts and the materials that move with it before saying yes. - **Send the plan to the floor.** Each shift supervisor gets the day's runs, materials and changes on the channel they read, in Arabic or English. - **Plan the Ramadan and summer shifts.** Shorter hours and night shifts are written into the plan ahead, so capacity is not discovered on the day. ### Quality: Every certificate on file before the truck leaves Is every certificate on file before shipment? - **Check against the customer's own specification.** Where a customer's specification is tighter than the standard, each batch made for them is checked against theirs. - **Ask for the inputs' certificates.** A lot of resin, steel or additive is not used until its certificate of analysis is on file and matches the lot. - **Keep licences and marks in date.** Conformity certificates, product registrations and audit dates are tracked, and the renewal starts while there is time to arrange the audit. - **Send the right certificate.** A customer asking for a certificate gets the one for their batch or shipment, not the latest one on file. ### Sales and customer service: Every customer told where their order is Can customers get an answer without calling planning? - **Say when it will be made.** A customer asking about an order hears the run it is in and the date it leaves, read from the plan, not a promise from memory. - **Warn before the date moves.** When a run moves, the customers on it hear the new date first, from the salesman they know. - **Confirm what can be made.** A new order is set against capacity and materials before the salesman promises a date. - **Say when it has left.** When the truck leaves the plant, the customer hears the time and the driver, so the site is ready to receive it. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ### After-sales and field service: Every installed machine serviced on time Which machines you installed are due for service this month? - **Know what you installed and where.** Each machine, its site, its running hours and its service history sit on one record, from the commissioning sheet on. - **Book the service before it is due.** Visits are booked by hours run or by date, with the parts the service needs reserved before the engineer sets off. - **Take the breakdown call in writing.** A customer reporting a fault on WhatsApp is asked for the model, the fault code and a photo, so the engineer brings the right part. - **Offer the contract at the end of warranty.** As a warranty ends, the customer is offered a service contract, only if they agreed to hear from you. [See service bookings](https://qantara.systems/solutions/service-bookings) ## Beyond the five teams Some of the work sits around the plant rather than on an order: the request to fix a machine, the file a big buyer keeps on you, the papers an export needs, and the figures a buyer abroad asks for about how something was made. - **Maintenance requests, logged and closed.** A request sent on WhatsApp from the floor becomes a work order with the machine, the photo and the urgency, and the person who raised it hears when it is done. No request lost in a chat. - **Your file with the big buyers.** Vendor registrations, trade licences, insurance and in-country value certificates that large buyers keep on file are tracked and renewed before they lapse. Never dropped from an approved list for a lapsed paper. - **Export papers, shipment by shipment.** Certificates of origin, packing lists and the buyer's own forms are prepared from the order and the batch, ready before the container is loaded. No container held for a paper. - **How it was made, for buyers abroad.** Fuel, power and output figures from your own records are gathered per shipment for buyers who ask how much energy went into what they bought, for your team to check. The figures ready when the buyer asks. ## How it works at a manufacturer 01 **Embed.** Our engineers walk the plant with procurement, planning and quality for a week, and trace each late shipment back to where it started. That becomes the baseline and shows where to start. 02 **Build.** An agent checks every part of the next run's bill of materials against stock and open orders, so a missing part is found days before the run, not at the line. 03 **Scale.** The record extends to quality, maintenance and customer updates, then across your plants, so a supplier that is late to one is watched for all of them. 04 **Measure.** Late deliveries, schedule changes and the hours spent chasing, against the weeks before we start, counted with your plant manager. ## No mark, no sale More of what Gulf plants make now needs a conformity mark or certificate before it can be sold, and the evidence behind it, test results, batch records, audit findings, sits in the plant's own systems and on paper. A lapsed licence or a missing certificate stops a shipment, and every order behind it. Agents keep the evidence and the paperwork moving together, so a mark or a certificate is never what holds a truck at the gate. A batch checked against its standard. Readings inside the band pass. The orange one outside holds the batch for a person; the retest passes, and only then is the certificate signed. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ## Built around the systems you run Nothing has to be replaced to start. Agents work around your ERP, read your plan, your lab results and your maintenance records, and write to suppliers and customers on the channels they already use. - ERP - Plant and MES systems - Lab and quality - Maintenance - Supplier portals - Email - WhatsApp Business - Production plan - Spreadsheets ## What plant managers ask us **Will agents change anything on our machines?** No. Agents work on the business side: suppliers, plans, papers and customers. Nothing is sent to a machine or a control system. **Can it work with our ERP?** Yes, through the interfaces your ERP already has, whichever it is. Where the plan lives in a spreadsheet, the agent works from the spreadsheet until it does not. **What if our customers' specifications differ?** Each customer's specification is kept with their orders and their product codes, so a batch is always judged by the one it was made for. **Our buyers in Europe ask for emissions figures. Can agents help?** The figures come from your own records of fuel, power and output, and agents gather them per shipment for your team to check. **Can agents call our suppliers?** Suppliers are written to on WhatsApp and email, in Arabic or English. **Does it work across several plants?** Yes. Each plant keeps its own lines and plan, and suppliers, customers and certificates sit on one record across them. **Where do we start?** With the inputs that stopped a line in the last quarter, followed with your procurement and planning teams for a week. ## Other industries - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. ## Start with the part that stopped the line Tell us which input held up your last run and who chased it. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/manufacturing --- # Every invoice right the first time For finance teams invoicing in Saudi Arabia, Oman and the UAE. Agents check every invoice against the rules of the country it is issued in, send it through your provider and write the answer back, inside the systems you already run. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) Every invoice checked before it is sent. Each invoice passes three checks on its way to your provider. One fails on the buyer's details, goes back to your team with the reason, and passes once fixed. A rejected invoice is cash that waits. We put agents on the checks before an invoice leaves and the corrections after, so the cash keeps moving. ## What the agents do around every invoice Four teams in finance handle an e-invoice: the one that issues it, the one that knows the rules, the one that receives supplier invoices and the one that closes the month. Agents work alongside all four, inside your ERP and your e-invoicing provider. ### Accounts receivable: Nothing leaves that the authority would send back How many invoices come back rejected, and who fixes them? - **Check every invoice before it leaves.** The agent checks the buyer's tax number and address, the tax category and rate, and the totals and rounding, against the rules of the country the invoice is issued in. - **Hold what would be rejected, and say why.** If something would fail, the invoice is held back. Whoever can fix it, in billing, sales operations or account management, gets the field, the rule it breaks and what to change. - **Issue credit notes against the original.** Every credit or debit note points to the invoice it corrects and gives the reason. Leaving either out is a common reason a credit note is sent back. - **Report counter sales on time.** Simplified invoices from branches and counters are reported within the window the authority sets, instead of piling up until the end of the month. ### Tax and compliance: Each company on its own rules, from its own date Which of our companies is in scope, from when, and under which rules? - **Map every company in the group.** For each legal entity: its country, revenue band, mainland or free zone, the date it has to be live and the provider it uses. Worked out with your tax adviser and kept in one place. - **Keep the checks up to date.** When an authority publishes a new rule, a new field or the next wave, the checks are updated before the date, and every change is logged. - **Watch certificates and providers.** Each invoicing unit signs with a cryptographic stamp that expires. The agent tracks when, and which provider each company is appointed to, so nothing lapses unnoticed. ### Accounts payable: Supplier invoices matched before they are paid Does every supplier invoice match the order and the delivery before anyone pays it? - **Read supplier invoices as data.** Structured invoices are read line by line, instead of someone re-typing a scan into the ERP. - **Match the order and the delivery.** Quantities, prices and tax are checked against the purchase order and the goods receipt. - **Check the supplier's tax details.** The tax number, category and amount are checked, so the input tax you reclaim is backed by a valid invoice. - **Query what does not match.** The supplier gets the line, the difference and the credit note you need, on the channel they use. Everything that matches is posted for the payment run. ### Accounting: The ledger, the provider and the VAT return agree Does our VAT return match what the authority already has? - **Reconcile the ERP with the provider.** Every invoice posted has an answer from the provider, every answer belongs to an invoice, and anything still pending has a name next to it. - **List the exceptions every morning.** Rejected, pending and unanswered invoices, company by company, with who owns each one and why, before the day starts. - **Build the VAT return from what was reported.** Sales and output tax come from the invoices the authority has already seen, so the return matches the records it holds. - **Keep the file for the auditor.** Every check, hold, correction and answer is kept by company, ready for a tax audit or a question from the authority. ## With your customers and suppliers E-invoicing changes what you need from the companies you trade with, and what they ask of you. Agents handle those conversations on WhatsApp and email, in Arabic and English, and keep every reply on the record. - **Customer details, collected before your date.** Every e-invoice needs the buyer's correct tax number and address. The agent asks each customer for them, checks the format and updates the customer record in your ERP, well before the first invoice has to go out. Every customer record complete before your date. - **Suppliers moved onto e-invoices.** Some suppliers will keep sending PDFs and paper. The agent tells each one how to send you an e-invoice instead, follows up until they do, and lets your payables team know who is still outside. Your supplier list, moved over one supplier at a time. - **Customers' questions about their invoices.** Where is my invoice, can you send it again, which tax number did you use, why is the amount different? The agent answers from the invoice record, on the channel the customer used, and passes anything unusual to your team with the conversation. Answered in the customer's language, with the right copy attached. - **Disputed invoices, closed properly.** Once an e-invoice is accepted it cannot simply be cancelled. When a customer disputes a price or a quantity, the agent gathers the order, the delivery note and the conversation, sends the case to the account manager, and drafts the credit note once it is agreed. Every dispute on the record, from the first message to the credit note. ## How it works in e-invoicing 01 **Embed.** Our engineers sit with billing, tax and payables and go through a month of invoices with them: what came back and why or, for a company whose date is still ahead, what its new rules would send back. Sorted by reason, that becomes the baseline and shows where to start. 02 **Build.** An agent reads each invoice as it is posted, checks it against the customer record and its country's rules, sends it through your provider and writes the answer back onto the invoice in your ERP. Nobody logs into a portal to find out what happened. 03 **Scale.** Everything each invoice used and produced stays on one record. Credit notes, supplier invoices and the month end build on it, and so does the next company in the group, under its own country's rules. 04 **Measure.** Rejected invoices, hours spent on corrections and days from delivery to an accepted invoice, each against the month before we start, reviewed with your finance team. ## One group, three sets of rules In Saudi Arabia a business invoice is cleared by the authority before the buyer receives it. In the UAE and Oman it travels between accredited providers, and its tax data is reported to the authority on the way. Each company in your group is checked against its own country's rules, on its own date. One group, three countries' rules. One agent checks each invoice against its own country first. Then the routes part: cleared by the authority, or passed from provider to provider. ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your ERP and the e-invoicing provider each company already uses, and write every answer back where your team looks. - ERP and accounting - E-invoicing providers - Banking feeds - Spreadsheets - Email - WhatsApp Business - Customer and supplier portals - Shared drives ## What finance teams ask us **Do you replace our e-invoicing provider?** No. Your provider, or the solution you already integrated with the authority, keeps signing and sending. The agent works in front of it, checking each invoice before it goes, and behind it, writing each answer back into your ERP. **Which countries do you cover?** Saudi Arabia, Oman and the UAE: any company in your group that invoices there, each checked against its own country's rules and format, from its own date. Other countries are added when their rules are published. **What happens when a rule changes?** The checks change, not your ERP. The change is drafted when the authority publishes it, approved by your tax lead, logged, and live before the date it applies from. **Who fixes an invoice that is held?** Whoever owns the data. The agent names the field, the rule and the fix and sends it to billing, sales operations or the account manager. Where the fix changes a customer record, a person approves it first. **Our companies are in free zones. Does this apply to them?** Often, yes. Scope follows the legal entity and what it supplies, not only where it is licensed. We map each company with your tax adviser before anything is built: in scope or not, from which date, through which provider. **Can agents check our supplier invoices too?** Yes. Supplier invoices arrive as structured data, and the agent matches each one to the purchase order and the goods receipt before it is posted, so the tax you reclaim sits on an invoice that matches. **Do agents send anything to the authority on their own?** Only what passes the checks you approved, through your provider. Anything above your threshold waits for a person, and every submission is logged with what was sent and what came back. ## E-invoicing in your industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with last month's invoices Tell us which company in your group has the next date, or where invoices come back most often. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/e-invoicing --- # Every request quoted, followed up and booked For sales and operations teams in freight, distribution and automotive. Agents read every request, price it from your own rates, send it for approval where it needs one, follow it up and book what the customer accepts. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) The clock on one quote. The dial runs from the request to the quote being sent, and its centre names the step. The blue mark is when the same quote goes out today. A request left waiting is an order someone else takes. We put agents on every request, so none of them waits. ## What the agents do around every quote Five desks touch a quote before it becomes a booking: the one that answers requests, the one that sets prices, the one that has to deliver, the one that extends credit and, if you bid for public work, the tenders team. Agents work alongside all five, inside the systems you already run. ### Sales: Every request answered, even the incomplete ones How many requests got no answer last month, and who would know? - **Ask for what is missing.** A request often arrives without something the price depends on: the delivery site, the quantity, the model or the date. The agent asks for exactly that, once, on the channel the customer used, and quotes when the answer comes. - **Keep one thread per customer.** The same buyer writes on WhatsApp, emails the next morning and messages a salesperson directly. The agent puts it together as one request, so the customer gets one quote and not three. - **Answer when nobody is in.** A request that comes in after hours, on a day your office is closed or in the shorter working days of Ramadan is acknowledged at once, and its quote is ready for the first person in. In a group, the offices may not even share a weekend. - **Revise without starting again.** When the customer asks for a better price, another quantity or another date, the agent prepares the revision against the first quote and records what changed and why. ### Pricing: Every price from the list in force today Are we still quoting from last month's prices? - **Price from the version in force.** Price lists, rate sheets and surcharges change, sometimes from one week to the next. The agent prices from the version in force on the day, gives the quote a validity that matches it, and says which charges can still move. - **Apply each customer's agreement first.** Contract prices, volume tiers and agreed discounts come before the list price, so a key account gets its own price without anyone opening a spreadsheet. - **Hold the margin rule.** A price below your floor or a discount beyond its band goes to whoever your delegation of authority names, up to the general manager or the owner, with the margin, the customer's history and the last price they accepted. - **Reprice open quotes when costs move.** When a price list, a surcharge or an exchange rate changes, the open quotes that used the old one are found and flagged before the customer accepts them. ### Operations: Nothing promised that cannot be delivered Can we deliver what we just quoted, by the date we promised? - **Check before the quote promises.** Stock on hand, space with the carrier, a vehicle in the allocation or a bay in the workshop: checked before the quote names a date. - **Turn the acceptance into a booking.** The accepted quote becomes the booking, sales order or reservation in your system, with every line exactly as quoted. - **Ask for what the booking needs.** Shipping instructions, the delivery site and its receiving hours, the papers for an import permit: requested with the confirmation and chased until they arrive. - **Confirm, then hand over.** The customer gets the confirmation with your reference. The warehouse, the carrier or the workshop gets what it needs to start. [See orders and confirmations](https://qantara.systems/solutions/orders) ### Credit control: Every quote safe to accept Did we just quote a customer who is over their limit? - **Check the account before the price.** The open balance, overdue invoices and the credit limit come from your ERP. A customer on hold gets a quote with payment in advance, or the request goes to credit control first. - **Put the right terms on the quote.** Credit, advance payment or a letter of credit, by customer and by amount, as credit control set them, written on every quote so nobody promises terms they cannot give. - **Issue the pro forma from the quote.** When a buyer needs a pro forma invoice for a letter of credit, an import permit or a payment in advance, it is issued from the accepted quote, line for line. - **Say the currency and the VAT.** Each quote is in the customer's currency and says plainly whether VAT is in the price, with the treatment your tax adviser set for the country of supply. A price that says nothing about VAT can be read as including it. [See collections](https://qantara.systems/solutions/collections) ### Tenders: Every tender read before it closes Which tenders closed last month without a bid from us? - **Watch the portals every day.** New tenders and requests for quotation on the government and company portals you are registered on, matched to what you sell. - **Read the documents for the decision.** Scope, closing date, bid bond, the documents required and the deadline for questions, summarised for the person who decides whether to bid. - **Prepare the file.** Your commercial registration, certificates, the local content documents where they are asked for, and the price schedule in the buyer's format, in Arabic where the buyer requires it. - **Keep every date.** Questions, extensions and the closing date are tracked. Your team submits the bid, and the result is recorded with the winning price where it is published. ## Beyond the five desks Some of the work around a quote happens away from the desks: with salespeople on the road, between the companies in your group, with the brands you represent and with customers who said no. - **Prices for the team on the road.** A salesperson in a customer's office sends a voice note asking for a price. The agent answers while the meeting is still going, with the price, the stock and how far the discount can go. Your field team quotes on the spot, inside your rules. - **One buyer, several of your companies.** In a group, two companies can quote the same customer for the same goods. The agent sees both quotes on the record, keeps the prices and terms consistent, and tells both sales heads when they clash. One price for one customer, across the group. - **Leads passed on by your brands.** Manufacturers and principals pass on leads from their own sites and campaigns. The agent answers each one in the brand's tone, quotes from your list and keeps the record the brand asks you to show. Every lead from a brand answered, with the proof it was. - **Lost quotes, asked why.** When a quote is turned down or lapses without an answer, the agent asks the customer what decided it, once, and records the reply: the price, the date, the terms or another offer. A reason on every lost quote, instead of a guess. ## How it works for quotes and bookings 01 **Embed.** Our engineers sit with sales, pricing and operations and go through a month of requests with them: where each came in, how long the answer took, who followed it up and whether it was won. That becomes the baseline and shows where to start. 02 **Build.** An agent takes each line from its source: the items from the request, the prices from your list, the discount from the customer's terms, the VAT from the country's rules. A line outside your rules waits for the person who signs it off, then the quote goes out. 03 **Scale.** Revisions, wins and losses stay on one record for each customer, with the reason. Their next request, the order, the invoice and the next branch start from what it already knows. 04 **Measure.** Requests answered, quotes won and the time from request to quote, each against the month before we start, counted with your sales team. ## The invoice starts at the quote An e-invoice carries the buyer's legal name, tax number and address, and it is checked before the buyer has it. A tax number in the wrong format or a required field left empty gets it rejected, and once issued it cannot be edited, only reversed with a credit note and issued again. A new customer often gives those details first when they ask for a quote. Agents take them there, check them and carry them to the order and the invoice. The buyer's details, carried to the invoice. Taken once on the quote and checked there, in orange, the details slide into the order and then the invoice, so it is accepted first time. [See e-invoicing and compliance](https://qantara.systems/solutions/e-invoicing) ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your ERP, your CRM and the price lists you keep, and answer on the channels your customers already use. - ERP and accounting - Price lists - Forwarding software - CRM - Email - WhatsApp Business - Tender portals - Dealer systems - Spreadsheets ## What sales teams ask us **What if our prices live in people's heads?** Then the first weeks write them down. Our engineers sit with whoever prices today and turn what they know into lists and rules the agent can use. Anything the rules do not cover still goes to them. **Will this damage our customer relationships?** Your salespeople keep their customers. The agent answers what is routine, the same way every time and in your company's name, and hands anything that needs a person to the account manager with the whole conversation. **Can the agent negotiate?** Only inside what you allow: another volume tier, another validity, other payment terms. A counter-offer beyond your rules goes to the person you name, with the customer's message attached. **Which channels do requests come in on?** WhatsApp Business, email, web forms and customer portals, in Arabic or English. Each request is answered where it was asked, in the language it was asked in. **Do you replace our CRM or ERP?** No. Quotes, bookings and orders are written into the systems you already run, through their own interfaces. Your team keeps the screens it knows, and nothing is migrated. **Do agents submit tenders?** No. The agent watches the portals, reads the documents and prepares the file. Your team decides whether to bid and submits it. **Where do we start?** With the requests of one branch or one product line, timed for a month with your team. The agent goes first to the desk where they waited longest. ## Quotes in your industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. ## Start with the requests nobody answered Tell us where requests come in today and who answers them. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/quotes-and-bookings --- # Every order acknowledged, confirmed and tracked For order desks and customer service in distribution, trading and manufacturing. Agents take orders from every channel into your ERP, check stock and credit, confirm in the customer's language and keep the customer told until delivery. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) Four orders, one way into your ERP. Each order arrives in its own shape, goes through the agent along the orange line and lands as the same sales order. The bottom line confirms each one back. An order is only as right as the last person who typed it. We put agents on every order: entered once, checked before it is confirmed. ## What the agents do around every order Four desks touch an order between the first message and the delivery: the one that takes it, the warehouse that fills it, credit control that can stop it and customer service that answers for it. Agents work alongside all four, inside the systems you already run. ### Order desk: Every order in, however it was sent How many orders are still sitting in someone's phone? - **Acknowledge it at once.** The customer gets a reply as soon as the order lands, in the language they wrote in, saying what was understood. Nobody has to wonder whether the order was seen. - **Read the purchase order, whatever its layout.** Each chain and contractor sends its own format: a PDF, a spreadsheet, a download from their portal. The agent reads the lines, the delivery address and their order number, and keeps their number on your sales order. - **Enter it once, in your ERP.** The sales order is created with your item codes, your units and the customer's price list. The warehouse, the driver and the invoice all read that one entry. - **Hold back what looks wrong.** A quantity far above what the customer usually takes, a price they should not have or an address that has never been delivered to is shown to the order desk before anything is confirmed. [See quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) ### Warehouse: Nothing confirmed that the shelf cannot fill Which orders did we confirm that the warehouse cannot fill? - **Count what is already promised.** A line is checked against stock on hand less what other open orders have already taken, not against the stock figure alone. - **Reserve it the moment it is confirmed.** Confirmed lines are reserved in your ERP straight away, so two customers are never promised the same last cartons. - **Promise a date the route can keep.** The delivery date comes from the route plan, the vehicle's capacity and the customer's receiving days, not from a standard lead time. - **Hand it over ready to pick.** The warehouse gets the order with its lines, the delivery window and anything the customer asked for, so nobody has to call the order desk to ask. ### Credit control: No order held without a reason Which orders are on credit hold this morning, and why? - **Check the account with the order.** The open balance, the overdue invoices and the limit are read from your ERP when the order arrives, not when the truck is being loaded. - **Hold it with the reason.** An order over the limit is held with one line for credit control: what is overdue, what is open and what would let it go. - **Tell the salesman before the customer.** The salesman who owns the account hears about the hold first, with the figures, so the conversation with the customer is theirs to have. - **Move it the moment it is cleared.** A payment matched or a decision from credit control sends the order on to the warehouse, and the customer hears that it is moving. [See collections](https://qantara.systems/solutions/collections) ### Customer service: Customers told before they have to ask Who tells the customer when an order is going to be late? - **Say when it leaves.** When the order is loaded, the customer gets the delivery window on the channel they ordered on, in their language. - **Say it is late before they notice.** A supplier that ships late, a vehicle off the road or a line still held changes the date. The customer hears the new one first, with what is still on time. - **Answer to their reference.** A chain asks about its own purchase order number, a contractor about the site. The agent finds the order from whichever reference the customer uses. - **Record what came back short.** A short or damaged line is logged against the order with the photo, and the credit note or the replacement goes to the person who approves it. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ## Beyond the four desks Some orders do not arrive as one message from one customer: the ones that repeat every week, the ones under a contract, the ones a brand pays part of and the ones between your own companies. - **The weekly order, ready before they ask.** Many customers order the same things on the same day each week. The agent prepares the usual order from their history and sends it for a yes, a change or a skip. Regular customers order with one reply. - **Call-offs against a contract.** A customer with a supply contract orders against it in instalments. Each call-off is checked against the contract's prices and what is left to call off, and the account manager hears when it runs low. Every call-off inside its contract. - **Promotions on the orders they were meant for.** Free goods, bundle prices and trade promotions from the brands you carry are applied to the orders that qualify, and recorded for the claim back to the brand. No promotion missed, and none given twice. - **Orders between your own companies.** When one company in your group buys from another, the sales order on one side becomes the purchase order on the other, with the same lines and prices. One order, entered once, on both sides. ## How it works for orders 01 **Embed.** Our engineers follow a day of orders with your team, from the first message to the delivery note: who typed each one again, where, and what was lost when they did. That becomes the baseline and shows where to start. 02 **Build.** The customer orders, adds a line, drops another and moves the day, across a morning of messages. An agent keeps it as one sales order, changes it line by line as each message arrives, and checks a new day against the route before it agrees. 03 **Scale.** Every branch's orders and stock sit on one record, so an order one branch cannot fill is checked against the others before anyone says no, and the transfer is booked with it. 04 **Measure.** The time from each order to its confirmation, and the orders corrected after they were invoiced, each against the month before we start, counted with your order desk. ## A changed order is a new offer A confirmation that changes the order, a smaller quantity, a later date, another brand, is not the customer's yes: it is a new offer, and they have not agreed to it. A quick reply on WhatsApp, or goods accepted at the door, can still turn it into the order, and the argument starts at the invoice. Agents set every confirmation beside the order it answers, name each line that changed and wait for the customer's yes before the order goes ahead. The order and its confirmation, line by line. Matching lines get an equals mark. The changed line is marked in orange, and the agent asks the customer before anything is confirmed. ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your ERP and your stock, read the purchase orders your customers send, and answer on the channels they already order on. - ERP and accounting - Stock and warehouse - Price lists - Route planning - WhatsApp Business - Email - Customer portals - EDI and purchase orders - Spreadsheets ## What order desks ask us **Can our customers keep ordering on WhatsApp?** Yes. Customers order the way they do today, on WhatsApp, by email, through their portal or through your salesmen, in Arabic or English. Nothing changes on their side. **What happens to an order the agent cannot read?** It goes to the order desk with what was understood and what was not, and the customer is asked only for what is missing. **Who confirms the order?** The agent, inside the rules you set: stock available, the account in order, the price from the right list. Anything outside them waits for the person you name. **Will customers know they are dealing with an agent?** They should, and we set it up that way. The agent writes in your company's name and says what it is, and a customer who wants a person gets one, with the thread. **What if a customer orders something we do not carry?** The customer hears straight away, with the nearest item you do carry if your team has named one. Nothing is substituted without their yes. **Do you replace our ERP?** No. Orders are written into the ERP you already run, through its own interfaces. Your team keeps the screens it knows, and nothing is migrated. **Where do we start?** With one channel or one branch, followed for a day with your team. The agent starts where an order is typed again most often. ## Orders in your industry - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. ## Start with the orders typed twice Tell us where orders come in today and who types them into your ERP. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/orders --- # Payments followed up on schedule, every time For finance teams and owners who sell on credit. Agents follow up every open invoice in the customer's language, record each promise and dispute, match what is paid and bring your team the cases that need a person. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) Six open invoices, followed up on time. Each row is a customer. The dots are reminders sent as today, the blue line, passes; what came back is at the end of the row. Orange went to your team. A late payment is often just an invoice nobody asked about. We put agents on every open invoice, so each one is asked about on time. ## What the agents do around every open invoice Four desks touch the money between the invoice and the bank: credit control, which asks for it, cash application, which finds it when it comes, the people who settle disputes, and whoever keeps the cheques and notes held as security. Agents work alongside all four, inside the systems you already run. ### Credit control: Every invoice asked about at its moment Which customers have heard nothing from us since their invoice fell due? - **Keep a rhythm for each customer.** A courteous note before the due date, a reminder on it, firmer ones after: the cadence your team sets for each kind of customer, kept for every invoice, large or small. - **Write as your team would.** In Arabic or English, on WhatsApp or by email, with the invoice, the delivery note and the statement attached, in the tone you use with that customer. - **Hold the customer to their word.** A promise to pay is recorded with its date and amount. On that date the bank is checked, and a promise that slips is followed up the same morning. - **Hand over with the whole thread.** An account that stops answering, or owes more than your threshold, goes to the person you name with every message, promise and document in one place. ### Cash application: Every payment matched to what it pays How much in the bank is not matched to an invoice yet? - **Read the bank every morning.** Transfers, cheques cleared and card settlements are read from your bank feeds, with the payer's name as the bank shows it, which is rarely the name on the account. - **Match one transfer to many invoices.** A customer who pays a month's invoices in one transfer, or part of one invoice, is matched line by line, using their remittance advice when they send one and asking for it when they do not. - **Find whose money it is.** A payment nobody can place is matched from the amount, the reference and the customer's history, and asked about before it sits unapplied for a month. - **Close the loop with the customer.** The customer is told what their payment was applied to, so their statement and yours agree before the next reminder goes out. ### Disputes: Disputes settled, the rest still collected How much is overdue only because something is in dispute? - **Find the paper behind the complaint.** A short delivery, a price that differs from the order or a missing purchase order number is checked against the signed delivery note, the order and the price list. - **Fix the cause, not only the case.** The same complaint from the same customer, branch or route, month after month, is shown to the person who can fix it at the source. - **Put it with the person who can settle it.** Sales, the warehouse or the driver gets the dispute with the evidence, and a date by which an answer is due. - **Close it with the right document.** A credit note against the original invoice, a replacement delivery or a corrected invoice, issued once and sent to the customer with the outcome. [See orders and confirmations](https://qantara.systems/solutions/orders) ### Cheques and notes: Every cheque and note in one register Which cheques fall due this week, and which notes would still hold up? - **Register what you hold.** Post-dated cheques, promissory notes and guarantees are entered with the customer, the bank, the date and the invoices they cover, the day the salesman hands them in. - **Present each one on its date.** The cheques due each day are listed for the bank run, and each is matched to its invoices when it clears. - **Act the day one comes back.** A returned cheque reaches credit control with the account, the other cheques that customer has given and what your policy says to do next. - **Keep guarantees in date.** Bank guarantees and credit limits that rest on them are listed before they expire, so the customer is asked to renew while there is still time. ## Beyond the four desks Some money is owed in ways that do not fit a reminder: through a buyer's portal, held back until a project is handed over, on a statement the customer disputes as a whole, or under a credit insurance policy with its own deadlines. - **Invoices on a buyer's portal.** Government bodies and large groups pay through their own portals, where an invoice moves through approval stages. The agent follows each one's stage and tells you which are stuck, and at whose desk. No invoice lost inside a buyer's approvals. - **Retentions, asked for at handover.** On contracts that hold back part of each payment until completion, the agent keeps the retention on the record and asks for it with the handover documents when the work is accepted. Retentions collected, not forgotten. - **Statements that agree.** When a customer's ledger and yours differ, the agent sets one against the other, finds the missing payments, credit notes and duplicates, and sends a reconciled statement. One balance both sides accept. - **The credit insurer, told on time.** Policies ask for overdue accounts to be reported within their own deadlines. The agent tracks each policy's dates and prepares the notice with the history attached. Cover kept, because the insurer heard in time. ## How it works for collections 01 **Embed.** Our engineers go through a month of open invoices with your finance team: which were asked about, by whom and when, and which were never asked about at all. That becomes the baseline and shows where to start. 02 **Build.** An agent reads each reply against the invoice. When a customer disputes one line, it checks the signed delivery note, sets that line aside for the person who settles it, and keeps asking for the rest. 03 **Scale.** When the same customer buys from several of your companies, the record adds up what they owe all of them. Credit is decided on the whole, and each company hears it at once. 04 **Measure.** What is overdue, by how long, against the month before we start, with the hours your team spends chasing, counted with finance. ## The paper behind your credit is changing Much of the credit in Gulf trade is secured with paper: post-dated cheques, promissory notes, bills of exchange. The rules on what each one lets you do when a customer does not pay are being rewritten, country by country, and a note signed on paper years ago may not do what you expect. Agents keep a register of every instrument you hold, check each one against the rules where it was signed, and ask customers to replace the ones that need it, well before they are needed. The cheques and notes you hold, checked. Each instrument is read in turn: a check means it is in order, an orange ring that it was signed only on paper and has to be reissued. ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your ERP and accounting, read your bank feeds, and write to customers on the channels they already answer. - ERP and accounting - Bank feeds - Cheque register - CRM - WhatsApp Business - Email - Buyer portals - E-invoicing - Spreadsheets ## What finance teams ask us **Will this damage our customer relationships?** A reminder on time, in the customer's language and with the right papers attached, is usually welcome. The tone is yours to set, and the accounts you name stay with the people who manage them. **Which accounts stay with our team?** The ones you choose: key accounts, government buyers, anyone above a balance you set. For those the agent prepares the statement and the history, and your team makes the call. **Does the agent call customers?** It writes, on WhatsApp and by email, in Arabic or English, and prepares the call for whoever on your team makes it. **What happens when a cheque comes back?** Your policy decides what happens next, and the agent prepares it: the letter to the customer, the request for a replacement, or the file for your lawyer. **Is it worth it if our customers pay in the end?** Paying in the end is the cost: the cash is late, and the reminders it took came out of your team's week. **Do you replace our ERP or our bank?** No. Promises, disputes and matches are written into the ERP you already run, and the bank is read, never instructed. Your team keeps the screens it knows. **Where do we start?** With a month of one company's open invoices, read with your finance team, and the channel your customers already answer on. ## Collections in your industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with the invoices that wait longest Tell us how open invoices are followed up today and who does it. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/collections --- # Every booking made, reminded and kept For service managers and dealer principals. Agents answer booking requests on the channels customers use, book the right bay and technician, send the reminders and refill every cancellation, across every branch. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) A week of service bookings. Each square is a slot, coloured by the channel the booking came on; the dot is the reminder the day before. Orange is a cancellation refilled from the waiting list. An empty bay in the morning is revenue the day never gets back. We put agents on every booking, so the week fills and stays full. ## What the agents do around every booking Four desks touch a booking between the request and the next visit: reception, which takes it, workshop planning, which makes it work, customer care, which keeps it, and field service, for work done at the customer's site. Agents work alongside all four, inside the systems you already run. ### Reception: Every request booked, whenever it comes How many booking requests wait until someone is free? - **Book outside opening hours.** A request sent at night, on a weekend or in the shorter days of Ramadan gets its slot then, not when reception opens. - **Ask what the job needs to know.** The symptom, the mileage or machine hours, a photo of the warning light: asked once, in the customer's language, so the workshop knows what is coming. - **Price the routine work up front.** Services on your fixed-price menu are quoted with the booking, so the customer knows the cost before they arrive. - **Confirm with what to bring.** The confirmation says where to go, when to arrive and what to bring, with your booking reference. [See quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) ### Workshop planning: Every slot matched to a bay and a technician Which bookings will arrive to find no bay, no technician or no part? - **Book by bay and by skill.** A job needing a lift, an alignment bay or a technician trained on the brand is booked where those exist, not wherever there is a gap. - **Keep room for what walks in.** Space is held back each day for walk-ins and cars that come back, at the share your service manager sets. - **Pick the parts before the car arrives.** The parts for tomorrow's booked jobs are listed for the store tonight, and a booking whose part is missing is moved before the customer sets off. - **Move bookings when a technician is out.** When someone is off sick, the bookings they had are moved to whoever can do them, and the customers who have to change are told first. ### Customer care: Every booking kept, or given to someone else How many bays stood empty this week because someone did not come? - **Remind where they read it.** Each reminder goes on the channel the customer actually answers, in their language, at the time of day they tend to reply. - **Keep the waiting list honest.** Customers who asked for an earlier slot are kept in order with the days and times they can really do, so a freed slot goes to someone who will come. - **Follow up who did not come.** A customer who did not turn up is asked what happened and offered a new time, without a tone that blames them. - **Book the next visit at collection.** When the car or machine is collected, the next service is proposed for its date or mileage, and booked if they say yes. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ### Field service: Every visit planned around the route How much of a field technician's day is spent driving? - **Plan the route, not only the visit.** Visits are booked into the technician's day by where they are, so the day is spent at sites, not between them. - **Plan around the heat and the site.** Outdoor work is booked outside the midday break in the summer months, and each visit carries the site's access hours and contact. - **Say when the technician is on the way.** The customer hears when the technician sets off and when they will arrive, and hears again if that changes. - **Close the visit on the job.** The work done, the parts used, the photos and the customer's signature come back to the job the same day, ready for the invoice. ## Beyond the four desks Some bookings do not come one at a time from one customer: the car you collect from the door, a fleet's whole programme, a season's checks, and the bookings the brand sends you from its own app. - **Collected from the door.** For customers who want the car collected, the agent books the driver, the pick-up time and the return, and sends the photos taken at collection. Collection and return on the same booking. - **A fleet's programme, booked in one go.** A fleet manager sends the list of vehicles due. The agent spreads them across the weeks so the fleet keeps enough on the road and the workshop is never swamped. A whole fleet serviced without a day off the road. - **Checks before the summer.** Before the heat, customers who agreed to hear from you are offered an air-conditioning and cooling check, booked into the quieter days. The quiet weeks filled before the busy ones. - **Bookings from the brand's app.** Requests from the manufacturer's app and site reach your system as bookings, answered in the brand's tone and recorded the way the brand asks. Every booking the brand sends, kept. ## How it works for service bookings 01 **Embed.** Our engineers stand at your service desk for the first hours of the day and count what arrives, what is dealt with, and what is still waiting when the bays are already full. That becomes the baseline and shows where to start. 02 **Build.** An agent sends the reminder the evening before and asks for a reply. A yes confirms the slot, a no frees it for the waiting list, and silence gets one more message in the morning before the slot is offered on. 03 **Scale.** Workshop bookings and field visits sit on one plan across branches and vans, so a new request goes to the nearest place, or the nearest technician's route, that can take it. 04 **Measure.** How full the bays are through the week, the bookings kept and the ones refilled, against the weeks before we start, counted with your service manager. ## A reminder that sells needs a yes A message about a booked visit is service. The same message with a discount on tyres is marketing, and marketing needs the customer's consent and an easy way to stop. Regulators in the Gulf are drawing that line more firmly, and the businesses that send reminders are the ones it catches. Agents keep the two apart: reminders go to every customer with a booking, offers only to those who said yes, and every consent and every withdrawal is kept on the record with its date. Who gets the reminder, and who gets the offer. The reminder reaches everyone with a booking; the offer reaches only those whose offers switch is on. One customer says stop, and their switch turns off, in orange. [See customer inquiries](https://qantara.systems/solutions/customer-inquiries) ## Built around the systems you run Nothing has to be replaced to start. Agents book inside your dealer or workshop system, read the bays, technicians and parts you already plan with, and answer on the channels your customers use. - Dealer or workshop system - Workshop planning - Parts stock - Field service - WhatsApp Business - Email - Brand booking apps - CRM and consent - Spreadsheets ## What service managers ask us **Can agents answer the phone?** Calls your team answers stay with your team. A call they miss is written back to on WhatsApp straight away, with slots to choose from. **Does it work across branches?** Yes. Each branch keeps its own bays, technicians and hours, and each service manager sees their own list. **Can customers choose their technician?** If your planner allows it. A customer who asks for whoever did their last service is offered that technician's free slots first. **Will the agent overbook us?** No. It books only into the slots your planner has opened, and never past what a bay can take in a day. **Do customers get answers in Arabic?** Each customer is answered in the language they wrote in, Arabic or English, and the booking reaches your system in the language your team works in. **Do you replace our workshop system?** No. Bookings are written into the system you already run, through its own interfaces. Your advisers keep the screens they know. **Where do we start?** With one branch's bookings and reminders, counted with your team for a week. The agent starts with the missed calls and the empty slots. ## Service bookings in your industry - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with the bays that stood empty Tell us how bookings come in today and who makes them. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/service-bookings --- # Deliveries chased before they are late For procurement heads, buyers and planners. Agents follow up every open purchase order, confirm the dates, tell planning the moment one slips and match each delivery to its order when it arrives. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) Five open orders and the dates promised. Each flag stands at the date its supplier promised; the dashed line is the day production needs it. A flag that slides is a date that moved; orange moved past the need. A delivery date is a promise, and promises move. We put agents on every open order, so planning hears while there is still time to act. ## What the agents do around every purchase order Four desks touch a purchase order after it goes out: buying, which gets the promise, planning, which builds on it, stores, which receives what comes, and accounts payable, which pays for it. Agents work alongside all four, inside the systems you already run. ### Buying: Every order acknowledged and its date confirmed Which open orders has no supplier confirmed? - **Get the acknowledgement.** Each purchase order is acknowledged, and the supplier's proforma is read against it: a different quantity, price or date is flagged to the buyer before it becomes the delivery. - **Ask ahead of the date, not after it.** Follow-ups are set by the lead time and by how well each supplier has kept its word, so a slip is heard about while it is still a warning. - **Read the reply, whatever form it takes.** A voice note, a photo of a shipping schedule, a line in an email: the date and the quantity are taken from it and written on the order in your ERP. - **Keep the buyer for what needs a buyer.** Price, an alternative supplier, a hard conversation: those come to your buyer with the facts gathered, and the routine asking does not. ### Planning: Every slipped date reaches planning in time Which late delivery stops production next week? - **Set each date against the need.** Every promised date is read against the day the goods are needed: the production run, the customer's order, the delivery to site. - **Flag the slip with what it touches.** A date that moves past the need reaches the planner with the run, the customer orders and the stock it affects, not as a bare date. - **Bring the options with the facts.** Another supplier's stock, a part delivery, faster freight and what each would cost, gathered for the planner to choose from. - **Give sales the date to give.** When a slip reaches a customer's order, the salesman hears the new date to promise, not a guess, before the customer asks. [See orders and confirmations](https://qantara.systems/solutions/orders) ### Stores: Every delivery expected, checked and put away Does the store know what is arriving tomorrow? - **Know what is coming each day.** The supplier's shipping notice and packing list are read ahead, so the store knows what arrives tomorrow and how it is packed. - **Ask for the certificates with the goods.** Mill certificates for steel, analyses for chemicals and food, certificates of origin and conformity: asked for before the truck leaves, checked before the goods go to stock. - **Put rejected goods back on the supplier.** Goods that fail the check are sent back with the photos and the reason, and the replacement goes onto the order with its own date. - **Spread the trucks over the day.** Deliveries are booked into the store's hours, so the bay, the forklift and the people are free when each truck comes. ### Accounts payable: Every supplier invoice answered from the record How much of the week goes on suppliers asking when they will be paid? - **Answer when they will be paid.** A supplier asking about an invoice hears its status and the payment date from your ERP, in the language they wrote in. - **Agree the statement.** The supplier's statement is set against your ledger every month, and each difference is traced to the invoice or credit note behind it. - **Chase the credit note.** A credit note promised for a return or a price difference is followed up until it arrives and is posted. - **Catch the same invoice twice.** An invoice sent again by email after the original came on paper is recognised, and only one is paid. ## Beyond the four desks Some purchases do not go from one order to one delivery: imports behind a stack of shipping documents, goods sent straight to a project site, releases against a yearly agreement, and the one part a stopped machine is waiting for. - **Imports, through the forwarder.** For goods shipped from abroad, the agent follows the supplier for the documents and the forwarder for the vessel and the arrival, so the papers are ready before the container lands. No container waiting at the port for a missing paper. - **Deliveries to a project site.** Materials sent straight to a site are booked into the site's delivery windows, with the gate pass and the contact, and the site engineer hears when the truck sets off. No truck turned away at the gate. - **Releases against a yearly agreement.** Under a yearly price agreement, each release is placed against what is left on it, and the buyer hears before the agreed quantity runs out. The next agreement negotiated before the last one ends. - **The part a stopped machine needs.** When a machine is down, the part is asked for from every supplier that might hold it, and the answers come back side by side: who has it, the price, when it can be there. The machine running again sooner. ## How it works for supplier follow-ups 01 **Embed.** Our engineers sit with your buyers and planners for a week and follow the open orders: where each date is written, how often the copies disagree, and how many hours go on asking. That becomes the baseline and shows where to start. 02 **Build.** When goods arrive, an agent lays the delivery note over the purchase order. What matches is received; what is short stays open on the order, and the supplier is asked for the rest with a date. 03 **Scale.** Every buyer's open orders, for raw materials, packaging and spares, sit on one record against the day each is needed, so planning sees the few that will be late before anyone has to ask. 04 **Measure.** How late deliveries arrive, order by order, and the hours your buyers spend asking, against the weeks before we start, counted with your procurement head. ## New suppliers, promises with no history This year many Gulf buyers got goods moving again by ordering more, ordering earlier and turning to suppliers they had not used before, often nearer home. A new supplier's promise has no history behind it, and a date that moves is usually found out when the goods do not arrive. Agents record every promise and every arrival, so each supplier's record builds order by order and your buyers know whose dates to plan on. Each supplier's record, order by order. The tick is the date promised and the dot the day the goods came, so a long line is a late delivery. Orange is an open order whose date moved again. ## Built around the systems you run Nothing has to be replaced to start. Agents work inside your ERP's purchasing, read the supplier portals you already log in to, and write to suppliers on the email and WhatsApp they already answer. - ERP purchasing - Production planning - Warehouse and stores - Accounts payable - Supplier portals - Email - WhatsApp Business - Forwarders' tracking - Spreadsheets ## What procurement heads ask us **Do our suppliers need new software?** No. They get messages on the email and WhatsApp they already use, and on a portal only where your team already works through one. **Who negotiates with suppliers?** Your buyers. The agent gathers the facts for the conversation, the dates, the history and the alternatives, and never agrees a price or a change of terms. **What counts as a risk?** Your planners decide, item by item: how close to the day it is needed a date may come, and how long a supplier may stay silent, before someone is told. **Can the agent call a supplier?** Suppliers are written to on WhatsApp and email, and a call your buyer makes is noted on the order. **Will suppliers know they are dealing with an agent?** Yes. Messages come from your purchasing team's assistant, signed as such, and a supplier who wants a person is passed to the buyer. **Can it place purchase orders?** It sends only orders your buyer has approved. Drafting them from your reorder rules is a separate step that you can switch on later. **Where do we start?** With the open orders for one category, the ones that stop production when they are late, followed with your buyers for a week. ## Supplier follow-ups in your industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with the order that stops the line Tell us which deliveries hold up your work today and who chases them. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/supplier-follow-ups --- # Every customer question answered from your own record For customer service heads and owners. Agents answer where an order is, what a statement says and what a charge is for, from the systems you run, in the customer's language, and hand anything that needs a person to your team. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) One question, answered from four of your systems. Each drawer is a system, pulled out for the one fact it holds, and the reply is written from them. What no drawer holds goes to a person, in orange. Most questions customers ask already have an answer, somewhere in your systems. We put agents on finding it, so your team keeps the questions that need a person. ## What the agents do with every question Four desks take customers' questions: customer service, which takes most of them, sales, whose phones take the rest, accounts, for statements and papers, and complaints, for what went wrong. Agents work alongside all four, inside the systems you already run. ### Customer service: Every question understood, whatever form it takes How many questions wait until someone has time to look? - **Understand the question as it is asked.** A voice note in Gulf Arabic, a photo of a delivery note, English and Arabic in one line, Arabic written in Latin letters: each is read for what the customer wants to know. - **Find the customer, whatever number they write from.** A buyer writing from a new phone, a driver for a contractor, a branch manager: each is matched to the account and its open orders before anything is said. - **Answer at night and on Fridays.** Questions sent after the office closes, at the weekend or in the shorter Ramadan days get their answer then, not on the next working morning. - **Give everyone the same answer.** The customer, their salesman and your branch hear the same date, because all three are answered from the same record. [See orders and confirmations](https://qantara.systems/solutions/orders) ### Sales: Every routine question off the salesman's phone How much of a salesman's day goes on answering instead of selling? - **Answer price and availability.** The customer's own price and what is on the shelf at their branch, read from the price list and the stock, not from memory. - **Repeat the last order.** "Same as last time" is read as the customer's last order, shown back to them line by line before anything is placed. - **Bring customers to the company number.** Customers who write to a salesman's own phone are moved to the company's number, with the salesman still in the conversation, so the history stays with you. - **Brief the salesman before a visit.** Before the call, the salesman gets the customer's open questions, late orders and complaints, on one page. [See quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) ### Accounts: Every paper sent the moment it is asked for How long does a customer wait for a copy of an invoice? - **The statement as of today.** What is open, what has been paid and what is due next, taken from the ledger on the day it is asked for, in the customer's own references. - **Copies of any paper.** An invoice, a credit note, the delivery note signed at the door: found by any reference the customer gives and sent as it was issued. - **Certificates by batch or shipment.** A certificate of analysis, of origin or of conformity, matched to the batch or the shipment the customer bought, not the latest one on file. - **Explain a charge.** A line on an invoice the customer does not recognise is explained from the order, the price list and the delivery it came from. [See collections](https://qantara.systems/solutions/collections) ### Complaints: Every complaint owned until it is closed Which complaints are open, and who has each one? - **Log it with the evidence.** The photos, the delivery note and the order are kept with the complaint from its first message. - **Give it an owner and a date.** Each complaint goes to the person who can settle it, with the date your policy sets for an answer. - **Keep the customer told.** The customer hears who has it and when to expect an answer, and hears again if that changes. - **Flag the pattern.** The same complaint from several customers, a product, a route or a driver, reaches the manager who can fix the cause. ## Beyond the four desks Some questions are not one customer asking about one order: a container still on the water, a car in the workshop, a group chat with a customer's whole team, and the questions a chain's buyers send to a shared inbox. - **A container still on the water.** For forwarders' customers, the answer comes from the carrier's tracking and the customs status together, so "where is it" also says when it can be collected. One answer that covers the sea and the port. - **Is my car ready.** For dealers and workshops, the answer comes from the job card: what has been done, what is waiting for a part, the estimate to approve, and when to come. Fewer calls to the workshop floor. - **The customer's whole team in one group.** In a WhatsApp group with a customer's buyer, site engineer and accountant, each gets the answer to their own question, addressed to them. Nobody in the group asks twice. - **A chain's shared inbox.** A retail chain's buyers write from one shared address about many stores. Each question is matched to the store and the order it is about. Every store's question answered to its own order. ## How it works for customer inquiries 01 **Embed.** Our engineers sit with your customer service team for a week and sort every question by what it asks and where its answer lives. That week becomes the baseline and shows where to start. 02 **Build.** An agent answers what the record can answer. A question it should not answer, a refund, a damaged load, an angry customer, goes to the right person as the whole conversation, with the order and the photos, so the customer never repeats themselves. 03 **Scale.** WhatsApp, email, the portal and the salesman's notes become one history for each customer, across branches and companies. 04 **Measure.** How long customers wait for an answer, and how many ask again, against the week before we start, counted with your customer service head. ## "Let me check" now has a price A reply that says "let me check" answers nothing, and the customer waits for a second message and a third. Each one costs your team time and the customer patience, and on business messaging each reply can now carry a fee as well. Agents read the order, the warehouse and the delivery first, and answer once, completely, in the customer's language. Three replies, or one. Each row is one conversation through the day, and every reply sent is charged a coin. Today's answer takes three replies; the agent's takes one. ## Built around the systems you run Nothing has to be replaced to start. Agents read your ERP, warehouse and delivery systems for the answers and reply on the WhatsApp Business number and inboxes your customers already write to. - ERP and orders - Warehouse and delivery - Accounts and statements - Document store - WhatsApp Business - Email - Customer portal - CRM - Spreadsheets ## What customer service heads ask us **Can agents answer the phone?** Calls your team answers stay with your team, and a call they miss gets a written answer on WhatsApp. **What if the answer is not in our systems?** Then the agent says it does not know yet and passes the question to the person who does. It does not guess. **Will customers know they are talking to an agent?** Yes. Replies come from your company's assistant, signed as such, and anyone who asks for a person gets one. **Which languages does it answer in?** The language the customer wrote in, Arabic or English, including the two mixed in one message, and Gulf Arabic as it is spoken in voice notes. **Can it give a refund or a credit?** No. Refunds, replacements and credits are your team's decision, every time; the agent tells the customer once it is made. **What about our salesmen's own WhatsApp numbers?** Those stay theirs. Agents work only on your company's WhatsApp Business number; a salesman's own phone is never connected. **Where do we start?** With the question your team answers most, usually where an order is, on one channel for one branch, counted with your team for a week. ## Customer inquiries in your industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## Start with the question you answer most Tell us what customers ask your team every day and where the answers live. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/solutions/customer-inquiries --- What is it? One record of how your company runs, agents that work from it, a person above your thresholds, inside your borders, built on site. It is not a new system for your team to learn: the agents work inside the ones you already run. # One record, read and written by every agent. Our engineers build agents around the systems you already run. Every agent works from one record of how your company operates, acts within the limits you set, asks a person above them, and leaves a line in the log. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) ## The log of the example order above: one line for everything the agent read, did and asked. The last column names the page that shows each step. | Time | Actor | Action | Target | Approved by | Shown on | | --- | --- | --- | --- | --- | --- | | 09:02 | Orders agent | Read the customer, their prices and the stock | An order from a caterer, on WhatsApp | Not needed | The operating record | | 09:02 | Orders agent | Drafted the sales order | Sales order | Not needed | Agents | | 09:03 | Orders agent | Held it for a person: over the credit limit | Sales order | Waiting | Control | | 09:11 | Sales manager | Approved it on their phone | Sales order | Sales manager | Control | | 09:11 | Orders agent | Wrote it to the ERP and the record | Sales order | Sales manager | Connections | | 09:12 | Orders agent | Confirmed it to the customer on WhatsApp | Confirmation, for Thursday | Not needed | Agents | AI is only as useful as what it knows about how you operate. That is learned on site, and kept in one record. ## Six parts, one record in the middle The record sits in the middle. Agents read from it and write to it, connections reach the systems you run, your thresholds and the log sit beneath, all of it inside your country, held up by engineers until it stands on its own. - [The operating record](https://qantara.systems/platform/record): One memory of how your company runs. One memory of what moved, where, when, for whom and at what cost, written by your agents and your people. - [Agents](https://qantara.systems/platform/agents): The work, on the channels your customers already use, in Arabic and English. One narrow agent per process, working from the record within the limits you set. - [Connections](https://qantara.systems/platform/connections): Built around your ERP, customs, e-invoicing and messaging. Nothing replaced. How an agent reaches your systems: reading where the data already is, writing only what you allow. - [Control](https://qantara.systems/platform/control): Your thresholds, a person above them, and the log of every action. The limits you set for each agent, the person who decides above them, and the log of everything it did. - [Where it runs](https://qantara.systems/platform/where-it-runs): Inside your borders, and where each model runs, said plainly. Where the record, the logs and the documents are kept, and where each model runs, country by country. - [Engineers](https://qantara.systems/platform/engineers): On site until it stands on its own. What stays with you. The engineers who build inside your company, on site, until your team can run it alone. ## What every agent may do Four verbs, the same for every agent, whatever its process. - **Reads.** The record and your systems, where the data already is. - **Proposes.** The quote, the order, the reminder or the declaration, drafted for a person to see. - **Writes, within your thresholds.** To your systems and the record, only what you have allowed it to write alone. - **Asks, above them.** The person you named, with the case prepared and everything it read. ## In Arabic and English Customers write in the language they think in. The order in the example came in on WhatsApp, and the agent reads it and answers in the language it came in. A caterer, on WhatsApp: "Same as last week, plus ghee. Can it come Thursday?" ## Most companies here have tried AI. Few can point to the earnings. Across the Gulf, most companies have run a pilot, and few can show it in their results. The reasons given are security and whether the answers can be trusted, which is why every agent here works inside your thresholds and leaves a line in the log. ## What owners ask first **Do we have to replace our systems?** No. Agents are built around the ERP, the customs window, the e-invoicing provider, WhatsApp and email you already run, and write back only what you allow. [See connections](https://qantara.systems/platform/connections) **Does my team have to learn a new tool?** No. The agents work in WhatsApp, email and the screens your team already uses, and a person decides on their phone. [See agents](https://qantara.systems/platform/agents) **What can it do on its own, and what needs my sign-off?** Only what sits inside the thresholds you set: an amount, a customer, a country, an hour of the day. Above them, the agent prepares the case and the person you name decides. [See control](https://qantara.systems/platform/control) **Can I see every action it took?** Yes. Every action is a line in the log: what the agent read, what it did, who approved it and what happened next. [See the log](https://qantara.systems/platform/control) **What happens if it is wrong?** It cannot act above your thresholds, and every action is on the record with what the agent read. The person who approved saw what the agent saw, and the rule is fixed on site. [See control](https://qantara.systems/platform/control) **Where does my data sit, and where does the model run?** In your country, and we tell you where each model runs, workflow by workflow, before anything is built. [See where it runs](https://qantara.systems/platform/where-it-runs) **Will you be in my office, and will you still be here next year?** Yes, engineers work on site with the people who run the process, from the first week until your team can run it alone. [See engineers](https://qantara.systems/platform/engineers) **Does this get me through e-invoicing?** Agents check every invoice against your country's rules before it is issued, and route what would fail to your team with the reason. [See e-invoicing and compliance](https://qantara.systems/solutions/e-invoicing) ## See it in your industry - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. ## See it on your own records Tell us which process costs your team the most time. Our engineers take it from there, on site. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf Next: [The operating record](https://qantara.systems/platform/record) --- This is the Markdown twin of the page at https://qantara.systems/platform --- What is the operating record? One memory of what moved, where, when, for whom and at what cost, written by your agents and your people. It is not a new ERP; it sits beside the one you have. # One record of how your company runs. Every order, shipment, invoice, declaration and promise your agents and your people touch is written to one record: what moved, where, when, for whom, at what cost and why. The next agent starts from what the last one wrote. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) The record, filling one row at a time. Each row comes in from the channel on the left and says what moved, where, when, for whom, at what cost and why. The orange column is the one no ERP keeps. | What | Where | When | For whom | Why | Written by | | --- | --- | --- | --- | --- | --- | | Order confirmed | Sohar branch | Sun 08:40 | A caterer | Weekly order | Written by the orders agent, from a WhatsApp message. No approval needed: inside the thresholds. | | Delivery moved | Muscat warehouse | Sun 11:05 | A hotel group | Supplier late | Written by the supplier follow-ups agent, from the supplier's email. No approval needed. | | Invoice issued | Head office | Mon 09:20 | A caterer | Delivered in full | Written by the orders agent, from the delivery recorded in your ERP. No approval needed. | | Discount given | Dammam branch | Mon 14:10 | A contractor | Repeat buyer | Written by the sales manager, from their note of the call. Approved by the sales manager, above the agent's limit. | | Short delivery | Sohar branch | Tue 07:55 | A supermarket | Carton short, signed | Written by the orders agent, from a photo of the signed delivery note. Approved by the warehouse lead. | A decision made on a call leaves no record. Every agent writes one, so the next can read it. ## What is in it, and what may be done to it In the record: parties, orders, shipments, invoices, declarations, promises, thresholds, approvals, log entries. What an agent may do to it: reads, proposes, writes within your thresholds, asks above them. ## The next agent starts where the last one ended Nobody tells the collections agent an invoice went out. It reads the row the orders agent wrote, on the day your terms say, and the next agent after it reads both. Two agents, one record. The orders agent writes three rows. Nobody tells the collections agent about the invoice: it reads that row, along the orange wire, and writes its own. ## Whose record it is What an owner asks about the record before anything else: whose it is, where it lives, what it is not, and what each line of it keeps. - **Whose it is.** The record is to your operation what a spreadsheet is to its cells: ours is the software, the contents are yours, and you can take them with you whenever you like. - **Where it lives.** In your country. Where it is stored, and where each model that reads it runs, is set out country by country. [See where it runs](https://qantara.systems/platform/where-it-runs) - **What it is not.** This is not a dashboard. It is the record under every agent, kept beside your ERP rather than instead of it. - **What every line keeps.** Who wrote it, from which channel, and who approved it, so each line traces back to a message, a call or a person. ## In Arabic and English One row of the record, as your team reads it. The fields are the same in both scripts, so the agent that writes it and the person who checks it see the same thing. What: Order confirmed: ghee and oil; Where: Sohar branch; For whom: A caterer; Why: Their weekly order ## Today the record is a WhatsApp group A delivery note is printed, signed on a tailgate and photographed. The photo goes to a WhatsApp group, and someone types it into a spreadsheet the next branch never sees. The record already exists; it is scattered across phones. ## What owners ask about the record **Is this a new ERP?** No. It reads yours and writes back only what you allow; your ERP stays the place your accounts are kept. **Do we have to move our data into it?** No. Agents read where the data already is, and the record keeps what was done with it: what moved, for whom, and why. **Can the next company in the group use it?** What was learned carries to the next company, so it starts further on. Each company's data stays in that company's record. ## Where the record does the most work - [Orders and confirmations](https://qantara.systems/solutions/orders): Every order acknowledged and tracked. - [Collections](https://qantara.systems/solutions/collections): Payments followed up on schedule. - [Supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups): Deliveries chased before they are late. ## Start the record with one process The first workflow is the hardest. Every one after it starts from what the record already knows. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf Next: [Agents](https://qantara.systems/platform/agents) --- This is the Markdown twin of the page at https://qantara.systems/platform/record --- What is an agent here? A narrow piece of software for one process, built around your systems, that works from the record and answers to the limits you set. It is not a chatbot on your website. # Agents that work on the channels your customers use. One agent per process. It reads the record, answers on WhatsApp and email in Arabic or English, drafts what has to be sent, acts within your thresholds and asks a person above them. There is no new tool for anyone to learn. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) Your customers write in the language they think in, at the hour they think of it. Every message answered, in that language, from the record. ## Seven agents, one for each process Each agent does one process and nothing else. Its row says what it reads, what it proposes, what it writes within your thresholds, and when it asks a person. | Agent | Reads | Proposes | Writes, within your thresholds | Asks a person | Its work | | --- | --- | --- | --- | --- | --- | | Quotes agent | The request, your rates and your rules | The quote | The booking, once the quote is accepted | When a price falls outside your rules | [Quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings) | | Orders agent | Orders on WhatsApp, email and portals; stock and credit | The sales order | The order into your ERP, and the confirmation | When an order is over the customer's credit limit | [Orders and confirmations](https://qantara.systems/solutions/orders) | | Inquiries agent | The order and its delivery, in the record | The answer | The reply, on the channel the customer used | When anything is unusual: it hands over the thread | [Customer inquiries](https://qantara.systems/solutions/customer-inquiries) | | Collections agent | Open invoices, terms and payments | The reminder | Reminders on schedule, promises to pay, matched payments | When a customer disputes an invoice or breaks a promise | [Collections](https://qantara.systems/solutions/collections) | | E-invoicing agent | Each invoice, and its country's rules | The e-invoice | The e-invoice, once it passes the checks | When an invoice would be rejected, with the reason | [E-invoicing and compliance](https://qantara.systems/solutions/e-invoicing) | | Service agent | Booking requests, bay capacity and parts on hand | The slot | The booking and its reminder | When no slot fits, or the job needs an adviser | [Service bookings](https://qantara.systems/solutions/service-bookings) | | Supplier agent | Open purchase orders and supplier replies | The follow-up | Date changes, and deliveries matched on arrival | When a late delivery puts production at risk | [Supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups) | ## What an agent may do Four verbs, the same for every agent: it reads, it proposes, it writes within your thresholds, and above them it asks. An order over the limit takes all four. - **Reads.** Always. - **Proposes.** A draft for a person. - **Writes.** Within your thresholds. - **Asks.** Above them. ## The hard cases What customers here actually send, and what an agent has to read before it answers anyone. You will not see an accuracy number for any of it on this site. - **A voice note in Gulf Arabic.** A driver records the problem rather than typing it, in the dialect they speak, with the noise of the road behind it. - **Arabic in Latin letters.** Customers write Arabic with Latin letters and numbers, and change to English in the middle of a sentence. - **A photo instead of a message.** A stamped delivery note, a handwritten correction, a part number on a label: the message is the picture. - **The right model for each workflow.** No single model reads all of these well, so none is promised in advance. ## One conversation, turn by turn A service booking on WhatsApp, with what the agent did under each of its messages. It is an example written for this page, not a real customer's. - **A customer, 08:12:** Good morning. My pickup is due its service. Is there anything tomorrow morning? - **Service agent, 08:12:** Good morning. Tomorrow I can offer 10:00 or 11:30. The service takes about three hours. (Read the service history; Checked bay 2 and the parts; Two slots offered) - **A customer, 08:15:** 10:00 please. Can someone take me to the office while it is done? - **Service agent, 08:15:** Booked for 10:00 tomorrow in bay 2. I have asked the service adviser about a lift, and I will remind you this evening. (Booked 10:00 in bay 2; Asked the adviser about a lift; Reminder set for this evening; Booked; Logged) - **Service adviser, 08:31:** A driver will take you to your office at 10:05. (Approved by the adviser; Logged) ## In Arabic and English The conversation above, as the customer wrote it, in both scripts. The agent answers in the language the message came in. A customer, on WhatsApp: "Good morning. My pickup is due its service. Is there anything tomorrow morning?" ## Customers here write the way they speak Voice notes in dialect, Arabic in Latin letters, two languages in one sentence. That is what a Gulf customer sends, and it is what an agent has to read before it answers anyone. ## What owners ask about the agents **Will customers know they are writing to an agent?** Yes. It says so when asked, and a person is one message away. **What happens when it does not understand?** It asks, or hands the conversation to a person with everything it read. Nothing is guessed. **Can it make calls?** A call your team misses gets a message on WhatsApp straight away, in the customer's language. **Does it ever act outside its process?** No. One agent, one process, one set of limits. ## Where the agents talk to customers most - [Customer inquiries](https://qantara.systems/solutions/customer-inquiries): Every "where is my order" answered. - [Service bookings](https://qantara.systems/solutions/service-bookings): Every booking made, reminded and kept. - [Collections](https://qantara.systems/solutions/collections): Payments followed up on schedule. ## Pick the agent that pays first Most companies start with the process that costs the most time. The roster shows what each agent does. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf Next: [Connections](https://qantara.systems/platform/connections) --- This is the Markdown twin of the page at https://qantara.systems/platform/agents --- What is a connection? The way an agent reaches one of your systems: reading where the data already is, writing only what you have allowed, with its own login and its own permissions. It is not an integration project. # Built around the systems you run. Nothing is replaced. Agents read your ERP, your customs window, your e-invoicing provider, WhatsApp and email where the data already is, and write back only what you allow, after the checks you set. Your team keeps the tools it knows. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) Every system you run was bought to keep something safe. We leave it where it is and work inside it. ## Read where it is, never copied Most integration projects start by copying your data into a second system, which then has to be kept in step. An agent reads your ERP where the data already is, keeps a reference in the record, and writes back only past your threshold. A reference, not a second copy. On the left, the usual way: your data copied into a second system, struck through, with what a copy costs. On the right, the agent reads your ERP in place and keeps only a reference; what it writes back waits at your threshold, the orange ring, until a person approves. ## What it reads, writes and never touches One card per system, the same three lines on each. Your IT team sets the permissions behind every line before anything goes live. | System | Reads | Writes | Never | | --- | --- | --- | --- | | ERP and accounting | Customers, prices, stock and open invoices. | Sales orders and delivery notes, after approval. | Changes master data. | | Customs window | Nothing. | A declaration draft, for your broker. | Files on its own. | | E-invoicing | Your invoices. | The e-invoice, once it passes the checks. | Issues one that fails. | | WhatsApp Business | Messages from customers and suppliers. | Replies and reminders. | Messages a customer who has not consented. | | Email | The shared inbox. | Drafts and replies. | Deletes anything. | | Dealer management | Bookings, bays and parts. | A booking. | Moves a job without the adviser. | ## For your IT team The only technical part of the page: how each connection signs in, what it may reach, and who can switch it off. - **Its own login.** Each agent signs in with credentials of its own, never a person's, with the permissions your IT team chooses. - **Scoped and revocable.** Credentials are scoped to one deployment and yours to revoke at any time. Every read and every write is a line in the log. - **Built for each system.** Each connection is built during the embed, with your IT team, for the system it reaches. - **When a system has no interface.** Connections are built system by system during the embed, starting with the ones the first process needs. ## In Arabic and English The same order, as your ERP holds it and as the customer reads it on WhatsApp, in both scripts. ERP field: Sales order 4471: ghee, 12 cartons; WhatsApp reply: Your 12 cartons of ghee are confirmed for Thursday. ## Three countries, three filing deadlines, one record Saudi Arabia, the UAE and Oman each bring e-invoicing in on their own dates and their own rules, and every invoice reaches the authority through your e-invoicing provider. It is the connection every company here needs next, and the agent checks each invoice against its own country's rules before it goes. ## What IT teams ask **Do we need to replace our ERP?** No. The agent reads it and writes back only what you allow; your ERP stays where your accounts are kept. **Who gives the agent a login?** You do, with the permissions you choose. It never uses a person's login. **What if our system has no API?** We build the connection during the embed, system by system, with your IT team. **What if we change our ERP?** The record stays as it is, and the connection is rebuilt for the new system. **Will it slow our systems down?** It reads the way a person does, on a schedule you set, so your systems carry no more than a busy clerk puts on them. **What does it never touch?** Master data, payments, and anything you have not listed. It reads only what its process needs. ## Where the connections carry the most - [E-invoicing and compliance](https://qantara.systems/solutions/e-invoicing): Every invoice checked before it is issued. - [Orders and confirmations](https://qantara.systems/solutions/orders): Every order acknowledged and tracked. - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. ## Tell us what you run Name the systems and the processes, and our engineers come on site knowing which connections to build first. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf Next: [Control](https://qantara.systems/platform/control) --- This is the Markdown twin of the page at https://qantara.systems/platform/connections --- What is control here? The limits you set for each agent, the person who decides above them, and the log of everything the agent read, did and asked. It is not a dashboard to watch: it is a record you can open. # Your thresholds. A person above them. Every action logged. Each agent works within limits you set: an amount, a customer, a country, an hour of the day. Above them, it prepares the case and a person decides, on their phone, in their language. Every action is logged before anyone asks to see it. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) ## The log of the request above: written as each step happened, before anyone asked to see it. An example. | Time | Actor | Action | Target | Approved by | | --- | --- | --- | --- | --- | | 10:14 | Orders agent | Asked for a credit release | A contractor in Jeddah | Waiting | | 10:14 | Orders agent | Held it: above your limit | Credit release | Waiting | | 10:15 | Orders agent | Sent the case to the sales manager, with what it read | Credit release | Waiting | | 10:22 | Sales manager | Approved it on their phone | Credit release | Sales manager | | 10:22 | Orders agent | Released the credit in the ERP | Customer account | Sales manager | Nobody hands the keys to a system they cannot stop. You hold the thresholds: above them, every agent stops and asks. ## Where the line sits is yours Six requests from one week, drawn by size. Drag the line, or use the arrow keys: what reaches above it waits for a person, what stays under it goes through. Nothing you set here is saved. ## Who may do what Every role, the agent among them, has the same three answers for every action: alone, with approval, or never. This is an example; the matrix is yours to fill in. | Action | The agent | Sales manager | Finance manager | Owner | | --- | --- | --- | --- | --- | | Send a quote | Alone | Alone | Never | Alone | | Confirm an order | Alone | Alone | Never | Alone | | Release credit | With approval | With approval | Alone | Alone | | Issue an invoice | With approval | Never | Alone | Alone | | Message a customer | Alone | Alone | Alone | Alone | | Change a price | Never | With approval | Never | Alone | ## The log What the agent read, what it did, who approved it and what happened next, written as it happens, before anyone asks to see it. It is kept in the record and sent to your own systems when you want it. ## For the approver The log protects the person who approved, because it shows what they saw when they decided: the case, what the agent read, and the rule that sent it to them. ## In Arabic and English The approval reaches the manager in the language they work in, with the same case, the same rule and the same two answers. Approve a credit release for a contractor in Jeddah? Above your limit. Read: the account, the open invoices and the last payment. ## Control is the concern, not the idea Owners across the Gulf are not wary of what AI can do. They are wary of what it does when nobody is looking. A threshold, a person above it and a log that exists before anyone asks are the answer to that. ## What owners ask about control **What can it do without asking?** Only what sits inside the thresholds you set. The matrix on this page is an example; yours is filled in with you, action by action. **Can we stop it?** Yes. Above your thresholds every agent stops and asks, and the thresholds are yours to lower until everything goes to a person. **What if it is wrong?** It cannot act above your thresholds, and every action is on the record with what the agent read. The person who approved saw what the agent saw, and the rule is fixed on site. **Can we see every action?** Yes. The log is on the record, written as each action happens, and it can be sent to your own systems. **Does it act at night?** Only if you let it. The hour of the day is a threshold like any other. **Who is accountable?** One team: the engineers who built it, on site with you, and the Qantara team behind them. ## Where the thresholds do the most work - [Collections](https://qantara.systems/solutions/collections): Payments followed up on schedule. - [Quotes and bookings](https://qantara.systems/solutions/quotes-and-bookings): From request to confirmed booking. - [E-invoicing and compliance](https://qantara.systems/solutions/e-invoicing): Every invoice checked before it is issued. ## Decide what it may decide Bring the thresholds you would set today. We build the agent around them, and a person decides above them. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf Next: [Where it runs](https://qantara.systems/platform/where-it-runs) --- This is the Markdown twin of the page at https://qantara.systems/platform/control --- What does inside your borders mean? The record, the logs and the documents are stored and processed in your country. It is not a promise that nothing ever leaves: where a model runs abroad, we say so before anything is built. # Inside your borders. Your record, your documents and your logs stay in your country. Where a model runs is said plainly, workflow by workflow, and you see it before anything is built. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) ## Where does the model run? Where your data is kept is one answer. Where the model that reads it runs can be another, and it is the one most often left out. We give both, for each workflow, before anything is built. Operations data is the most sensitive data a company has. We treat it that way by default. ## How your data is handled ### 01 Kept: Kept together, in your country The record, the documents it was written from and the log of every action are kept in one place, in your country. Where exactly is agreed with you in writing, before anything is built. ### 02 Read: Each workflow's model, said plainly A model reads the work in order to do it. Before a workflow goes live you get it in writing: what the model reads, which of it is personal data, and where that model runs. ### 03 Reached: Read only by the people you name Each person and each agent reads the part of the record their work needs, and nothing else. Every look and every change is a line in the log, so you can see who read what, and when. ### 04 Leaves: Nothing crosses without paper Nothing leaves your country unless a workflow needs it and you have agreed to it. Each country asks for its own paper before personal data crosses its border; we prepare it with you. ## In Arabic and English The table's columns, as your legal and IT teams will read them, in both scripts. Country, Stored in, Model runs in, Paper a transfer needs, Last verified ## What legal and IT teams ask **Where does the model run?** Where we tell you, workflow by workflow, before anything is built. **Our bank has rules about our data. Do they apply?** Some sector rules reach your suppliers as well as you. Bring them, and the deployment is built inside them. **What paper do we need to send anything abroad?** It differs by country and by the kind of data. We prepare it with you, country by country, before anything is sent. ## Where residency matters most - [Logistics and freight](https://qantara.systems/solutions/logistics): Quotes, bookings, customs and delivery, on time. - [Manufacturing and industrial](https://qantara.systems/solutions/manufacturing): Suppliers, schedules and the line kept moving. - [E-invoicing and compliance](https://qantara.systems/solutions/e-invoicing): Every invoice checked before it is issued. ## Bring your data rules Your legal and IT teams can send us their questions before anyone visits. We answer in writing. [Talk to the team](https://qantara.systems/contact) / [Email us](mailto:hello@qantara.systems) Muscat and across the Gulf Next: [Engineers](https://qantara.systems/platform/engineers) --- This is the Markdown twin of the page at https://qantara.systems/platform/where-it-runs --- What is a forward-deployed engineer? An engineer who builds inside your company rather than from a distance: on site, with the people who run the work, accountable for the result. It is not a consultant, and not a support desk. # Engineers on site until it stands on its own. A named engineer works on your premises with the people who run the process, builds the agent around your systems, measures it against your numbers and stays until your team runs it alone. [Talk to the team](https://qantara.systems/contact) / [Read the thesis](https://qantara.systems/original/thesis) The frame comes away, and the arch holds. The dashed frame is our engineers, there from the first week. The stones are what they build with you, set one by one; the orange keystone is the record. When it is set, the frame comes away and the arch stands on its own. ## The four steps: what happens in each, who is there, what is written down, and what you see at the end of it. | Step | What happens | Who is there | What is written down | What you see at the end | | --- | --- | --- | --- | --- | | Embed | The engineer sits with the people who run the process and maps how it really runs | The engineer, and the people who run the work | How the work moves today, and the baseline | The baseline, agreed, and the process to start with | | Build | The first agent is built around your systems and tried on real cases | The engineer and your team | The connections, the thresholds and the rules | The agent working on real cases | | Scale | The next process is added on the same record | The engineer, your team and the next process's owner | The next process's map and thresholds | Two processes on one record | | Measure | The numbers are read against the baseline | The engineer, your leadership and the people who run the work | The numbers against the baseline | What changed, in your own numbers | Software fails at the last mile. We walk it with you, then hand you the keys. ## How the engineers work, step by step ### 01 Embed: Sit with the people who run the work A named engineer works on your premises beside the people who run the process, writes down how it really runs, and records the baseline before anything changes. - What was learned each day, written down for you - How the work moves across your ERP, email, calls and messaging - The baseline, agreed with you before anything changes ### 02 Build: Build the first agent on real cases The engineer builds the agent around your systems and your thresholds, and your team tries it on real cases as it takes shape. Nothing in your systems changes. - Connections built system by system - Thresholds set with the people who approve - Tried by your team on real cases ### 03 Scale: Add the next process on the same record The second agent starts from what the first agent wrote, so it is built on what the record already knows. Branches and group companies follow, one at a time. - The next process, chosen with you - The same record and the same log - Branches and group companies added one at a time ### 04 Measure: Read the numbers against the baseline The numbers are read the same way as the baseline from the first week, and reviewed with the people who run the work. The agent is tuned until they move. - The same numbers as the baseline, read the same way - Reviewed with the people who run the work ## Who comes, and when we step away The questions an owner asks before letting anyone in: who it is, for how long, when they leave, and what they are there for. - **Who comes.** A named engineer for your company, from Muscat, on site for the embed and the build, with the Qantara team accountable alongside. - **For how long.** For the embed and the build, then as often as the work needs, until your team can run it alone. - **When we step away.** When your team can set a threshold, read the log and add a case without us. We train them for exactly that. - **What we are not.** We are not the product. The record is. We are the frame that holds it while it is set. ## In Arabic and English The engineer's note at the end of a day of the embed, as your team reads it, in both scripts. The engineer's note, day two: "Orders reach the sales team on WhatsApp and are typed into the ERP by hand. Many need a call back for a missing item code." ## Someone has to be there at the start of the working day Companies here buy on references and pilots, and a pilot tests how the people behind the software behave when something goes wrong as much as it tests the software. That is learned in the room, at the start of the working day, not from a distance. ## What owners ask about the engineers **How long are you on site?** For the embed and the build, then as often as the work needs. **Who is accountable?** One named engineer, and the Qantara team behind them. **Can our IT team run it?** Yes. That is the condition for us stepping away, and we train them for it. **Can we build the next agent ourselves?** Your team learns to add cases and set thresholds during the build. A new agent is work we do with you. ## Where the engineers have the most to learn - [Automotive and heavy equipment](https://qantara.systems/solutions/automotive): Bookings, parts and customers followed up. - [Distribution and trading](https://qantara.systems/solutions/distribution): Orders confirmed, delivered and collected. - [Supplier follow-ups](https://qantara.systems/solutions/supplier-follow-ups): Deliveries chased before they are late. ## Someone has to build the bridge We named the company after it. Tell us where to start. [Talk to the team](https://qantara.systems/contact) / [Back to the overview](https://qantara.systems/platform) Muscat and across the Gulf --- This is the Markdown twin of the page at https://qantara.systems/platform/engineers --- # Intelligence is abundant. Deployment is scarce. Manifesto. The Qantara team, Muscat, 14 October 2026. The models will keep getting better and cheaper. None of them will walk into a warehouse at seven in the morning, read a delivery note signed on a tailgate, and know what the stamp means. That is the work. This is what we believe about it. ## 1. A model knows the world. It does not know your company. Every few months a better model arrives, and the one before it gets cheaper. That race is real, and it is not ours to run. What no model arrives with is how one company actually runs: which supplier is always late, which approval is a formality and which is not, what a note in the margin of a delivery note means. That knowledge lives in people and is written down nowhere. AI is only as useful as what it knows about how you operate, and that is learned in one place: on site, inside the work. ## 2. The Gulf can skip a step. In the West, AI arrives as an upgrade to software that already runs the company. Much of the Gulf's operating work took another road: a delivery note signed on a tailgate and stamped, a shortage written in Arabic in the margin, a photograph sent on WhatsApp, a decision made on a call that leaves no record. That is not a failing of the people who run it. They have kept their companies moving for years with the tools they had. It means that for much of the work there is nothing to migrate and nothing to rip out. AI can be the first system the work runs on. ## 3. The hard part is deployment, so we do it in person. The obstacles are not in the model. Arabic and English share the same form. The data has to stay in the country. Companies buy on references and pilots. Someone has to be there when the working day starts. So our engineers work on site, inside the operation. They write down how the work really runs and record a baseline before anything changes. We bring in the right AI from Silicon Valley for each workflow, build the agents around the systems already there, and stay until the team runs it without us. ## 4. Arabic is not a setting. People in the Gulf write the way they speak: in dialect, with English words in Arabic script and Arabic words in Latin letters, in voice notes and in photographs of handwritten pages. A model tuned only on formal Arabic misses much of how the business actually writes. We build for the way people really write and speak. Every agent is run on the customer's own past cases, in Arabic and English, with their team marking what good looks like, before it touches live work. ## 5. Every deployment should make the next one easier. Too many AI projects end as a demonstration that worked once. The difference between a project and a system is memory. Every agent we deploy writes to one operating record of how the company runs: what moved, where, when, for whom, at what cost, and why. We think of it as an arch. Each deployment is a stone. Our engineers are the frame that holds the stones while they are set, and the record is the keystone. Once it is in place, the frame comes away and the arch carries itself. ## 6. Trust is written down before it is asked for. An agent earns its login the way a new colleague does: by being accountable for everything it does. - Each agent signs in with credentials of its own, scoped to one deployment and revocable at any time. - Every read and every write it makes is a line in the log. - Above the thresholds you set, a person approves. - The record and its log stay in your country. - For each workflow, we state in writing which model reads what, and where it runs. And we are judged on your own numbers, read the same way before and after. If the number does not move, the work is not done. ## 7. We say what will not work, before anyone pays. In the Gulf, a decision at the top of a family group reaches many companies at once, and a reference travels further than any advertisement. A deployment that fails is remembered for years. So we tell people what will work and what will not before they pay for it, we do not call a pilot a result, and we would rather lose a project than deliver one that does not work. It is also why we publish what we learn. The research below is free to read and to check: every number in it is quoted from a cited source or computed by code we publish. If we are wrong, you can show us where. ## 8. Hold us to it. Three questions will tell you whether we have done what this page says. - Before we build: what is the baseline? It should be written down, in your numbers. - While it runs: what did the agent read, what did it do, and who approved it? The answer should be in the log. - At the end: can your team set a threshold, read the log and add a case without us? If not, we are not finished. Intelligence will keep getting cheaper. The work will not do itself. We are building the bridge between the two, in Muscat and across the Gulf. ## Research and writing Surveys, technical reports and guides on putting AI to work inside Gulf companies. Every number is from a cited source or from code we publish. - [Arabic language models for Gulf operations: a 2026 survey](https://qantara.systems/insights/arabic-language-models.md) (Survey, 14 October 2026): Which Arabic text and speech models can carry a Gulf company's orders, messages, voice notes and documents, what the leaderboards measure, and what licences and hosting allow. - [How the Gulf writes: Arabizi, code-switching and dialect in business messages](https://qantara.systems/insights/how-the-gulf-writes.md) (Research, 14 October 2026): What operational messages in the Gulf really look like, what the research says about reading them, and what that asks of an AI agent that acts on them. - [Compounding agents: evaluation and A/B testing on live operations](https://qantara.systems/insights/compounding-agents.md) (Technical report, 14 October 2026): How an operational agent gets better month after month without putting the business at risk: what to test on past cases, what to test on live work, and how many cases each answer needs. - [Inside the workflow engine: durable execution for operational agents](https://qantara.systems/insights/workflow-engine.md) (Technical report, 14 October 2026): How we build agents that carry an order across three days and five systems without losing it, doing it twice or doing it unseen. - [Right-sizing models: routing between small and frontier models](https://qantara.systems/insights/right-sizing-models.md) (Research, 14 October 2026): Most steps in an operational workflow do not need the largest model: how to send each one to the smallest model that does it well, and why Arabic changes the arithmetic. - [The operating record: a data model for how a company runs](https://qantara.systems/insights/operating-record.md) (Technical report, 14 October 2026): One line per event, written by agents and people, kept beside the ERP, and traceable to the message, call, document or person it came from. - [Generating complex and realistic benchmarks through evolutionary data degradation](https://qantara.systems/insights/evolutionary-data-degradation.md) (Research, 14 October 2026): A search that makes Gulf business documents harder to read one defect at a time, and checks at every step that the answer can still be recovered. - [From pilot to production: why AI stalls in Gulf operations](https://qantara.systems/insights/pilot-to-production.md) (Report, 14 October 2026): What public surveys say about the distance between an AI pilot and AI in production, why that distance is longer in Gulf operations, and what the evidence says shortens it. - [AI and personal data in the GCC: a country-by-country guide](https://qantara.systems/insights/gcc-personal-data.md) (Guide, 14 October 2026): What each Gulf data protection regime asks before an AI agent reads personal data: the law and its dates, the regulator, the lawful bases, the rules for sending data abroad, the breach clock, and where the cloud and the model actually run. - [WhatsApp is the Gulf's operating system](https://qantara.systems/insights/whatsapp-operating-system.md) (Research, 14 October 2026): We argue that in much of Gulf trade, orders, complaints, delivery proof and payment reminders arrive as chats, voice notes and photos on one app; this paper weighs the evidence, sets out Meta's rules for businesses, and describes what an agent has to do to work there. - [The Gulf will skip the software era](https://qantara.systems/thesis.md) (Essay, 8 October 2026): Much of the Gulf's operating economy never went through the software era. In the West, AI is an upgrade to a system that already exists; here, it can be the first system. ## Tell us where to start. Write to our team about the work you would fix first, or about anything in the research. [Talk to the team](https://qantara.systems/contact) Canonical: https://qantara.systems/insights --- # Arabic language models for Gulf operations: a 2026 survey Survey. Qantara Research, Qantara. 14 October 2026. 15 min read. > Which Arabic text and speech models can carry a Gulf company's orders, messages, voice notes and documents, what the leaderboards measure, and what licences and hosting allow. ## Abstract Which Arabic language and speech models can an agent rely on when work arrives as a Gulf-dialect WhatsApp message, a voice note or a scanned invoice? We surveyed the Arabic-centric and Arabic-adapted models released between August 2023 and October 2026, reading their technical reports, model cards and licences, and the benchmarks used to rank them, as published on 14 October 2026. Open-weight models built for Arabic in the Gulf now rank alongside multilingual models several times their size on native Arabic benchmarks. Most of those benchmarks, however, test Modern Standard Arabic, some were translated from English or carry wrong answer keys, and a new Emirati benchmark finds models that understand the dialect but answer in the standard language. Speech is the weakest link: on one Saudi television test set, open recognisers get 48% to 93% of Gulf dialect words wrong, against 19% to 66% of standard Arabic words. Licences split the field into weights a company may host in its own country and models reachable only as a service. For Gulf operations, this means choosing a model per workflow, testing it on the company's own past cases, and hosting open weights in-country where data cannot leave. ## Key findings 1. Arabic-centric open models now compete at the top of native Arabic leaderboards: in Qimma's April 2026 ranking, Jais-2-70B-Chat placed third with 65.81, behind Qwen3.5-397B and Karnak [1]. 2. Most Arabic benchmarks measure Modern Standard Arabic, and their quality varies: the Open Arabic LLM Leaderboard dropped its machine-translated tasks in 2025, and Qimma discarded 3.1% of ArabicMMLU's questions as flawed [2, 1]. 3. Models understand Gulf dialect better than they write it: in TII's judged test, Falcon-Emirati-7B answered in Emirati with a fidelity of 0.52, against 0.05 or less for four other models [3, 4]. 4. Speech recognition is the weakest link: on the Sada test set, every system in the Open Universal Arabic ASR Leaderboard made more word errors on Khaliji speech than on Modern Standard Arabic [5]. 5. Licence and access differ as much as accuracy: Jais 2, Fanar and AceGPT publish Apache 2.0 weights, Aya and Command R7B Arabic weights are non-commercial, and ALLaM 34B and Falcon-H1-Arabic were reachable only as services when we checked [6, 7, 8, 9, 10, 11]. ## 1. Introduction The work of a Gulf distributor arrives in several kinds of Arabic at once: an order typed in Gulf dialect on WhatsApp with the product names in English, a voice note from a loading bay, a supplier invoice in Modern Standard Arabic and English, a customs declaration in formal Arabic. An agent that takes part in this work has to read all of it, reply in a register the customer accepts, and run where the company's data may be processed. Arabic is a case of diglossia (Two varieties of one language with different roles: in Arabic, Modern Standard Arabic for writing, news and formal speech, and the local dialect for everyday talk.), and Gulf operations happen on both sides of it. The question is newly answerable. Between December 2025 and October 2026 the Gulf's main laboratories released Jais 2, Falcon-H1-Arabic, Fanar 2.0 and Falcon-Emirati [12, 11, 13, 3], with new public tests of a Gulf dialect: Alyah for written Emirati [14] and Emirati speech results for Falcon-ASR [15]. Arabic remains scarce in training data, about 0.5% of the web by the Fanar team's estimate, despite 400 million native speakers [13], so what a model was trained on, and in which variety, matters as much as its size. Existing surveys describe Arabic models and benchmarks well [16, 17]. This one asks a company's question: which models can be trusted with which kinds of Gulf work, how far the published scores hold, and what licence and hosting allow. It contributes: 1. A dated inventory of 15 Arabic-centric and Arabic-adapted text models, August 2023 to October 2026, with organisation, sizes, licence and release date. 2. A reading of the main Arabic benchmarks and their known weaknesses. 3. A summary of the published evidence on Gulf dialect, in text and in speech. 4. What follows for choosing, testing and hosting a model per workflow. ## 2. Background and related work Al-Khalifa and colleagues trace Arabic language technology from morphological analysers to the large models that followed ChatGPT, among them Jais, ALLaM, AceGPT and Fanar [16]. They note two problems that recur here: because digital Arabic is scarce, many datasets are translated from English and carry its cultural assumptions, and models trained mainly on Modern Standard Arabic struggle with colloquial input. Alzubaidi and colleagues at the Technology Innovation Institute (TII) in Abu Dhabi review more than 40 Arabic benchmarks, keep a public list of them, and name three gaps: little evaluation over time, little of multi-turn dialogue, and cultural misalignment in translated sets [17]. Ouda's list for Silma AI, of March 2025, records more than 25 Arabic-capable models with sizes and licences [8]. Arabic speech recognition grew up on broadcast television. The Multi-Genre Broadcast challenges built MGB-2 from about 1,200 hours of Al Jazeera, mostly Modern Standard Arabic, then Egyptian and Moroccan sets [5, 18]. Gulf speech entered public benchmarks in 2024, with the Saudi Sada corpus [19] and the Emirati part of Casablanca [18]. The Open Universal Arabic ASR Leaderboard of Wang, Alhmoud and Alqurishi compares open recognisers across these sets and is our main speech source [5]. ## 3. Scope and method We included text models that are Arabic-centric (trained from scratch with a large Arabic share) or Arabic-adapted, by continual pre-training (Training an existing model further on new text, here mostly Arabic, instead of training a new model from scratch.) or tuning of a multilingual base, released from August 2023 to 14 October 2026 with a public paper, model card or announcement. Open multilingual models enter where Arabic leaderboards rank them; closed frontier models through the Arabic results their developers publish. For speech, we included public data and evaluations with Gulf content. Every source was read on 14 October 2026. We say when a number comes from the developer of the model it describes. Release dates are those of the first paper or weights; where a source gives none, we use the creation date of the model's Hugging Face repository. We ran no models. Arabizi, Arabic written in Latin letters, is left to our companion paper How the Gulf writes. ## 4. The model families **Figure 1. Arabic model releases and Gulf-dialect tests, August 2023 to October 2026** Read down: each entry is a public release, dated by month; the entries aimed at a Gulf dialect date from 2026. - Aug 2023: Jais 13B. An Arabic-centric model pretrained on Arabic and English, with open weights. - Sep 2023: AceGPT. Arabic localisation, aligned with a reward model attuned to local culture. - Oct 2024: Aya Expanse 8B and 32B. Cohere Labs: 23 languages including Arabic, under a non-commercial licence. - Jan 2025: Fanar Star and Fanar Prime. 7B and 9B models from Qatar, with dialect speech recognition. - Feb 2025: ALLaM 7B preview and Command R7B Arabic. Open 7B and 8B models from Saudi Arabia's SDAIA and from Cohere Labs. - May 2025: Falcon-Arabic 7B. TII adapts Falcon 3 with 32,000 added Arabic tokens. - Aug 2025: ALLaM 34B in Humain Chat. A service hosted in Saudi Arabia, without public weights. - Dec 2025: Jais 2, 8B and 70B. A custom Arabic vocabulary; dialects and Arabic-English code-switching. - Jan 2026: Falcon-H1-Arabic and the Alyah benchmark. Models naming Gulf among their dialects, and a benchmark for Emirati. - Mar 2026: Fanar 2.0, 27B. Continual pre-training of Gemma 3 on 120 billion curated tokens. - Apr 2026: Qimma leaderboard. Validates benchmark questions before ranking 46 models. - Oct 2026: Falcon-Emirati 7B and Falcon-ASR. A model specialised in Emirati, and a speech recogniser with Emirati results. Source: the papers, model cards and announcements cited in Table 1 and in the text [20, 21, 9, 22, 23, 24, 10, 6, 11, 14, 13, 1, 3, 15]. Months without a stated date are Hugging Face repository creation dates, read on 14 October 2026. ### Abu Dhabi: Jais and Falcon Jais, released in August 2023 by Inception, the Mohamed bin Zayed University of Artificial Intelligence (MBZUAI) and Cerebras, was a 13B model pretrained on Arabic, English and code [20], followed in 2024 by a family from 590M to 70B parameters under Apache 2.0 [8]. Jais 2 (December 2025, 8B and 70B) is, its authors write, to their knowledge the largest open Arabic-centric model trained from scratch, under a commercially permissive licence [12]. Its card lists a custom Arabic-centric vocabulary of 150,272 tokens and coverage of Modern Standard Arabic, regional dialects and Arabic-English code-switching, without naming the dialects [6]. Vocabulary matters for Arabic because of tokenizer fertility (The average number of tokens a tokenizer cuts a word into. A tokenizer built mostly for English splits Arabic words into more pieces, which raises cost and shortens the text a model can hold at once.). TII began by adapting its own models. Falcon-Arabic (May 2025) added 32,000 Arabic tokens to Falcon 3-7B and continued training on native, not machine-translated, Arabic [24]. Falcon-H1-Arabic (January 2026) builds on the hybrid Mamba-Transformer Falcon-H1 in 3B, 7B and 34B sizes, with contexts up to 256K tokens, trained on about 300 billion tokens; TII names Egyptian, Levantine, Gulf and Maghrebi among its expanded dialect sources [11]. Falcon-Emirati-7B (October 2026) specialises the 7B in Emirati with Emirati web text, Modern Standard Arabic writing on Emirati culture and synthetic Emirati text [3]. TII offers these through its chat service; we found no public weights for them in its Hugging Face organisation on 14 October 2026. ### Saudi Arabia and Qatar: ALLaM and Fanar ALLaM, from the National Center for AI at the Saudi Data and AI Authority (SDAIA), was presented in July 2024 and at ICLR 2025; its authors show that vocabulary expansion and mixed Arabic and English pretraining teach a model Arabic without catastrophic forgetting of English [25]. A 7B preview was released under Apache 2.0 [8]. ALLaM 34B, launched in August 2025 inside the Humain Chat app, is reported as built from scratch and hosted end to end in the Kingdom, with no mention of public weights [10]. Fanar, from the Qatar Computing Research Institute at Hamad Bin Khalifa University, paired a 7B model trained from scratch on nearly 1 trillion tokens with a 9B model continually trained from Gemma 2, alongside speech recognition for several dialects [22]; the 9B weights are under Apache 2.0 [8]. Fanar 2.0 (March 2026) centres on a 27B model continually pretrained from Gemma 3 on 120 billion curated tokens, built and run entirely at the institute, reporting 3.5 points gained on dialect benchmarks over Fanar 1.0 and a long-form speech recogniser [13]. Its card names Gulf, Levantine and Egyptian among supported dialects, under Apache 2.0 [7]. ### Cohere and other Arabic-tuned models Cohere Labs' Aya programme runs from Aya 101 to Tiny Aya, a 3.35B model for more than 70 languages [26]. Aya Expanse covers 23 languages including Arabic at 8B and 32B, and Aya Vision adds images, both under non-commercial CC-BY-NC 4.0 [9, 8]. Command R7B Arabic (February 2025), an 8B model, is described as optimised for Modern Standard Arabic and English, under the same licence [23]. AceGPT, from the Chinese University of Hong Kong, Shenzhen, with King Abdullah University of Science and Technology, localised an existing model with Arabic pre-training, native Arabic instructions and a reward model attuned to local culture [21]; its 32B second version ranks tenth in Qimma [1]. Silma 9B is built on Google's Gemma under Gemma's terms [8]. ### Frontier multilingual models Open multilingual models compete directly: Qwen3.5-397B leads Qimma with 68.06, and Llama-3.3-70B-Instruct scores 63.96 [1]. Closed models are measured on MMLU translated by professional translators: OpenAI reports 0.904 in Arabic for o3-high, against its 14-language average of 0.888 [27], and Anthropic reports Claude Sonnet 4.5 at 97.2% of its English score in Arabic [28]. These show that frontier models read formal Arabic well. They say nothing about a Gulf voice note or a reply in dialect, and no closed model appears in the Qimma or Alyah tables we read. **Table 1. Arabic-centric and Arabic-adapted text models, by release date** | Model | Organisation | Sizes | Licence | Released | | --- | --- | --- | --- | --- | | Jais | Inception, Cerebras, Mohamed bin Zayed University of Artificial Intelligence | 13B | Open weights | Aug 2023 | | AceGPT | Chinese University of Hong Kong, Shenzhen, with partners | 13B; 8B, 32B in v2 | Apache 2.0 | Sep 2023 | | Jais family | Inception, Cerebras, Mohamed bin Zayed University of Artificial Intelligence | 590M to 70B | Apache 2.0 | Aug 2024 | | Silma 9B | Silma AI | 9B | Gemma terms | Aug 2024 | | Aya Expanse | Cohere Labs | 8B, 32B | CC-BY-NC 4.0 | Oct 2024 | | Fanar Star, Prime | Qatar Computing Research Institute | 7B, 9B | Apache 2.0 (9B) | Jan 2025 | | ALLaM 7B preview | SDAIA | 7B | Apache 2.0 | Feb 2025 | | Command R7B Arabic | Cohere Labs | 8B | CC-BY-NC 4.0 | Feb 2025 | | Aya Vision | Cohere Labs | 8B, 32B | CC-BY-NC 4.0 | Mar 2025 | | Falcon-Arabic | TII | 7B | No public weights found | May 2025 | | ALLaM 34B | SDAIA, Humain | 34B | App only | Aug 2025 | | Jais 2 | Inception, Cerebras, Mohamed bin Zayed University of Artificial Intelligence | 8B, 70B | Apache 2.0 | Dec 2025 | | Falcon-H1-Arabic | TII | 3B, 7B, 34B | No public weights found | Jan 2026 | | Fanar 2.0 | Qatar Computing Research Institute | 27B | Apache 2.0 | Mar 2026 | | Falcon-Emirati | TII | 7B | Chat service only | Oct 2026 | From the sources cited in the text, read on 14 October 2026 [8, 23]. Dates for the Jais family, Silma 9B, Aya Expanse, ALLaM 7B preview and Aya Vision are Hugging Face repository creation dates; "No public weights found" records our search of TII's Hugging Face organisation that day. **Figure 2. What each model allows a Gulf company to do** Each row is a model; a filled mark means the property holds, a half mark that it holds in part, and text gives the detail where yes or no would mislead. | | Weights published | Licence allows commercial use | Gulf dialect named | Sizes | | --- | --- | --- | --- | --- | | Jais 2 | yes | yes | partial | 8B, 70B | | Fanar 2.0 | yes | yes | yes | 27B | | ALLaM 7B preview | yes | yes | Not stated | 7B | | AceGPT v2 | yes | yes | Not stated | 8B, 32B | | Silma 9B | yes | Gemma terms | Not stated | 9B | | Aya Expanse | yes | no | Not stated | 8B, 32B | | Command R7B Arabic | yes | no | no | 8B | | Falcon-H1-Arabic | None found | Service terms | yes | 3B, 7B, 34B | | Falcon-Emirati | None found | Service terms | yes | 7B | | ALLaM 34B | no | Service terms | Not stated | 34B | Source: Qantara, compiled from the sources in Table 1, read on 14 October 2026. Gulf dialect is yes where the developer names Gulf or a Gulf dialect, partial where it names dialects without saying which, and no where the card names Modern Standard Arabic only. ## 5. Benchmarks and leaderboards The Open Arabic LLM Leaderboard on Hugging Face is the reference most developers quote. Its second version, of February 2025, removed saturated and machine-translated tasks and added ArabicMMLU, a human-translated MMLU, the AraTrust safety set and a retrieval task scored by a model [2]. ArabicMMLU has 14,575 multiple-choice questions in Modern Standard Arabic from school exams in eight countries; at release GPT-4 scored 72.5% and the best Arabic-centric model 62.3% [29]. Balsam has 78 tasks and 52,000 examples, with blind test sets [30]. AraBench tests translation from dialect into English, at levels down to 25 cities [31]. Qimma, released by TII in April 2026, validates questions before ranking models: two models score each item, native speakers review the flagged ones, and the suite keeps over 52,000 samples, 99% native Arabic [1]. Five weaknesses run through them. Translation. The leaderboard's maintainers say the tasks translated from English in its first version introduced linguistic and contextual mismatches [2]; the TII survey counts cultural misalignment in translated sets among the field's gaps [17]. Even the dialect benchmark AraDiCE was built by machine translation and human post-editing [32], and every frontier score above is a translation. Modern Standard Arabic. ArabicMMLU's Gulf sources are 184 questions from the UAE, 111 from Kuwait and 104 from Saudi Arabia, against more than 6,000 from Jordan [29]: by our sum, 399 of 14,575. Alyah's authors note that most Arabic benchmarks focus almost exclusively on the standard language [14]. Wrong answers and broken scoring. Qimma discarded 436 of 14,163 ArabicMMLU items (3.1%) for wrong gold answers, corrupt text and duplicates, and rewrote 88% of the Arabic HumanEval+ prompts [1]. ArabicMMLU's own authors found 96% of a sample of answer keys correct and treat that as the highest meaningful score [29]. The leaderboard found a scoring bug that had cut some small models' scores on one task by up to 20 points [2]. Contamination. Most test sets are static and public, so data contamination (When test questions, or close copies of them, appear in a model's training data, so that a high score partly measures memory rather than skill.) is hard to rule out; Balsam's authors built blind test sets for this reason [30]. Who runs the test, and how. TII scored Falcon-H1-Arabic with a different inference engine from the leaderboard's, a difference it puts at under one point, and scored a newer ALLaM release higher than the leaderboard's [11]; TII also built Alyah and Qimma, which rank its models. None of this suggests bias, but it is a reason to rerun a shortlist. And most of these tests score multiple-choice answers by likelihood [1], while an agent writes replies and fills fields. ## 6. Gulf dialect beside the standard and the larger dialects Arabic's dialects include Gulf, Levantine, Egyptian and Maghrebi [5], and Gulf is itself several: Sada labels Najdi, Hijazi and Khaliji speech [5], and the Habibi speech work lists Emirati, Omani and Dhofari separately [33]. Benchmarks have favoured the larger dialects: AraDiCE's 45,000 post-edited samples cover Egyptian and Levantine, and only its cultural test spans the Gulf [32]. On AraDiCE, Arabic-specific models such as Jais and AceGPT beat multilingual ones on dialect tasks; models chose Gulf replies best, which the authors attribute to Gulf's closer resemblance to the standard language, and asked to write dialect, they often explained the prompt instead [32]. Alyah, released by TII in January 2026, is built for one Gulf dialect: 1,173 four-option questions collected by hand from native Emirati speakers [14]. Its hardest categories were Language and Dialect and Greetings and Daily Expressions, which the authors attribute to Emirati being mostly spoken and rarely written. Figure 3 shows the instruction-tuned results. **Figure 3. Accuracy of instruction-tuned models on Alyah, the Emirati-dialect benchmark, in percent** Each bar is one model's accuracy, in percent, on 1,173 four-option questions written by native Emirati speakers; guessing would score 25%. | | % | | --- | --- | | Falcon-H1-Arabic 7B Instruct | 82.18 | | ALLaM 7B Instruct preview | 77.24 | | Gemma 3 27B it | 74.68 | | Qwen2.5 72B Instruct | 74.6 | | Aya Expanse 32B | 73.66 | | AceGPT v2 32B Chat | 72.8 | | Llama 3.3 70B Instruct | 69.74 | | Fanar 1 9B Instruct | 69.22 | | Command R7B Arabic | 64.54 | | Silma 9B Instruct | 63.94 | | Aya Expanse 8B | 61.21 | | Llama 3.1 8B Instruct | 46.29 | | Qwen3 8B | 25.66 | Source: TII, Alyah results table for instruction-tuned models, published 27 January 2026 and read on 14 October 2026 [14]; 13 of the 31 models listed, values quoted exactly. TII built both Alyah and the top model; the Jais 2 models are discussed in the post but are not in its table. Arabic-trained 7B models sit above multilingual models ten times their size: 82.18 for Falcon-H1-Arabic 7B and 77.24 for ALLaM 7B, against 74.6 for Qwen2.5-72B and 69.74 for Llama-3.3-70B [14]. Scores near 25% need care: Qwen3's instruction-tuned models scored 25.66 to 26.26, the level of guessing, and Qimma also singles out Qwen3 as the family whose instruction tuning did not help [1]. We read this as a mismatch between output and scoring code rather than ignorance, and as a reminder of how fragile one score is. Writing the dialect is harder than reading it. Al-Qasida, across nine models and eight dialects, found that models produce dialect less well than they understand it because they are reluctant to, that post-training can add to the bias, and that a few examples in the prompt overcome it [4]. TII measured the same for Emirati with an LLM-as-judge (Scoring free-text answers by asking another language model to grade them against a rubric. Cheaper than human raters, but it inherits the judging model's biases.): asked the Alyah questions openly, Falcon-Emirati-7B answered in Emirati with a fidelity of 0.52, against 0.05 for ALLaM-7B, 0.03 for Gemma-3-27B, 0.02 for Jais-2-8B and about 0.00 for Fanar-2-27B. The others, the authors write, "often know the right answer but say it in Modern Standard Arabic by default" [3]. The register of a reply is therefore a decision made per workflow: a formal reply may suit a supplier and not a customer who wrote in dialect. Messages also mix languages; Jais 2's card names Arabic-English code-switching (Moving between languages within one conversation or sentence, as in a Gulf message that mixes Arabic with English product names and numbers.) as a target [6]. ## 7. Speech: recognising and speaking Gulf Arabic A voice note is two problems in sequence: turning Gulf speech into text, then understanding the text. If recognition drops a quantity, no language model downstream recovers it. The measure is word error rate (The share of words a speech recogniser gets wrong, by substituting, dropping or inserting them, against a human transcript. Lower is better.), and public data for Gulf speech is small (Table 2). **Table 2. Public speech data with Gulf content** | Dataset | Size | Source | Gulf content | | --- | --- | --- | --- | | MGB-2 (2016) | About 1,200 hours | Al Jazeera broadcasts [5] | One of five dialect groups; 78% standard Arabic [18] | | Sada (2024) | 668 hours | 57 Saudi television shows [19] | Mostly Saudi dialects | | Casablanca (2024) | About 48 hours, 6 Emirati | Television series on YouTube [18] | Emirati among eight dialects | | Mixat (2024) | 15 hours | Two Emirati podcasts [34] | Emirati mixed with English | | Habibi test (2026) | 1,375 Saudi and 1,048 Emirati clips | Sada and other corpora [33] | Two of seven speech synthesis subsets | Figures as stated by each dataset's authors; MGB-2's share of standard Arabic as reported by the Casablanca authors. The leaderboard's first report ran 14 open system set-ups, without fine-tuning, on five multi-dialect test sets, and its Table 3 splits the Sada test set by dialect [5]. Every set-up did best on Modern Standard Arabic and markedly worse on Egyptian and Khaliji, which the authors attribute to training data dominated by the standard language; Whisper, for one, saw 739 labelled hours of Arabic among 680,000 [5, 35]. Rankings tracked labelled Arabic data, noise and music raised every error rate, and elderly and female speakers fared worse with most systems. **Figure 4. Word error rate on Modern Standard Arabic and on Khaliji speech in the same Sada test set, in percent** For each system, the first bar is the percentage of words wrong on Modern Standard Arabic and the second on Khaliji (Gulf) speech, both from Saudi television; shorter is better. | | Modern Standard Arabic | Khaliji | | --- | --- | --- | | Conformer-CTC large with language model | 19.23 | 48.23 | | Whisper large-v3 | 27.95 | 59.92 | | Whisper large-v3 turbo | 28.93 | 65.04 | | Whisper large-v2 | 29.13 | 63.06 | | SeamlessM4T v2 large | 39.87 | 55.73 | | MMS 1B all | 42.71 | 83.43 | | Whisper small | 49.41 | 93.16 | Source: Wang, Alhmoud and Alqurishi, Open Universal Arabic ASR Leaderboard, Table 3, arXiv, 18 December 2024 [5]; seven of the 14 set-ups, values quoted exactly (the paper prints decimal commas). Emirati speech tells the same story. On Casablanca's Emirati test set, Whisper large-v3 got 62.31% of words wrong before text normalisation and 52.88% after, and on code-switched segments it produced no words in the other language, transliterating or translating them [18]. Mixat's authors found existing recognisers perform poorly on Emirati podcasts, and worse with code-switching [34]. The Gulf laboratories have begun to answer. Fanar has had dialect speech recognition since its first release, and Fanar 2.0 adds a long-form recogniser [22, 13]. TII's Falcon-ASR (October 2026), a 1.6B model trained on Emirati, other Gulf and Arabic dialects, the standard language and English, reports an average word error rate of 20.92% on the leaderboard's six current test sets, against 23.17% for the best entry it checked on 30 September 2026, and 22.73% on an internal Emirati set [15]. These are the developer's figures, the Emirati set is not public, and the model was offered as a demonstration with an API planned. For an agent that answers a voice note with a voice note, synthesis matters too. Habibi, released openly in January 2026, trains one model across more than 12 regional dialects and publishes a multi-dialect synthesis benchmark with Saudi and Emirati subsets; its authors report quality competitive with ElevenLabs' Eleven v3 (alpha) [33]. ## 8. Open weights, services and in-country hosting Where a model can run depends on whether its weights are published and what their licence allows. Open weights (A model whose trained parameters can be downloaded and run on one's own hardware. The licence attached to the weights decides whether commercial use is allowed.) under Apache 2.0, as for Jais 2, the ALLaM 7B preview, Fanar and AceGPT, can run in a cloud region in the country, in the company's own cloud or on its hardware, and be used commercially [6, 8, 7]. CC-BY-NC weights, as for Aya and Command R7B Arabic, can be tested, but commercial use falls outside the licence [9, 23]. The rest are services. ALLaM 34B runs inside Humain's app, hosted in Saudi Arabia [10]; TII's Falcon-H1-Arabic, Falcon-Emirati and Falcon-ASR were offered through its chat service and a demonstration [11, 3, 15]; frontier models are reached through their developers' APIs. A service in the same country can meet a residency rule that one abroad cannot, but either way the provider's terms decide where the model runs and what it keeps. Size need not be a barrier either: TII positions its 7B as the general-purpose production model and its 3B for on-device use [11], and Fanar 2.0's authors call sovereignty a first-class design principle [13]. ## 9. Implications for deployment Three conclusions follow for a Gulf company, and they describe how Qantara approaches the work. Choose per workflow. No model leads on every kind of Arabic work. One that reads invoices well may not reply in dialect, and the best text model cannot recover a quantity the recogniser dropped. Table 3 is an illustrative example of how the choice divides. **Table 3. An illustrative mapping of Gulf workflows to what to test and where the model can run** | Workflow | What arrives | What to test on past cases | Where the model can run | | --- | --- | --- | --- | | Orders by WhatsApp | Gulf dialect with English product names | Items and quantities; replies in the customer's register | In-country open weights where messages carry personal data | | Voice notes | Gulf speech on phones, with noise and English words | Word error rate on the company's own notes | In-country recognition where audio cannot leave | | Supplier documents | Standard Arabic and English, often photographed | Fields extracted against the ERP | Depends on what the document holds | | Customer replies | Drafts in dialect or standard Arabic | Register and tone, marked by the team | Any model the data allows; a person approves above thresholds | Illustrative; ours. A method, not measured results. Evaluate on the customer's own Gulf cases. Section 5 shows why a leaderboard can shortlist a model but not choose it. The test that counts is built from the company's past work: its WhatsApp orders in its customers' dialect, its voice notes from its own warehouses, its supplier documents. At Qantara, each agent is run on the customer's past cases before it goes live, with their team marking what good looks like, and our engineers record a baseline first. Al-Qasida's finding that a few examples restore dialect output suggests the same cases can improve a model as well as measure it [4]. Our technical report Compounding agents: evaluation and A/B testing on live operations sets out the method. Host where the data must stay. The record of what each agent read and did, and its log, are kept in the customer's country, and for each workflow we state in writing which model reads what and where it runs. Where data cannot leave, open-weight Arabic models from Gulf developers, under licences that allow commercial use, now exist at sizes up to 70B. Where data may leave, frontier models from Silicon Valley, which Qantara brings to Gulf companies through partners, are candidates too. Either way each agent signs in with credentials of its own, every read and write is logged, and above the customer's thresholds a person approves. As Figure 1 shows, the field changes every few months, so a model chosen today should be re-tested on the same past cases when a better one appears. ## 10. Limitations - We ran no models. Many scores come from the developers of the models they rank, including TII for Alyah, Qimma and the Falcon models. - Gulf evidence is thin. Alyah covers written Emirati; Sada, Saudi television; Casablanca, six hours of Emirati television; Mixat, 15 hours of podcasts. We found no public benchmark for Omani, Kuwaiti, Bahraini or Qatari text, and none built from business messages or calls. - Most text benchmarks are multiple choice; they do not test extraction, register or action. - Closed frontier models are absent from the Arabic leaderboards we read, and their published Arabic figures are translations. - Speech results come from broadcast and podcast audio; phone voice notes are likely harder, but we found no public measurement. - Licences, access and availability change; our statements describe 14 October 2026. A public Gulf-wide benchmark built from operational messages and voice notes would test these conclusions directly; we would welcome one. ## 11. Conclusion By October 2026, open-weight Arabic models from Abu Dhabi, Riyadh and Doha rank alongside multilingual models several times their size, under licences that let a company run them in its own country. The evidence for Gulf dialect is newer and thinner: models understand it better than they write it, most benchmarks do not test it, and speech recognition, the first step for every voice note, still gets far more Gulf words wrong than standard ones. For a company putting agents into its operations, published scores are a starting list. The decision belongs to its own past cases, marked by its own team, with each workflow's model chosen, tested and hosted where its data is allowed to be. ## References [1] AlQadi, L., Alzubaidi, A., Alyafeai, M., et al. (2026). QIMMA قِمّة ⛰: A Quality-First Arabic LLM Leaderboard. Hugging Face blog, Technology Innovation Institute. https://huggingface.co/blog/tiiuae/qimma-arabic-leaderboard (accessed 14 October 2026) [2] El Filali, A., Aloui, M., Husaain, T., et al. (2025). The Open Arabic LLM Leaderboard 2. Hugging Face blog. https://huggingface.co/blog/leaderboard-arabic-v2 (accessed 14 October 2026) [3] Alsuwaidi, S., Alkaabi, O., Alhammadi, M., et al. (2026). Falcon-Emirati: When an LLM Learns the Dialect, the Culture, and the Nuance. Hugging Face blog, Technology Innovation Institute. https://huggingface.co/blog/tiiuae/falcon-emirati (accessed 14 October 2026) [4] Robinson, N. R., Abdelmoneim, S., Marchisio, K., et al. (2025). AL-QASIDA: Analyzing LLM Quality and Accuracy Systematically in Dialectal Arabic. Findings of ACL 2025. https://aclanthology.org/2025.findings-acl.1137/ [5] Wang, Y., Alhmoud, A. and Alqurishi, M. (2024). Open Universal Arabic ASR Leaderboard. arXiv:2412.13788. https://arxiv.org/abs/2412.13788 [6] Inception (2025). Jais-2-70B-Chat model card. Hugging Face. https://huggingface.co/inception42/Jais-2-70B-Chat (accessed 14 October 2026) [7] Qatar Computing Research Institute (2026). Fanar-2-27B-Instruct model card. Hugging Face. https://huggingface.co/QCRI/Fanar-2-27B-Instruct (accessed 14 October 2026) [8] Ouda, K. (2025). Arabic LLM Models. Hugging Face blog, SILMA AI. https://huggingface.co/blog/silma-ai/arabic-llm-models-list (accessed 14 October 2026) [9] Cohere Labs (2024). aya-expanse-8b model card. Hugging Face. https://huggingface.co/CohereLabs/aya-expanse-8b (accessed 14 October 2026) [10] Middle East AI News (2025). HUMAIN Chat goes live powered by ALLaM 34B LLM. Middle East AI News, 25 August 2025. https://www.middleeastainews.com/p/humain-chat-live-allam-34b-llm (accessed 14 October 2026) [11] Boussaha, B. E. A., Alyafeai, M., Alzubaidi, A., et al. (2026). Introducing Falcon-H1-Arabic: Pushing the Boundaries of Arabic Language AI with Hybrid Architecture. Hugging Face blog, Technology Innovation Institute. https://huggingface.co/blog/tiiuae/falcon-h1-arabic (accessed 14 October 2026) [12] Anwar, M., Freihat, A. A., Ibrahim, G., et al. (2026). Jais 2: A Family of Arabic-Centric Open Large Language Models. arXiv:2608.13580. https://arxiv.org/abs/2608.13580 [13] Fanar Team, Abbas, U., Ahmad, M. S., et al. (2026). Fanar 2.0: Arabic Generative AI Stack. arXiv:2603.16397. https://arxiv.org/abs/2603.16397 [14] Alkaabi, O., Alzubaidi, A., Alobeidli, H., et al. (2026). Alyah ⭐️: Toward Robust Evaluation of Emirati Dialect Capabilities in Arabic LLMs. Hugging Face blog, Technology Innovation Institute. https://huggingface.co/blog/tiiuae/emirati-benchmarks (accessed 14 October 2026) [15] Muneer, A., Saraf, R., Gundluru, R., et al. (2026). Introducing Falcon ASR. Hugging Face blog, Technology Innovation Institute. https://huggingface.co/blog/tiiuae/falcon-asr (accessed 14 October 2026) [16] Al-Khalifa, S., Durrani, N., Al-Khalifa, H., et al. (2025). The Landscape of Arabic Large Language Models (ALLMs): A New Era for Arabic Language Technology. arXiv:2506.01340, accepted at Communications of the ACM. https://arxiv.org/abs/2506.01340 [17] Alzubaidi, A., Alsuwaidi, S., Boussaha, B. E. A., et al. (2025). Evaluating Arabic Large Language Models: A Survey of Benchmarks, Methods, and Gaps. arXiv:2510.13430. https://arxiv.org/abs/2510.13430 [18] Talafha, B., Kadaoui, K., Magdy, S. M., et al. (2024). Casablanca: Data and Models for Multidialectal Arabic Speech Recognition. Proceedings of EMNLP 2024. https://aclanthology.org/2024.emnlp-main.1211/ [19] Alharbi, S., Alowisheq, A., Tüske, Z., et al. (2024). SADA: Saudi Audio Dataset for Arabic. Proceedings of ICASSP 2024, pp. 10286-10290. https://doi.org/10.1109/ICASSP48485.2024.10446243 [20] Sengupta, N., Sahu, S. K., Jia, B., et al. (2023). Jais and Jais-chat: Arabic-Centric Foundation and Instruction-Tuned Open Generative Large Language Models. arXiv:2308.16149. https://arxiv.org/abs/2308.16149 [21] Huang, H., Yu, F., Zhu, J., et al. (2024). AceGPT, Localizing Large Language Models in Arabic. Proceedings of NAACL 2024. https://aclanthology.org/2024.naacl-long.450/ [22] Fanar Team, Abbas, U., Ahmad, M. S., et al. (2025). Fanar: An Arabic-Centric Multimodal Generative AI Platform. arXiv:2501.13944. https://arxiv.org/abs/2501.13944 [23] Cohere Labs (2025). c4ai-command-r7b-arabic-02-2025 model card. Hugging Face. https://huggingface.co/CohereLabs/c4ai-command-r7b-arabic-02-2025 (accessed 14 October 2026) [24] Boussaha, B., Alyafeai, M., Alzubaidi, A., et al. (2025). Falcon-Arabic: A Breakthrough in Arabic Language Models. Hugging Face blog, Technology Innovation Institute. https://huggingface.co/blog/tiiuae/falcon-arabic (accessed 14 October 2026) [25] Bari, M. S., Alnumay, Y., Alzahrani, N. A., et al. (2025). ALLaM: Large Language Models for Arabic and English. Proceedings of ICLR 2025 (arXiv:2407.15390). https://arxiv.org/abs/2407.15390 [26] Cohere Labs (2026). Aya. Cohere Labs research page. https://cohere.com/research/aya (accessed 14 October 2026) [27] OpenAI (2025). Multilingual MMLU Benchmark Results. openai/simple-evals, GitHub. https://github.com/openai/simple-evals/blob/main/multilingual_mmlu_benchmark_results.md (accessed 14 October 2026) [28] Anthropic (2026). Multilingual support. Claude documentation. https://platform.claude.com/docs/en/build-with-claude/multilingual-support (accessed 14 October 2026) [29] Koto, F., Li, H., Shatnawi, S., et al. (2024). ArabicMMLU: Assessing Massive Multitask Language Understanding in Arabic. Findings of ACL 2024. https://aclanthology.org/2024.findings-acl.334/ [30] Al-Matham, R., Darwish, K., Al-Rasheed, R., et al. (2025). BALSAM: A Platform for Benchmarking Arabic Large Language Models. Proceedings of ArabicNLP 2025 (arXiv:2507.22603). https://aclanthology.org/2025.arabicnlp-main.21/ [31] Sajjad, H., Abdelali, A., Durrani, N., et al. (2020). AraBench: Benchmarking Dialectal Arabic-English Machine Translation. Proceedings of COLING 2020, pp. 5094-5107. https://aclanthology.org/2020.coling-main.447/ [32] Mousi, B., Durrani, N., Ahmad, F., et al. (2025). AraDiCE: Benchmarks for Dialectal and Cultural Capabilities in LLMs. Proceedings of COLING 2025. https://aclanthology.org/2025.coling-main.283/ [33] Chen, Y., Liu, J., Tu, Y., et al. (2026). Habibi: Laying the Open-Source Foundation of Unified-Dialectal Arabic Speech Synthesis. arXiv:2601.13802. https://arxiv.org/abs/2601.13802 [34] Al Ali, M. K. and Aldarmaki, H. (2024). Mixat: A Data Set of Bilingual Emirati-English Speech. Proceedings of SIGUL 2024 at LREC-COLING 2024, pp. 222-226. https://aclanthology.org/2024.sigul-1.26/ [35] Radford, A., Kim, J. W., Xu, T., et al. (2022). Robust Speech Recognition via Large-Scale Weak Supervision. arXiv:2212.04356. https://arxiv.org/abs/2212.04356 ## Cite this paper ```bibtex @techreport{qantara2026arabiclanguagemodels, title = {Arabic language models for Gulf operations: a 2026 survey}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/arabic-language-models} } ``` ## Disclosure Every model description, score, size, licence and date is quoted from the cited sources as read on 14 October 2026; dates without a stated release are Hugging Face repository creation dates, and "no public weights found" records our own search that day. The selection of models and benchmarks, Figure 2, the sum of ArabicMMLU's Gulf questions and the ranges drawn from published tables are ours; Table 3 and the workflow examples are illustrative. We ran no models for this survey. Canonical: https://qantara.systems/insights/arabic-language-models --- # How the Gulf writes: Arabizi, code-switching and dialect in business messages Research. Qantara Research, Qantara. 14 October 2026. 19 min read. > What operational messages in the Gulf really look like, what the research says about reading them, and what that asks of an AI agent that acts on them. ## Abstract Operational messages in the Gulf arrive in Gulf Arabic written in Arabic script, in Arabic typed with Latin letters and numerals (Arabizi), in English, and often in a mixture of all three, with more than one digit system, and sometimes as voice notes. We ask what this means for an AI agent that has to read such messages and act on them. We review the published research on Arabizi detection and transliteration, Arabic-English code-switching and Gulf dialect resources, set it beside official population statistics for the six GCC states, and annotate an illustrative message word by word. We find that resources for Gulf text and speech exist but are thin and uneven, that tools and models built for Modern Standard Arabic lose accuracy on Gulf input, sometimes to the point of being unusable, and that public evaluation sets rarely look like a Gulf business message. We propose a reading pipeline (normalise, detect script and dialect, interpret, confirm in the customer's language) and argue that an agent should be judged on messages shaped like the customer's own, and should never require a customer to switch to Modern Standard Arabic or English to be understood. ## Key findings 1. Gulf Arabic was already being typed in Latin letters and numerals in 2003, and surveys in Oman and Saudi Arabia find that mixing Arabic and English is ordinary among educated and working writers [1, 2, 3]. 2. The people writing are diverse: in national statistics compiled for mid-2022, non-nationals were a majority of residents in four of the six GCC states and 54.6% across all six [4]. 3. Tools built for Modern Standard Arabic lose accuracy on Gulf input: a tagger built for MSA got 64.03% of lemmas in Gulf text right, against 77.02% for one built for Egyptian Arabic, and off-the-shelf speech models exceeded 100% word error rate on Emirati podcast speech [5, 6]. 4. Public evaluation rarely looks like the Gulf: the 2024 multi-label dialect identification test set had no GCC dialect among its labels, and a 2025 study of Arabizi translation by large language models covered no Gulf dialect [7, 8]. 5. An agent should normalise, detect, interpret and then confirm in the customer's own language, and should be evaluated on the customer's past messages, stratified by script, dialect and channel, rather than on one average over clean text. ## 1. Introduction Most of what moves a Gulf company's day is written in a hurry. A buyer confirms an order from a car park, a driver reports a carton short from a loading bay, a supplier moves a delivery date in a voice note. These messages decide what is shipped, invoiced and chased, and they are what an AI agent has to read before it can do anything useful in operations. Very often they are not written in the Arabic that language technology was built for. Arabic is diglossic (Using two varieties of one language for different purposes: here Modern Standard Arabic for formal writing, and a spoken dialect for almost everything else.): Modern Standard Arabic (MSA) is the written standard across the Arab world, while people speak, and increasingly type, their own dialects [5, 9]. In the Gulf three further facts sit on top of that. People have long typed Gulf Arabic in Latin letters and numerals, a practice called Arabizi (Arabic written in Latin letters, with numerals standing in for Arabic letters that have no Latin equivalent, such as 3 for ع, 7 for ح and 2 for ء.) [1]. Many writers move between Arabic and English inside a single message [2, 3]. And in four of the six GCC states most residents are not nationals, so the person at the other end of a thread may write another dialect, Arabic as a second or third language, or English [4]. This matters more now than when language models were mainly used for conversation. An agent that confirms orders, releases credit or reschedules deliveries turns a misreading into an operational error: three cartons become two, tomorrow becomes today, a question becomes a commitment. Our question is therefore practical. What do operational messages in the Gulf look like, what does the published research say about reading them, and what does that require of an agent that acts on them? This paper contributes: 1. A review of the research on Arabizi, Arabic-English code-switching and Gulf dialect resources, read for what it implies about business messages rather than social media. 2. The demographic context from official statistics, cited country by country with its year, and what it means for who writes to a Gulf company. 3. An annotated illustrative message, and a matrix of the phenomena such messages contain against what each requires of a model. 4. A reading pipeline (normalise, detect, interpret, confirm in the customer's language) and an evaluation practice built on the customer's own past messages. ## 2. Background and related work ### Gulf Arabic and its spelling Khalifa and colleagues define Gulf Arabic broadly as the Arabic spoken in the six GCC states, and stress that the region's cultural homogeneity does not make it linguistically homogeneous: the Khaleeji (Gulf Arabic: the family of dialects spoken by nationals of the GCC states, which differ among themselves in sounds, grammar and vocabulary.) dialects differ from one another in sound, grammar and vocabulary, and all of them differ from MSA [5]. None has an official spelling. The unified CODA guidelines, which set conventions for 28 city dialects from Rabat to Muscat, start from that absence: since no dialect has a standard orthography, no spelling of a dialect word can be called incorrect [10]. ### Arabizi The earliest Gulf study we found is Palfreyman and Al Khalil's analysis of instant messages written by female university students in the UAE [1]. The writers used numerals for Arabic sounds with no Latin counterpart (5 for the sound of خ, 6 for ط, 9 for ص, 7 for ح), wrote ch and g for Gulf pronunciations that MSA spelling does not show, and in one message used the numeral 3 both as a letter and as the number three. Of the 79 people who answered the authors' survey, 55% said they wrote this way because it was easier to type in English, 30% cited missing support for Arabic script and 15% the Gulf sounds, and some described it as a social choice. The numbers are small and the study is two decades old. But Darwish noted in 2014 that Arabizi stayed popular after phones and browsers supported Arabic, because writers were used to it and more fluent on English keyboards [11]. Computational work on Arabizi has two tasks: finding it among English words, and converting it to Arabic script by transliteration (Rewriting a word from one script into another, sound by sound, without translating it.). Darwish labelled the words of tweets as Arabizi, English or other, reaching 98.5% word-level identification accuracy, and converted Arabizi to Arabic script with 88.7% accuracy, about a third of the remaining errors being spelling variants [11]. Bies and colleagues at the Linguistic Data Consortium built a parallel corpus of Egyptian SMS and chat, 2,140 conversations and 475,000 words, in which 66% of conversations were entirely in Arabizi, 15% entirely in Arabic script and 19% mixed [12]. Shazal, Usman and Habash replaced the separate steps with one sequence-to-sequence model that detects and transliterates together, reporting 80.6% word accuracy on a blind test set [13]. Two threads run through this work. Arabizi is inseparable from code-switching: the hard words are those valid in both languages, such as men, which is English, or Arabic for 'from' [11]. And the annotated data is not from the Gulf: the largest parallel resource is Egyptian [12], and we did not find a public, annotated corpus of Gulf Arabizi. ### Code-switching Hamed and colleagues' 2025 survey of code-switching (Moving between two languages or varieties within one conversation, sentence or even word, as in an English noun given an Arabic article.) in Arabic language processing counts on average 12 papers a year since 2014, and finds the field concentrated on a few pairs: MSA with Egyptian Arabic for switching between varieties, and Egyptian-English and Algerian-French for switching between languages [14]. Gulf resources are recent and small. Mixat, published in 2024, is about 15 hours of speech from two Emirati podcasts whose hosts often switch between Emirati Arabic and English [6]. ZAEBUC-Spoken, also from 2024, is about twelve hours of recorded video meetings in which speakers role-play a work scenario, in MSA, Gulf and Egyptian Arabic and English, switching between them [15]. Surveys in the Gulf suggest the practice is ordinary. In Oman, Al-Qaysi and Al-Emran surveyed 338 students and 21 educators in higher education: 86.40% of the students and 81% of the educators said they code-switch on social networks, and WhatsApp was the application they used most for it [2]. In Saudi Arabia, Alsalami's questionnaire of 426 bilingual Saudis found that those with higher English proficiency switched more, and that working people used code-switching extensively [3]. In the UAE, Hopkyns, Zoghbor and Hassall found creative translanguaging, mixing Arabic and English, among 100 Emirati university students, where official policy presents the two as separate, pure languages [16]. All three are self-reports from educated, mostly young writers, and none measures business messages directly. Together they say that a customer who mixes Arabic and English is ordinary, not an edge case. ### Gulf dialect resources and shared tasks Three resources anchor Gulf dialect work in text. The Gumar corpus holds about 110 million words from 1,200 forum novels, labelled for sub-dialect document by document [5]; its coverage is uneven, with Saudi text 60.52% of the corpus and Omani text 1.13%. The MADAR corpus translates 2,000 travel sentences into 25 city dialects, four of them in the Gulf (Riyadh, Jeddah, Doha and Muscat), alongside a lexicon of 1,045 concepts [9]. CAMeL Tools, an open-source Python toolkit, bundles pre-processing, morphology, dialect identification, named entities and sentiment [17]; its dialect identifier distinguishes the same 25 cities plus MSA, so it knows Doha, Jeddah, Muscat and Riyadh but no Emirati, Kuwaiti or Bahraini city [18]. Shared tasks track how well dialects can be told apart. NADI 2020 covered 21 Arab countries and 100 provinces, using Twitter data [19]. By 2024 the organisers had moved to a multi-label task because dialects overlap so much that one sentence can be valid in several; but none of the nine country dialects in that year's multi-label test set came from a GCC state, and Emirati appeared only in the dialect-to-MSA translation subtask, where the winning system scored 23.38 BLEU on it [7]. NADI 2025, the first edition on speech, covered eight country dialects, of which only the UAE's came from the GCC [20]. Table 1 summarises what these resources cover. **Table 1. Resources for Gulf text and speech, and what they cover. Compiled by Qantara from the papers cited in this section.** | Resource | What it is | Gulf coverage | | --- | --- | --- | | Gumar corpus (2016) | About 110 million words of forum novels, labelled by sub-dialect | Saudi 60.52%, Emirati 13.35%, Kuwaiti 5.91%, Omani 1.13%, Qatari 0.65%, Bahraini 0.49% of the corpus | | MADAR corpus and lexicon (2018) | 2,000 travel sentences in 25 city dialects; 1,045-concept lexicon | Riyadh, Jeddah, Doha, Muscat | | CODA guidelines (2018) | Conventional spelling for dialect words | 28 city dialects, Rabat to Muscat | | Arabizi SMS and chat corpus (2014) | 475,000 words, Arabizi transliterated into Arabic script | None: Egyptian | | NADI shared tasks (2020 to 2025) | Dialect identification, dialect-to-MSA translation, and from 2025 speech | 21 countries in 2020; in 2024 Emirati in translation only; in 2025 Emirati the only GCC dialect | | Mixat (2024) | About 15 hours of podcast speech, transcribed | Emirati Arabic and Emirati-English | | ZAEBUC-Spoken (2024) | About 12 hours of role-played work meetings | Gulf Arabic among MSA, Egyptian and English | | SADA (2024) | 668 hours of Saudi television speech | Najdi, Hijazi and Khaleeji Saudi dialects | | CAMeL Tools (2020) | Toolkit: normalisation, morphology, dialect identification, entities, sentiment | Dialect identifier covers Riyadh, Jeddah, Doha, Muscat | Gumar percentages are from its Table 2, which also lists 10.03% mixed Gulf and 7.93% other Arabic, mostly MSA. SADA as described by Gerazov and colleagues (2025). ## 3. Who writes the messages A Gulf company's messages are written by its customers, suppliers and staff, and the region's demography shapes all three. Figure 1 shows non-nationals as a share of residents in mid-2022, as compiled from national statistical institutes by the Gulf Labour Markets, Migration and Population Programme [4]. Non-nationals were a majority in Qatar (87.9%), the UAE (87.1%), Kuwait (67.3%) and Bahrain (53.2%), and about four in ten residents of Saudi Arabia (41.6%) and Oman (40.1%); across the six states the share was 54.6%. The Qatar and UAE splits are the programme's own estimates, because neither state publishes totals by nationality. More recent official figures point the same way: Saudi Arabia's General Authority for Statistics put non-Saudis at 44.4% of the population in mid-2024 [21]. **Figure 1. Non-nationals as a share of residents, GCC states, mid-2022** Each bar is the share of a country's residents who are not its citizens; the longer the bar, the more likely the writer of a message is not a national. | | % of residents | | --- | --- | | Qatar (estimate) | 87.9 | | UAE (estimate) | 87.1 | | Kuwait | 67.3 | | Bahrain | 53.2 | | Saudi Arabia | 41.6 | | Oman | 40.1 | Source: Gulf Labour Markets, Migration and Population Programme, from national statistical institutes, mid-2022 figures, read 14 October 2026 [4]. Qatar and UAE splits are the programme's estimates. Oman, where Qantara is based, is highlighted. The non-national population is itself plural. India's Ministry of External Affairs counted 4,326,248 non-resident Indians in the UAE, 2,747,551 in Saudi Arabia, 1,036,389 in Kuwait, 830,491 in Qatar, 676,781 in Oman and 315,427 in Bahrain as of January 2026 [22], and Indian citizens are one group among many. Arabs from outside the Gulf write their own dialects, which the resources above treat as distinct from Khaleeji. Two consequences follow. First, English works as the common language between people who share no other. Randall and Samimi described Dubai's reliance on expatriate labour as having made English the common language there [23], and Hopkyns and colleagues describe English as a shared language and the main medium of instruction in the UAE, while Emiratis mostly speak Khaleeji at home [16]. Second, Arabic itself is used by people who learned it at work. Linguists describe a Gulf Pidgin Arabic: a simplified contact variety that grew up between Arabic-speaking locals and migrant workers from India, Indonesia, Pakistan and the Philippines [24]. A storekeeper's message in that variety is Arabic, but not the Arabic a dialect model was trained on. For an agent, this means the writer of a message cannot be inferred from the channel or the customer account. The same distributor may, in one morning, hear from a national buyer writing Gulf Arabizi, an accountant writing another Arab dialect, and a driver writing English with a few Arabic words. ## 4. Anatomy of a business message The message below is an illustrative example, written by us for this paper and not taken from any customer: a buyer at a catering company writes to a distributor's sales representative on WhatsApp. Every element in it is documented in the research above. We cannot say how often all of them occur together, because no public corpus of Gulf business messages exists. Table 2 annotates it word by word. ```text 9ba7 il5air akhoy, il order رقم ٤٥٧٢ ma wesal. nabi 3 karateen ghee w 2 oil bachir before 8. pls confirm ``` An illustrative example, written by us: one WhatsApp message to a distributor. **Table 2. The illustrative message, token by token. The meanings are ours.** | Token | Script | Language | Meaning | | --- | --- | --- | --- | | 9ba7 | Latin letters and numerals | Gulf Arabic (Arabizi): 9 for ص, 7 for ح | 'Morning' | | il5air | Latin letters and numerals | Gulf Arabic (Arabizi): 5 for خ | 'The good'; with the word before, 'good morning' | | akhoy | Latin | Gulf Arabic (Arabizi) | 'My brother', a friendly form of address | | il order | Latin | Arabic article on an English noun | 'The order' | | رقم | Arabic | Arabic, shared with MSA | 'Number' | | ٤٥٧٢ | Arabic-Indic digits | Numeral | 4572, the order number | | ma wesal | Latin | Gulf Arabic (Arabizi) | 'Has not arrived' | | nabi | Latin | Gulf Arabic (Arabizi) | 'We want', a Gulf form | | 3 | Western digit | Numeral | Three, a quantity; here not the letter ع | | karateen | Latin | Arabic plural of a borrowed word | 'Cartons' | | ghee | Latin | English | Ghee | | w | Latin | Arabic (Arabizi) | 'And' | | 2 | Western digit | Numeral | Two, a quantity; here not the letter ء | | oil | Latin | English | Cooking oil; brand and pack size unstated | | bachir | Latin | Gulf Arabic (Arabizi): ch for a Gulf pronunciation of ك | 'Tomorrow' | | before 8 | Latin and Western digit | English | A deadline; morning or evening is not said | | pls confirm | Latin | English | 'Please confirm' | Dialect spellings vary by writer; none is more correct than another. ### Letters, numerals and numbers The message uses numerals in two roles. In 9ba7 and il5air, as in Arabizi generally, a numeral stands for an Arabic letter [1, 11]. In '3 karateen' and '2 oil' the same characters are quantities. Palfreyman and Al Khalil recorded exactly this collision in the messages they collected [1]. A person resolves it from context without noticing. A parser that treats every digit as a number, or a transliterator that treats every 3 as ع, gets the order wrong. ### Three digit systems and the direction of text The order number is in Arabic-Indic digits and the quantities in Western ones. Unicode encodes two sets of Arabic digits separately: the Arabic-Indic digits used across most of the Arab world (U+0660 to U+0669), and the Eastern Arabic-Indic digits used for Persian, Urdu and Sindhi (U+06F0 to U+06F9), whose glyphs for four to seven vary between those languages [25]. A writer whose phone keyboard is set for Urdu or Persian types the second set, which looks like the first for several digits. With Western digits that makes three systems, sometimes inside one number, and they are distinct characters: they have to be mapped to one system before anything is compared with an ERP. Digits are also written left to right inside right-to-left text, and the Unicode Bidirectional Algorithm decides how a run of numbers and punctuation is displayed [26], so the order of characters on screen and in storage can differ. That matters when an agent copies a reference number back to a customer. ### Dialect without a standard spelling Words like bachir, akhoy and nabi have no MSA form to fall back on, and in Arabic script different writers spell them differently; the CODA guidelines exist because there is no standard [10]. A dictionary built on MSA fails on them, and a model that reads MSA well can still misread them. Identifying the dialect helps by telling the interpreter which conventions to expect, but the move to multi-label identification in 2024 is a reminder that a short message may be valid in several dialects at once [7]. ### English inside Arabic 'il order' puts the Arabic definite article on an English noun, and 'karateen' gives a borrowed word an Arabic plural. Bies and colleagues met the same pattern in Egyptian data, where English words take Arabic determiners [12]. For an agent the question is not which language the message is in, but what each word means. Labelling a whole message 'Arabic' or 'English' throws away the information it needs. ### Voice notes Some operational messages are not typed at all: they arrive as voice notes, in dialect, often with English mixed in. This is where the gap between technology built for MSA and the way the Gulf communicates is widest, as the next section shows. ## 5. Where models built for MSA fall short Where the evidence exists, it is direct. When Khalifa and colleagues hand-annotated about 4,000 words of Gulf Arabic from four Gumar novels, the MSA configuration of the MADAMIRA tagger met 9.3% out-of-vocabulary words against 5.6% for its Egyptian configuration, and was less accurate on every annotation layer (Table 3) [5]. Lemma accuracy, the layer an agent relies on to recognise a product or a verb whatever its form, was 64.03% with the MSA model and 77.02% with the Egyptian one. A model built for another dialect did better on Gulf text than a model built for the standard. **Table 3. Accuracy (%) of the MADAMIRA tagger on about 4,000 hand-annotated words of Gulf Arabic from the Gumar corpus, by the variety each configuration was built for. Source: Khalifa and colleagues (2016), Table 6.** | Annotation layer | Built for MSA | Built for Egyptian Arabic | | --- | --- | --- | | Conventional spelling | 83.81 | 88.34 | | Full morphological analysis | 76.16 | 83.62 | | Part of speech | 72.37 | 80.39 | | Syntactic tag | 76.28 | 81.51 | | Lemma | 64.03 | 77.02 | Speech shows the gap at its widest. On Mixat, the Emirati-English podcast data, Whisper (medium) and MMS, used without fine-tuning, had word error rates of 195.98% and 188.1% on the Emirati Arabic segments, against 12.06% and 72.75% on the English ones (Figure 2) [6]. A word error rate (The share of words a speech recogniser gets wrong, counting substitutions, deletions and insertions; it can exceed 100% when a model adds many words that were never said.) above 100% means the transcript holds more errors than the speech held words. The authors found that Whisper often produced a correct MSA translation instead of a transcript: it recognised the dialect but did the wrong task. ArTST, a model pre-trained on about a thousand hours of MSA, did best on the Emirati segments and still exceeded 100% [6]. Saudi speech behaves similarly: on the clean test set of SADA, 668 hours of Saudi television, Whisper medium without fine-tuning had a word error rate of 116.69%, and the best fine-tuned system 40.9% [27]. **Figure 2. Off-the-shelf speech recognition on Emirati podcast speech, by segment** Each group is one kind of segment and each bar one model; lower is better, and above 100% the transcript contains more errors than the speech contained words. | | Whisper (medium) | MMS (1b-all) | | --- | --- | --- | | Emirati Arabic | 195.98 | 188.1 | | Code-switched | 121.78 | 90.37 | | English | 12.06 | 72.75 | Source: Al Ali and Aldarmaki (2024), Table 3, on the Mixat data set (about 15 hours from two Emirati podcasts), published May 2024 [6]. Whisper medium and MMS-1b-all, without fine-tuning. With dialect data the picture changes. The best system in NADI 2025 reached 22.66% word error rate on Emirati test speech from another corpus [20]. The two Emirati numbers are not a controlled comparison, since the data differ, but they point the same way: dialect speech is workable with dialect data and close to unusable without it. Large language models narrow the gap without closing it. The AraDiCE benchmarks found that Arabic-centred models such as Jais and AceGPT did better than multilingual models on dialect tasks, that models generally did better on MSA than on dialects, and that dialect identification, generation and translation remained hard [28]. On Arabizi, Al Almaoui, Bouillon and Hengchen tested seven models, including GPT-4o, Claude 3.5 Sonnet and Gemini 1.5 Pro, on Lebanese, Egyptian and Algerian Arabizi, and concluded that models struggle significantly with it; translations into English scored higher than translations into MSA [8]. No Gulf dialect was in their test, and AraDiCE's dialect benchmarks centre on Levantine and Egyptian, reporting Gulf results for only some tasks [28]. We did not find a published evaluation of current models on Gulf Arabizi or on Gulf business text. Figure 3 condenses the evidence into a matrix: for each phenomenon in Table 2, whether a model trained mostly on MSA reads it well, and whether it needs dialect data, normalisation or both. It is our synthesis of the sources cited above, not a measurement. **Figure 3. What each phenomenon needs beyond a model trained on MSA** Read across a row: the first column says whether a model trained mostly on MSA reads the phenomenon well, the next two whether it also needs dialect data or normalisation. | | Read well by MSA-trained models | Needs dialect data | Needs normalisation | | --- | --- | --- | --- | | MSA in Arabic script | yes | no | partial | | Gulf dialect in Arabic script | partial | yes | partial | | Arabizi: Latin letters and numerals | no | yes | yes | | English words inside Arabic | partial | yes | partial | | Mixed digit systems | partial | no | yes | | Gulf Pidgin Arabic | no | yes | partial | | Voice notes in Gulf dialect | no | yes | partial | Qantara's synthesis of the sources cited in this paper, not a measured benchmark. Yes: generally; partial: in part, or for some writers; no: not without help. ## 6. A reading pipeline for an agent The pipeline in Figure 4 follows from the evidence. Its order matters: normalisation before detection, detection before interpretation, and confirmation before anything is written to a system that acts. **Figure 4. How an agent reads a Gulf business message** Follow the arrows from top to bottom; dashed arrows are the path taken when the reading is not certain. - Message arrives: WhatsApp, email, voice note - Transcribe: voice only, dialect-adapted - Normalise: digits, letter variants - Detect script and dialect: per word, several labels allowed - Transliterate Arabizi: original kept alongside - Interpret: items, quantities, dates, times - Ask, do not guess: one short question - Confirm in their language: same register, one digit system - Write to the record: original, reading, reply - Message arrives → Transcribe (audio) - Message arrives → Normalise (text) - Transcribe → Normalise - Normalise → Detect script and dialect - Detect script and dialect → Transliterate Arabizi (Arabizi) - Detect script and dialect → Interpret - Transliterate Arabizi → Interpret - Interpret → Confirm in their language - Interpret → Ask, do not guess (ambiguous) - Ask, do not guess → Confirm in their language - Confirm in their language → Write to the record (agreed) Qantara's design, drawn from the research cited in this paper. Voice notes take the upper path through a transcription model adapted to the dialect. 1. Normalise, and keep the original. Map the three digit systems to one, unify letter variants that writers use interchangeably (CAMeL Tools, for example, maps alef variants to bare alef, alef maksura to ya and ta marbuta to ha [29]) and collapse letters repeated for emphasis, a common feature of chat text [12]. Normalised text is for matching and search; the customer's own text is what is stored and quoted back. 2. Detect script and dialect word by word. Darwish's word-level labelling of Arabizi against English is the model [11]: one message can need three labels, and dialect labels should allow more than one answer [7]. 3. Transliterate Arabizi into Arabic script, beside the original. Most Arabic dialect tools expect Arabic script, which is why the parallel Arabizi corpus was built [12], and one model can detect and transliterate in a single pass [13]. 4. Transcribe voice notes with a model adapted to the dialect, or send them to a person. Off-the-shelf recognisers fail on Gulf speech; adapted ones can work [6, 27, 20]. 5. Interpret only the fields that drive action: item, quantity, unit, date, time and reference number. Resolve digit-or-letter from context, and treat what is left unsaid, such as morning or evening, as unknown rather than guessed. 6. Confirm in the customer's language, and ask rather than guess. Restate the facts that will be acted on, in the language and register the customer used, with numbers in one digit system, and ask one short question where something is ambiguous. 7. Write the original, the reading and the reply to the record, so that a person can see later what was read, how it was read, and what the customer agreed to. Step six carries most of the weight. As an illustrative example, a confirmation of the message in Table 2 would restate order 4572, three cartons of ghee and two of oil, tomorrow before 8, ask whether 8 means the morning, and do so in the customer's own mix of Arabic and English. Whether a company replies in Arabizi, in Arabic script or in English is a house-style decision for that company. The requirement is that the customer can answer in the form they already use, and is never translated into MSA or English in order to be understood. ## 7. Evaluating on real-shaped data Public benchmarks cannot tell a Gulf company how an agent will read its messages. The evaluation sets above are mostly Egyptian, Levantine or Maghrebi, the 2024 multi-label test set for written dialect identification contains no GCC dialect, and there is no public corpus of Gulf business messages [14, 28, 7, 8]. The evaluation set has to be built from the company's own past messages, and built so that the hard cases are visible. - Stratify. Label each message by script (Arabic, Latin, mixed), language mix, dialect where it can be told, channel (text or voice) and kind of writer, and report results for each stratum. An average over a set dominated by clean Arabic script hides failure on Arabizi and voice notes. - Score the fields, not the prose. What matters is whether the item, quantity, date and reference were read correctly, and whether the agent asked when it should have. Translation scores measure something else. - Include the hard cases on purpose: digits that could be letters, deadlines without a morning or evening, English nouns with Arabic morphology, all three digit systems, and messages from writers for whom Arabic is a second language. - Let the team that handles the messages decide what a correct reading is. They know that a given customer's 'oil' is a particular product and pack size; no annotator outside the company does. - Re-run when the mix changes. A new customer segment, a new branch or more voice notes changes the strata, and the results with them. These messages carry names, phone numbers and addresses. Building an evaluation set from them is processing personal data, and it should happen where the data already lives, under the company's own rules, rather than by sending samples abroad to be labelled. ## 8. Implications for deployment For a Gulf company putting agents into its operations, four things follow. 1. Customers should not have to change how they write. An agent that asks for MSA or English, or answers only in MSA, moves the cost of the technology onto the customer. Arabizi and code-switching are documented Gulf practices, chosen for habit and identity as well as convenience [1, 2, 16]. 2. Ask for results on your own messages, by stratum. A general Arabic benchmark score says little about Gulf Arabizi, Gulf voice notes or pidgin Arabic. 3. Treat voice notes as their own channel. Without recognition adapted to the dialect, they should go to a person. 4. Put uncertain readings under a threshold. Where the agent is not sure what a message says, a person decides, as they would above any other limit. This is how Qantara approaches the problem. Our engineers work on site inside the customer's operation and write down how the work really runs, including how its customers, suppliers and staff actually write. Agents work inside the systems the company already uses, such as WhatsApp, email and the ERP, and read and reply in Arabic and English on the same message. Before an agent goes live it is run on the company's past cases, with the company's own team marking what good looks like, and those cases are chosen to cover the scripts, dialects and channels the company really receives. Each message an agent reads, its reading and its reply are written to one operating record kept in the customer's country, and above the thresholds the customer sets, a person approves. We report no results here: this paper sets out the standard we hold that work to. ## 9. Limitations This paper is a review and an argument, not an experiment. We ran no models and built no corpus, so every performance number in it is someone else's, measured on someone else's data. The Gulf-specific evidence is thin and uneven. The only Gulf Arabizi study we found dates from 2003 and rests on 79 survey responses and a small set of messages from one university [1]; the computational Arabizi work rests mostly on Egyptian data [12]. The code-switching surveys are self-reports from students, educators and educated adults, not measurements of business messages [2, 3]. The speech evidence is Emirati and Saudi [6, 27, 20], and Kuwaiti, Omani, Qatari and Bahraini speech may behave differently. The tagger results in Table 3 come from about 4,000 words of novels, not messages [5]. The population figures for Qatar and the UAE are estimates [4], and nationality is not language: a non-national may be a native speaker of Gulf Arabic, and a national may prefer English. The illustrative message is ours, and its mix is not a measured frequency; Figure 3 is a judgement. Models change quickly, and an evaluation of 2026 models on Gulf business text could narrow the gaps reported here. A public, consented corpus of Gulf business messages with results by stratum would test our argument directly, and would change it if models trained mainly on MSA read such messages as well as they read MSA. ## 10. Conclusion Gulf business messages are written in Gulf Arabic, in Arabizi, in English and in mixtures of all three, with numerals that may be letters and digits in more than one system, by writers of many nationalities, and sometimes not written at all but spoken. The research needed to read them exists in pieces: Arabizi transliteration, code-switching corpora, Gulf dialect corpora and toolkits, dialect identification. Each piece shows the same thing. Technology built for MSA loses accuracy on Gulf input, sometimes until the output is unusable, and public evaluation rarely looks like a Gulf business message. An agent that acts on these messages should normalise without discarding the original, detect script and dialect word by word, interpret only the fields that drive action, and confirm in the customer's own language before it acts. It should be judged on the company's own messages, stratified so that the hard cases are visible. And it should never make a customer write in someone else's Arabic, or in English, in order to be understood. ## References [1] Palfreyman, D. and Al Khalil, M. (2003). "A funky language for teenzz to use": Representing Gulf Arabic in instant messaging. Journal of Computer-Mediated Communication 9(1). https://doi.org/10.1111/j.1083-6101.2003.tb00355.x [2] Al-Qaysi, N. and Al-Emran, M. (2017). Code-switching Usage in Social Media: A Case Study from Oman. International Journal of Information Technology and Language Studies 1(1). https://ijitls.journals.publicknowledgeproject.org/index.php/ijitls/article/view/5 [3] Alsalami, A. I. (2021). Arabic English Code Switching among Saudi Speakers. Arab World English Journal 12(4), pp. 118-131. https://awej.org/arabic-english-code-switching-among-saudi-speakers/ [4] Gulf Labour Markets, Migration and Population Programme, Gulf Research Center (2025). GCC: Total population and percentage of nationals and non-nationals in GCC countries (national statistics, mid-2022). Gulf Labour Markets, Migration and Population Programme. https://gulfmigration.grc.net/gcc-total-population-and-percentage-of-nationals-and-non-nationals-in-gcc-countries-national-statistics-mid-2022 (accessed 14 October 2026) [5] Khalifa, S., Habash, N., Abdulrahim, D., et al. (2016). A Large Scale Corpus of Gulf Arabic. Proceedings of LREC 2016, pp. 4282-4289. https://aclanthology.org/L16-1679/ [6] Al Ali, M. K. and Aldarmaki, H. (2024). Mixat: A Data Set of Bilingual Emirati-English Speech. Proceedings of SIGUL 2024 at LREC-COLING 2024, pp. 222-226. https://aclanthology.org/2024.sigul-1.26/ [7] Abdul-Mageed, M., Keleg, A., Elmadany, A., et al. (2024). NADI 2024: The Fifth Nuanced Arabic Dialect Identification Shared Task. Proceedings of the Second Arabic Natural Language Processing Conference (ArabicNLP 2024), pp. 709-728. https://aclanthology.org/2024.arabicnlp-1.79/ [8] Al Almaoui, P., Bouillon, P. and Hengchen, S. (2025). Arabizi vs LLMs: Can the Genie Understand the Language of Aladdin?. Proceedings of Machine Translation Summit XX, Volume 2, pp. 28-41. https://aclanthology.org/2025.mtsummit-2.4/ [9] Bouamor, H., Habash, N., Salameh, M., et al. (2018). The MADAR Arabic Dialect Corpus and Lexicon. Proceedings of LREC 2018. https://aclanthology.org/L18-1535/ [10] Habash, N., Eryani, F., Khalifa, S., et al. (2018). Unified Guidelines and Resources for Arabic Dialect Orthography. Proceedings of LREC 2018. https://aclanthology.org/L18-1574/ [11] Darwish, K. (2014). Arabizi Detection and Conversion to Arabic. Proceedings of the EMNLP 2014 Workshop on Arabic Natural Language Processing (ANLP), pp. 217-224. https://aclanthology.org/W14-3629/ [12] Bies, A., Song, Z., Maamouri, M., et al. (2014). Transliteration of Arabizi into Arabic Orthography: Developing a Parallel Annotated Arabizi-Arabic Script SMS/Chat Corpus. Proceedings of the EMNLP 2014 Workshop on Arabic Natural Language Processing (ANLP), pp. 93-103. https://aclanthology.org/W14-3612/ [13] Shazal, A., Usman, A. and Habash, N. (2020). A Unified Model for Arabizi Detection and Transliteration using Sequence-to-Sequence Models. Proceedings of the Fifth Arabic Natural Language Processing Workshop (WANLP 2020), pp. 167-177. https://aclanthology.org/2020.wanlp-1.15/ [14] Hamed, I., Sabty, C., Abdennadher, S., et al. (2025). A Survey of Code-switched Arabic NLP: Progress, Challenges, and Future Directions. Proceedings of COLING 2025, pp. 4561-4585. https://aclanthology.org/2025.coling-main.307/ [15] Hamed, I., Eryani, F., Palfreyman, D., et al. (2024). ZAEBUC-Spoken: A Multilingual Multidialectal Arabic-English Speech Corpus. Proceedings of LREC-COLING 2024, pp. 17770-17782. https://aclanthology.org/2024.lrec-main.1546/ [16] Hopkyns, S., Zoghbor, W. and Hassall, P. J. (2021). The use of English and linguistic hybridity among Emirati millennials. World Englishes 40(2), pp. 176-190. https://doi.org/10.1111/weng.12506 [17] Obeid, O., Zalmout, N., Khalifa, S., et al. (2020). CAMeL Tools: An Open Source Python Toolkit for Arabic Natural Language Processing. Proceedings of LREC 2020, pp. 7022-7032. https://aclanthology.org/2020.lrec-1.868/ [18] CAMeL Lab, New York University Abu Dhabi (2026). camel_tools.dialectid: dialect identification. CAMeL Tools documentation. https://camel-tools.readthedocs.io/en/latest/api/dialectid.html (accessed 14 October 2026) [19] Abdul-Mageed, M., Zhang, C., Bouamor, H., et al. (2020). NADI 2020: The First Nuanced Arabic Dialect Identification Shared Task. Proceedings of the Fifth Arabic Natural Language Processing Workshop (WANLP 2020), pp. 97-110. https://aclanthology.org/2020.wanlp-1.9/ [20] Talafha, B., Toyin, H. O., Sullivan, P., et al. (2025). NADI 2025: The First Multidialectal Arabic Speech Processing Shared Task. Proceedings of the Third Arabic Natural Language Processing Conference: Shared Tasks (ArabicNLP 2025), pp. 720-733. https://aclanthology.org/2025.arabicnlp-sharedtasks.99/ [21] General Authority for Statistics, Kingdom of Saudi Arabia (2025). Population Estimates Publication 2024. General Authority for Statistics. https://www.stats.gov.sa/documents/20117/2435273/Population+Estimates+Statistics+2024+EN.pdf/9b71e303-5fd9-19cb-9913-850a9d521639 (accessed 14 October 2026) [22] Ministry of External Affairs, Government of India (2026). Population of Overseas Indians. Ministry of External Affairs. https://www.mea.gov.in/population-of-overseas-indians.htm (accessed 14 October 2026) [23] Randall, M. and Samimi, M. A. (2010). The status of English in Dubai. English Today 26(1), pp. 43-50. https://doi.org/10.1017/S0266078409990617 [24] Albaqawi, N. S. (2016). Unity and Diversity within Pidginized Arabic as Produced by Asian Migrant Workers in the Arabian Gulf. Journal of Second Language Teaching and Research 5(1). https://pops.lancashire.ac.uk/index.php/jsltr/article/view/445 [25] The Unicode Consortium (2024). The Unicode Standard, Version 16.0.0, Chapter 9: Middle East-I. The Unicode Consortium. https://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-9/ [26] Goregaokar, M. and Leroy, R. (2026). Unicode Standard Annex #9: Unicode Bidirectional Algorithm, revision 52. The Unicode Consortium. https://www.unicode.org/reports/tr9/ (accessed 14 October 2026) [27] Gerazov, B., Politi, M. and Bratières, S. (2025). Arabic ASR on the SADA Large-Scale Arabic Speech Corpus with Transformer-Based Models. arXiv:2508.12968. https://arxiv.org/abs/2508.12968 [28] Mousi, B., Durrani, N., Ahmad, F., et al. (2025). AraDiCE: Benchmarks for Dialectal and Cultural Capabilities in LLMs. Proceedings of COLING 2025, pp. 4186-4218. https://aclanthology.org/2025.coling-main.283/ [29] CAMeL Lab, New York University Abu Dhabi (2026). camel_tools.utils.normalize: normalization. CAMeL Tools documentation. https://camel-tools.readthedocs.io/en/latest/api/utils/normalize.html (accessed 14 October 2026) ## Cite this paper ```bibtex @techreport{qantara2026howthegulfwrites, title = {How the Gulf writes: Arabizi, code-switching and dialect in business messages}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/how-the-gulf-writes} } ``` ## Disclosure Every number in this paper is quoted from the cited sources; we ran no models and computed no new figures. The message in Table 2 and its annotation, the confirmation described in the pipeline section, the matrix in Figure 3 and the pipeline in Figure 4 are ours, and the message and confirmation are illustrative. Qantara's approach is described as practice, not as results. Canonical: https://qantara.systems/insights/how-the-gulf-writes --- # Compounding agents: evaluation and A/B testing on live operations Technical report. Qantara Research, Qantara. 14 October 2026. 19 min read. > How an operational agent gets better month after month without putting the business at risk: what to test on past cases, what to test on live work, and how many cases each answer needs. ## Abstract Operational agents in Gulf companies handle orders, collections and supplier follow-ups at volumes far smaller than the very large user populations behind consumer A/B testing [1]. We ask how such an agent can be improved repeatedly without putting an untested change in front of customers. We review the literature on online controlled experiments, sequential testing, variance reduction, bandits and language-model evaluation, and compute, with the standard formulas for proportions, how many cases each kind of comparison needs at business-to-business pass rates and volumes. With 200 to 400 cases per version and an 80% baseline pass rate, an unpaired live test detects only changes of about 7 to 10 percentage points; running both versions on the same past cases, marked by the customer's own team, detects a five-point difference with a fraction of the cases. We set out an evaluation ladder (offline evaluation, shadow mode, canary, A/B test, rollout) gated at every step by thresholds the customer sets, with a person above them, and show how improvement compounds when every case and every approval is written to one record that the next evaluation starts from. ## Key findings 1. At business-to-business volumes a live A/B test is blunt: by our computation, with 200 to 400 cases per version and an 80% baseline, it detects only lifts of about 7 to 10 percentage points at 95% confidence and 80% power. 2. Running both versions on the same marked past cases is far cheaper: if they disagree on 10% of cases (an illustrative assumption), 312 cases detect a lift from 75% to 80% that an unpaired test needs 2,188 cases to detect. 3. Checking a live test daily and stopping when it looks good inflates false positives far above the nominal 5%; always-valid p-values allow continuous monitoring without that inflation. 4. Language models used as judges agree with people about as often as people agree with each other in English, but carry position and self-preference biases and are less consistent outside English, so the customer's reviewers remain the reference for Arabic. 5. Improvement compounds when every case and every approval is written to one record, because each becomes a marked case, a regression test or a pre-period measure for the next evaluation. ## 1. Introduction An agent that confirms orders from WhatsApp messages, chases overdue invoices or follows up a late supplier is never finished. Prices change, a branch opens, customers write in a new mix of Arabic and English, and stronger models arrive every few months. The question is how to change it without breaking what works: how to know, before a customer notices, that a new version is better and not merely different. Consumer software answers this question with online controlled experiments run on very large numbers of users [1]. Operations in the Gulf rarely have such numbers. To take illustrative figures, a distributor may confirm a few thousand orders a month and a manufacturer may raise a few hundred credit notes. At these volumes the statistics that make consumer A/B testing routine behave differently from what most teams expect, and a comparison that a consumer app settles in an afternoon can take a quarter. The question is pressing now for two reasons. Agents built on language models are capable enough for live work but not yet consistent: on τ-bench, published in June 2024, state-of-the-art function-calling agents completed fewer than half of the tasks, and in the retail domain fewer than a quarter of tasks were completed in all eight of eight attempts [2]. And a new prompt, tool or model can now be ready in a day, so the bottleneck has moved from building a change to knowing whether it is safe to keep. Two features of the Gulf sharpen the problem. Work arrives in Arabic and English, often in the same message, and the automatic tools for judging language-model output are measurably less consistent outside English [3]. And an owner who hands work to an agent needs to know what it does when nobody is looking, so the method for improving an agent has to be as conservative as the business that runs it. This report makes four contributions: - An evaluation ladder for operational agents, with what each step shows, misses and costs (Section 3). - Sample sizes and minimum detectable effects at business-to-business volumes, with the formula, the code and a calculator (Section 4). - A comparison of designs showing that paired evaluation on past cases needs a fraction of the cases of a live A/B test (Section 4). - A review of where language models can stand in for the customer's reviewers (Section 5), and an account of how improvement compounds through one record (Section 6). ## 2. Background and related work ### Online controlled experiments Kohavi, Tang and Xu distil experimentation at Microsoft, Google and LinkedIn into a practical guide [1]. Several of its ideas carry over to agents: an overall evaluation criterion (The one measure, agreed before a test starts, that decides whether the new version wins. Other measures are reported, but they do not decide.) agreed in advance (their chapter 7), guardrail metrics including the sample ratio mismatch check (chapter 21), the choice of randomisation unit (chapter 14), exposure ramped in steps (chapter 15) and an institutional memory of past experiments (chapter 8). The book is written for web-scale traffic, where small effects are visible; our setting starts where that fails. ### Proportions in small samples The most common measure of an operational agent is a pass rate, the share of cases it handled correctly: a binomial proportion. Wilson's score interval dates from 1927 [4]; Brown, Cai and DasGupta showed that the textbook interval, the estimate plus or minus 1.96 standard errors, has erratic coverage, and recommended the Wilson or Jeffreys intervals for small samples [5]. The sample size for comparing two independent proportions is a standard result [6]; when both versions run on the same items, the comparison is McNemar's test [7], with a sample-size formula due to Connor [8]. Gelman and Carlin warn that in noisy, small-sample settings a significant result is likely to overstate the effect, and can have the wrong sign [9]. ### Sequential testing and variance reduction Two lines of work address the cost of waiting. Miller showed that checking significance after every observation of a test with no real effect, stopping at the first 5% result or after 150 observations, yields a false positive 26.1% of the time [10]. Johari, Koomen, Pekelis and Walsh developed always-valid p-values (P-values that remain valid however often they are checked and whenever the test is stopped, so a team can watch results daily without inflating false alarms.), built on the mixture sequential probability ratio test and deployed on a large commercial A/B testing service [11]. Deng, Xu, Kohavi and Walker introduced CUPED (Controlled-experiment using pre-experiment data: each unit's result is adjusted by what a measurement taken before the test predicts, which shrinks the noise without biasing the comparison.), which uses data from before the experiment as a covariate; on Bing it cut variance by about 50%, the equivalent of half the users or half the time [12]. ### Bandits Thompson's 1933 paper [13] is the origin of Thompson sampling, which sends more traffic to whichever variant currently looks more likely to be best. The tutorial by Russo and colleagues gives the modern treatment, including a section on its limitations [14]. Nie, Tian, Taylor and Zou showed that data collected adaptively, as a bandit collects them, give sample means with a systematic negative bias [15]. ### Interleaving, shadow tests and canaries Interleaving comes from web search: two rankings are merged into one list and the user's clicks credit one or the other. Chapelle, Joachims, Radlinski and Yue found that, in all but one of the pairs they compared, it needed over an order of magnitude fewer queries than absolute click metrics [16]. Shadow testing sends a copy of live requests to a new version while only the current version's responses are returned [17]. Google's site reliability engineers define canarying as a partial, time-limited deployment of a change with its evaluation, advise one canary at a time, and compare the canary with a control population [18]. ### Evaluating language models and agents HELM measured 30 language models on 42 scenarios against 7 metrics, of which accuracy was only one [19]. Zheng and colleagues showed that strong models used as judges reach over 80% agreement with human preferences, the level at which humans agree with each other, and named their position, verbosity and self-enhancement biases [20]. Changing the order of two answers let Vicuna-13B beat ChatGPT on 66 of 80 queries with ChatGPT as the judge [21]; models recognise their own output, and that ability tracks how strongly they favour it [22]. Asked to judge the same content in 25 languages, models agreed with themselves across languages at an average Fleiss' kappa of only about 0.3, with Arabic among the languages where they struggle [3]. On the human side, Shankar and colleagues describe criteria drift: people need criteria to grade outputs, but grading outputs is how they find their criteria [23]. Miller argues that evaluations are experiments: they need standard errors, paired differences when two models answer the same questions, clustering when questions come in groups, and power analysis [24]. For agents specifically, τ-bench introduced pass^k (The share of tasks an agent completes correctly in every one of k repeated attempts. It falls as k grows when the agent is inconsistent.), a measure of reliability over repeated trials [2]. ## 3. The evaluation ladder We describe the path a change takes as a ladder of five steps (Figure 1), each costlier than the one below it and showing something the one below cannot. A change climbs only as far as its risk requires: a new wording for a payment reminder might stop at a canary, while a new model under the orders agent should climb every step. Between steps sits the customer's gate: a version moves up only when its results meet a bar the customer has set, and a person signs off. **Figure 1. The evaluation ladder** Read the top row left to right, then the bottom row right to left; the dashed arrow is the record feeding the next round of evaluation. - Past cases: marked by the team - Offline evaluation: both versions, same cases - Threshold gate: a person signs off - Shadow mode: live inputs, acts on nothing - Canary: a person on every case - A/B test: randomised by account - Rollout: within the thresholds - Operating record: every case and approval - Past cases → Offline evaluation - Offline evaluation → Threshold gate - Threshold gate → Shadow mode - Shadow mode → Canary - Canary → A/B test - A/B test → Rollout - Rollout → Operating record - Operating record → Past cases (new marked cases) Qantara. The steps draw on Kohavi, Tang and Xu (2020) on ramping exposure, the Google SRE Workbook (2018) on canarying and Amazon SageMaker's documentation on shadow tests (read 14 October 2026). The gate is drawn once but applies between every pair of steps. ### Offline evaluation on past cases Offline evaluation is where each agent starts. Before it goes live, it is run on the customer's past cases, and the customer's own team marks what good looks like: the right order lines, the right amount, the right decision to escalate. The cases should cover the work as it really arrives, by branch, channel, language and difficulty. A new version is run on the same cases as the version in service, so that every case yields a paired comparison (Section 4), and cases used to tune a prompt are kept apart from the cases used to judge it. Offline evaluation cannot show how people respond: a reminder can be correct by every measure and still be paid more slowly. Past cases also carry the mix of the past. ### Shadow mode In shadow mode (The new version receives a copy of live work and records what it would have done, but nothing it produces reaches a customer or a system.), the new version writes what it would have done to the log, while the version in service, or the person who does the work today, continues to act. It shows behaviour on today's inputs, cost per case and time to respond, and surfaces inputs the past cases did not contain. Because the incumbent's action is recorded too, every shadow case is also a paired comparison. Its blind spot is offline evaluation's: nothing is sent, so nothing downstream can be observed. ### Canary A canary hands a small share of live work to the new version, with a low threshold so that a person approves every case it touches. It answers a narrow question quickly: does anything break on real work? Following site reliability practice, the canary is compared with a control group over the same days, only one change is in canary at a time, and it runs for at least one full cycle of the work it changes [18]; for collections, that is a payment term. A canary is too small to measure modest improvements. ### A/B test An A/B test randomises live work between versions and measures what only live work can show: days to payment, disputes raised, orders corrected after confirmation. In business-to-business work the randomisation unit should be the customer account rather than the message, so that one buyer does not receive two behaviours in the same week [1]. Assignment should be blocked by language and branch, so that neither version gets more Arabic messages or a harder branch by chance; the test should run in whole weeks; and the criterion and guardrails should be written down first. The price of an A/B test at these volumes is time (Section 4). ### Rollout and the gate A version that passes is rolled out within the same thresholds as before: above them, a person approves, whatever the test said. The thresholds move separately and more slowly. An agent starts with a low threshold and a person on every case, and its limits widen only when its results hold, never for the actions the customer keeps for itself. Table 1 sums up the ladder. **Table 1. What each step shows, what it cannot show, and what it costs** | Step | What it shows | What it cannot show | What it costs | Exposure of customers | | --- | --- | --- | --- | --- | | Offline evaluation | Whether the new version gets marked cases right, against the old one | How people respond; today's mix of work | The team's marking time; compute | None | | Shadow mode | Behaviour, cost and speed on live inputs | Anything downstream: nothing is sent | Compute; review of a sample | None | | Canary | That nothing breaks on real work | Modest differences: too few cases | A person on every case | Small, every case approved | | A/B test | The causal effect on outcomes such as days to payment | Effects below its minimum detectable effect | Weeks to months at these volumes | Half the work, within thresholds | | Interleaving | Which of two rankings people choose from | Anything that is not a ranked proposal | Merging two lists | Low: a person still chooses | | Bandit | Which low-stakes variant earns most while testing | An unbiased estimate of the difference | Little, but estimates are biased | Low, by design | | Rollout | That the effect holds at full volume | Slow effects, such as trust over a year | Monitoring the guardrails | Full, within thresholds | Interleaving and bandits are live methods for narrower questions (Section 4); they sit beside the A/B test, not on the main ladder. ## 4. The statistics of small volumes ### A pass rate is an interval Suppose, as an illustrative example, that a new version handles 45 of 50 marked cases correctly. The point estimate is 90%, but the 95% Wilson interval (A confidence interval for a proportion that stays between 0 and 100% and keeps close to its stated coverage at small sample sizes, unlike the textbook plus-or-minus formula.) runs from 78.6% to 95.7% (our computation), while the textbook interval would claim 81.7% to 98.3%. Fifty cases cannot tell an 80% agent from a 95% one, and even a perfect 50 of 50 is consistent with a true failure rate of up to about 7%: its Wilson lower bound is 92.9%. A pass rate should always be reported with its interval and its number of cases [5]. ### How many cases a comparison needs For two independent groups, the cases each version needs to detect a lift from a baseline pass rate p₁ to a new rate p₂, at two-sided 95% confidence and 80% power, follow from the standard normal-approximation formula [6]. We state it and publish the code we ran. **The two-proportion formula** n per version = [ z(0.975) × √(2 p̄ (1 − p̄)) + z(0.80) × √(p₁ (1 − p₁) + p₂ (1 − p₂)) ]² ÷ (p₂ − p₁)², where p̄ = (p₁ + p₂) ÷ 2, z(0.975) ≈ 1.960 and z(0.80) ≈ 0.842. No continuity correction is applied; with one, the numbers rise slightly. ```python from math import ceil, sqrt from statistics import NormalDist z = NormalDist().inv_cdf za, zb = z(0.975), z(0.80) # 95% confidence (two-sided), 80% power def cases_per_version(p1, lift): # Two independent groups; normal approximation, no continuity correction p2 = p1 + lift pbar = (p1 + p2) / 2 a = za * sqrt(2 * pbar * (1 - pbar)) b = zb * sqrt(p1 * (1 - p1) + p2 * (1 - p2)) return ceil((a + b) ** 2 / lift ** 2) def cases_paired(disagree, lift): # Same cases, both versions (Connor, 1987); disagree = share of discordant cases a = za * sqrt(disagree) b = zb * sqrt(disagree - lift ** 2) return ceil((a + b) ** 2 / lift ** 2) def smallest_lift(p1, n): # Minimum detectable effect for n cases per version, by bisection lo, hi = 0.0001, 1 - p1 - 1e-9 for _ in range(60): mid = (lo + hi) / 2 lo, hi = (mid, hi) if cases_per_version(p1, mid) > n else (lo, mid) return hi def wilson(passed, n): p, d = passed / n, 1 + za ** 2 / n centre = (p + za ** 2 / (2 * n)) / d half = za * sqrt(p * (1 - p) / n + za ** 2 / (4 * n * n)) / d return centre - half, centre + half # Figure 2: baselines 60%, 75%, 85%; lifts of 2 to 10 points fig2 = [[cases_per_version(b, k / 100) for k in range(2, 11)] for b in (0.60, 0.75, 0.85)] # Figure 3: a lift from 75% to 80%, four designs (distinct cases) unpaired = 2 * cases_per_version(0.75, 0.05) # 2188 cuped = 2 * ceil(cases_per_version(0.75, 0.05) * (1 - 0.5 ** 2)) # 1642, correlation 0.5 paired = cases_paired(0.20, 0.05), cases_paired(0.10, 0.05) # 626, 312 [round(100 * smallest_lift(0.80, n), 1) for n in (100, 200, 400, 1000)] # 13.4, 10.0, 7.3, 4.8 wilson(45, 50) # (0.786, 0.957) ``` The computation behind Figures 2 and 3 and the numbers in this section, as we ran it on 14 October 2026 with the Python standard library. Figure 2 plots the result for three baselines. The curve is steep: halving the lift to be detected roughly quadruples the cases needed, since the sample grows with the inverse square of the difference. A higher baseline helps, because a pass rate near 85% varies less than one near 60%. From a 75% baseline, a 5-point lift needs 1,094 cases per version and a 2-point lift needs 7,157. **Figure 2. Cases needed per version to detect a lift in pass rate** Pick a baseline line and a lift on the horizontal axis, in percentage points; the height is the number of cases each version needs at 95% confidence and 80% power. | x | Baseline 60% (cases per version) | Baseline 75% (cases per version) | Baseline 85% (cases per version) | | --- | --- | --- | --- | | +2 pts | 9336 | 7157 | 4724 | | +3 pts | 4129 | 3135 | 2036 | | +4 pts | 2311 | 1737 | 1109 | | +5 pts | 1471 | 1094 | 686 | | +6 pts | 1016 | 748 | 460 | | +7 pts | 742 | 540 | 325 | | +8 pts | 564 | 406 | 239 | | +9 pts | 443 | 315 | 181 | | +10 pts | 356 | 250 | 141 | Qantara, computed with the two-proportion formula above (Fleiss, Levin and Paik, 2003), two-sided, without continuity correction, on 14 October 2026. **Figure 3. Cases needed for your own pass rate** (interactive on the page) Set today's pass rate and the lift you want to detect; the calculator returns the cases each version needs at 95% confidence and 80% power, with the same formula as Figure 2. n = (z_{α/2}·√(2p̄(1−p̄)) + z_β·√(p₁(1−p₁) + p₂(1−p₂)))² / (p₂ − p₁)², cases each variant needs to tell success rate p₁ from p₂, with p̄ = (p₁ + p₂)/2. Turned around, the same formula gives the minimum detectable effect (The smallest true difference a test of a given size would detect with the stated power, here 80%. Smaller differences may exist, but the test would usually miss them.) for the volume a business actually has. From an 80% baseline, 100 cases per version detect only a lift of about 13.4 points; 200 cases, 10.0 points; 400 cases, 7.3 points; 1,000 cases, 4.8 points (our computation). A company handling, for illustration, 800 cases of one kind a month, split evenly, can expect a one-month test to detect a change of about seven points and to miss anything smaller. Running such a test anyway is not harmless: if an underpowered test does reach significance, its estimate is likely to exaggerate the true effect [9]. ### Pairing: the same cases, both versions Offline evaluation and shadow mode allow a different design. Both versions see the same cases, and only the cases on which they disagree carry information. McNemar's test uses exactly these discordant (Cases on which one version passed and the other failed. In a paired comparison only these carry information; cases that both pass or both fail cancel out.) cases [7], and Connor's formula gives the cases needed from the share of disagreements and the difference to be detected [8]. A new version of a working agent usually agrees with the old one on most cases, which is what makes pairing cheap. Figure 3 puts the designs side by side for one question: detecting a lift from 75% to 80%. An unpaired A/B test needs 2,188 distinct cases in total; with a pre-period measure that correlates with the outcome at 0.5, CUPED brings that to 1,642 [12]. Running both versions on the same cases needs 626 cases if they disagree on 20% of them, and 312 if they disagree on 10%. The correlation and disagreement rates are illustrative; the formulas are not. Two cautions apply. A paired offline comparison measures agreement with the team's marks, not the customer's response, so it complements a live test rather than replacing one. And when a few large accounts supply most cases, standard errors should be clustered by account, which raises the numbers [24]. **Figure 4. One question, four designs: distinct cases needed** Each bar is the number of distinct cases needed to detect a lift from 75% to 80% at 95% confidence and 80% power; a shorter bar is a cheaper design. | | cases | | --- | --- | | A/B test, two separate groups | 2188 | | A/B test with CUPED, correlation 0.5 | 1642 | | Same cases, both versions, 20% disagree | 626 | | Same cases, both versions, 10% disagree | 312 | Qantara, computed on 14 October 2026 with the code above. Unpaired: the two-proportion formula, both groups together. With CUPED: assumes a correlation of 0.5 between a pre-period measure and the outcome. Paired: Connor's formula, assuming the versions disagree on 20% or 10% of cases. The correlation and disagreement rates are illustrative. ### Watching a live test A live test that takes weeks will be looked at every day, and should be, since a guardrail breach must stop it at once. But a p-value checked daily, with the test stopped when it first dips below 5%, does not have a 5% error rate; in Miller's worst case it was 26.1% [10]. There are three sound options: fix the horizon in advance and decide once; set a few checkpoints in advance, each with a stricter threshold; or use always-valid p-values, which may be checked at any time [11], at the price of somewhat less power than a single look at a well-chosen horizon. For operational agents the third is the most natural, since guardrails and the main criterion can then be watched continuously. ### Variance reduction from the record CUPED subtracts from each unit's outcome the part that a pre-experiment measurement predicts, which reduces the variance by a factor of one minus the squared correlation between the two [12]. For a collections agent randomised by customer, the natural covariate is the customer's own history: days to pay last quarter predicts days to pay this month. With a correlation of 0.5 the cases needed fall by a quarter; at 0.7, by roughly half. The covariate must exist before the test begins, recorded the same way for both groups: a company whose history is split between an ERP, a spreadsheet and a WhatsApp group has no clean pre-period to adjust by. ### Bandits, and when not to use them Thompson sampling moves traffic towards the leading variant as evidence accumulates, which helps when showing a weaker one has a real cost [13, 14]. In operations it suits low-stakes variants with fast feedback, such as the wording of a message offering delivery slots, where the reply comes within minutes and every variant sits within the thresholds. It is the wrong tool in four common situations. When the decision is whether to widen an agent's threshold, the owner needs an unbiased estimate of the difference, and adaptively collected data do not provide one [15]. When the outcome is slow, as a payment is, the bandit allocates for weeks on evidence that has not arrived. When the work shifts, as order patterns do around Ramadan and the Eid holidays, a settled bandit keeps favouring a winner chosen in a different month; a drifting system calls for exploration that never stops [14]. And at low volumes a bandit starves the trailing variant, so the comparison never becomes conclusive. ### Interleaving, where an agent proposes a list Some agents propose rather than act: the three suppliers to ask for a quotation, the delivery slots to offer, the overdue invoices to chase first. Where a person chooses from a ranked list, the two versions' rankings can be merged into one list, and the item the person picks credits the version that ranked it. In web search this needed over an order of magnitude fewer queries than comparing separate groups [16]. The gain will not carry over unchanged to a purchasing officer choosing suppliers, but where there is a ranked proposal and a choice, interleaving is the cheapest live comparison available. ## 5. Who marks the cases ### The customer's team is the reference Every number in Section 4 assumes that someone has decided what counts as a pass. In operations that call belongs to the people who do the work: the credit controller knows whether a reminder was right to send, the warehouse lead whether a short delivery was recorded correctly. Marking is also how the criteria are found: people need criteria to grade outputs, while grading outputs is what helps them define the criteria [23]. The rubric should be expected to change in the first rounds: two people mark the same sample, their disagreements become clarifications, and marking repeats until the rubric settles. ### Score the action, then the words Most of what an operational agent produces can be checked without a judge. The order lines, amount, date, account and decision to escalate are structured, and each can be compared exactly with the team's mark or with what the ERP later recorded. Only the wording needs judgement, and it is the smaller part of the risk; scoring the action exactly and the wording separately is cheaper and harder to fool than one overall verdict. And since one metric is not enough [19], the report for each version should also give its escalation rate, cost per case and time to act, each with an interval. ### Language models as judges For the wording, a language model can extend a small team's reach, but only once measured against that team. Agreement with human preferences above 80% in English [20] sits beside a position bias strong enough to reverse a ranking [21], a preference for a model's own output [22], and weaker consistency outside English, with Arabic named among the languages where judges struggle [3]. None of these studies used Gulf business messages that mix Arabic and English, so their numbers indicate a direction, not a level. Five practical rules follow. 1. Use a judge from a different model family from the agent's. 2. Present the two versions in both orders, and count only the verdicts that agree. 3. Judge against the marked reference, not on open-ended quality. 4. Measure the judge's agreement with the team on a held-out sample, separately for Arabic, English and mixed messages, and report it. 5. Until that agreement has been measured for a language, keep people as the judges for it. ### Repeat each case An agent built on a language model can give different answers to the same case, and a single run per case mixes that randomness into the comparison. Running each case several times, and reporting both the mean pass rate and pass^k, separates a version that is better on average from one that is more dependable [2, 24]. For an agent that will act within thresholds without a person, dependability is the property that matters. ## 6. How improvement compounds The ladder would be expensive if every evaluation started from nothing. It need not, because every step writes to the same record. Each case the agent handles is written with what it read and did; each action is a line in the log; each decision a person takes above a threshold is a mark, given at no extra cost by someone who would have decided anyway. These entries become the material Section 4 needs. - Marked cases. Each approval or rejection above a threshold is a labelled case for the next offline evaluation. Approvals cover only the cases above the threshold, so a fixed share of the cases below it should also be sampled for review, to keep the evaluation set representative. - Regression cases. Each failure, once found, becomes a case that every later version must pass, so a version that brings back an old mistake is stopped offline. - Pre-period measures. Each customer's, branch's and supplier's history, recorded the same way every month, is the covariate variance reduction needs. - Paired material. The version in service has already handled each recorded case, so a new version can be run on the same cases and compared pair by pair. This is the sense in which agents compound. The next agent starts where the last one ended: a collections agent can be evaluated on invoices that the orders agent wrote, against payment outcomes that the record already holds. Each evaluation is cheaper and sharper than the last, not because models improve by themselves but because the evidence for judging them accumulates in one place. The thresholds move on the same evidence. As an illustrative rule: widen an agent's limit for an action only when the lower Wilson bound of its pass rate, over its most recent cases at the current limit, is above the bar the customer set, and never for the actions the customer keeps for itself. Each widening then becomes a decision the customer can check against the record. ## 7. Implications for deployment For a Gulf company putting agents into its operations, the analysis suggests seven practices. - Agree the measure before the change: the criterion and the guardrails, in writing, in Arabic and English. - Do most of the learning offline. Paired evaluation on marked past cases settles most questions with hundreds of cases, not thousands. - Size every live test first. If the volume cannot detect the effect that matters within a quarter, release behind the thresholds and watch the guardrails instead. - Randomise by account and block by language, in whole weeks, and avoid comparisons that straddle Ramadan or the Eid holidays. - Monitor with always-valid inference, so a harmful change can be stopped on the day it shows. - Keep the team as the reference, and measure any model judge against its marks, language by language. - Report intervals, not points, with the number of cases behind each. This is how we approach it at Qantara. Named engineers work on site inside the customer's operation, write down how the work really runs and record a baseline. Each agent is run on the customer's past cases before it goes live, with their team marking what good looks like; it starts with a low threshold and a person on every case, and its limits widen only when the results hold. The thresholds are the customer's, and above them a person approves. Every read and write is a line in the log, and every agent writes to one operating record, kept in the customer's country, from which the next evaluation starts. ## 8. Limitations This report proposes a method and computes its cost; it reports no deployment results and uses no customer data. - Approximations. The sample sizes use the normal approximation without continuity correction; near 0% or 100%, or below a few dozen cases, exact methods are more reliable and usually ask for more cases. - Assumed parameters. The savings from pairing and CUPED rest on an assumed disagreement rate and correlation. Both must be measured on each workflow, and either could be less favourable. - Independence. The formulas treat cases as independent; cases from the same customer, day or batch are correlated, which raises the numbers. - Judges in Arabic. The evidence on model judges comes mostly from English chat and summarisation. Our Arabic evidence is one summarisation dataset in a multilingual study; we found nothing that measures judges on Gulf business messages. - Long-term effects. No step on the ladder measures slow effects, such as a customer's trust after a year of reminders; measuring long-term effects is a problem of its own [1]. - Volume. A group running one workflow across many companies may have the volume to make live A/B tests routine. ## 9. Conclusion At the volumes of Gulf operations, the live A/B test is a slow and blunt instrument. It remains necessary for outcomes that only customers reveal, but it cannot carry the weight of everyday improvement. That weight falls on paired evaluation over past cases the customer's team has marked, on shadow and canary runs that risk little or nothing, and on thresholds above which a person still decides. Improvement compounds when the evidence for each decision accumulates in one place. Each case an agent handles, each approval a person gives and each failure that is found becomes material for the next evaluation, so the next version is judged faster and more surely than the last. The method is conservative by design, which is what a business that has to run every day requires. ## References [1] Kohavi, R., Tang, D. and Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press. https://www.cambridge.org/core/books/trustworthy-online-controlled-experiments/D97B26382EB0EB2DC2019A7A7B518F59 [2] Yao, S., Shinn, N., Razavi, P., et al. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045. https://arxiv.org/abs/2406.12045 [3] Fu, X. and Liu, W. (2025). How Reliable is Multilingual LLM-as-a-Judge?. Findings of the Association for Computational Linguistics: EMNLP 2025. https://aclanthology.org/2025.findings-emnlp.587/ [4] Wilson, E. B. (1927). Probable Inference, the Law of Succession, and Statistical Inference. Journal of the American Statistical Association 22(158): 209-212. https://doi.org/10.1080/01621459.1927.10502953 [5] Brown, L. D., Cai, T. T. and DasGupta, A. (2001). Interval Estimation for a Binomial Proportion. Statistical Science 16(2): 101-133. https://doi.org/10.1214/ss/1009213286 [6] Fleiss, J. L., Levin, B. and Paik, M. C. (2003). Statistical Methods for Rates and Proportions, third edition (chapter 4: Determining Sample Sizes Needed to Detect a Difference between Two Proportions). Wiley. https://doi.org/10.1002/0471445428 [7] McNemar, Q. (1947). Note on the Sampling Error of the Difference Between Correlated Proportions or Percentages. Psychometrika 12(2): 153-157. https://doi.org/10.1007/BF02295996 [8] Connor, R. J. (1987). Sample Size for Testing Differences in Proportions for the Paired-Sample Design. Biometrics 43(1): 207-211. https://doi.org/10.2307/2531961 [9] Gelman, A. and Carlin, J. (2014). Beyond Power Calculations: Assessing Type S (Sign) and Type M (Magnitude) Errors. Perspectives on Psychological Science 9(6): 641-651. https://doi.org/10.1177/1745691614551642 [10] Miller, E. (2010). How Not To Run an A/B Test. evanmiller.org. https://www.evanmiller.org/how-not-to-run-an-ab-test.html (accessed 14 October 2026) [11] Johari, R., Koomen, P., Pekelis, L., et al. (2022). Always Valid Inference: Continuous Monitoring of A/B Tests. Operations Research 70(3): 1806-1821. https://doi.org/10.1287/opre.2021.2135 [12] Deng, A., Xu, Y., Kohavi, R., et al. (2013). Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data. Proceedings of WSDM 2013. https://doi.org/10.1145/2433396.2433413 [13] Thompson, W. R. (1933). On the Likelihood that One Unknown Probability Exceeds Another in View of the Evidence of Two Samples. Biometrika 25(3/4): 285-294. https://doi.org/10.2307/2332286 [14] Russo, D., Van Roy, B., Kazerouni, A., et al. (2018). A Tutorial on Thompson Sampling. Foundations and Trends in Machine Learning 11(1): 1-96. https://arxiv.org/abs/1707.02038 [15] Nie, X., Tian, X., Taylor, J., et al. (2018). Why Adaptively Collected Data Have Negative Bias and How to Correct for It. Proceedings of AISTATS 2018, PMLR 84: 1261-1269. https://proceedings.mlr.press/v84/nie18a.html [16] Chapelle, O., Joachims, T., Radlinski, F., et al. (2012). Large-Scale Validation and Analysis of Interleaved Search Evaluation. ACM Transactions on Information Systems 30(1). https://doi.org/10.1145/2094072.2094078 [17] Amazon Web Services (2026). Shadow tests. Amazon SageMaker AI Developer Guide. https://docs.aws.amazon.com/sagemaker/latest/dg/shadow-tests.html (accessed 14 October 2026) [18] Warner, A., Davidovič, Š., Hidalgo, A., et al. (2018). Canarying Releases. The Site Reliability Workbook, Google and O'Reilly. https://sre.google/workbook/canarying-releases/ (accessed 14 October 2026) [19] Liang, P., Bommasani, R., Lee, T., et al. (2023). Holistic Evaluation of Language Models. Transactions on Machine Learning Research. https://arxiv.org/abs/2211.09110 [20] Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks Track. https://arxiv.org/abs/2306.05685 [21] Wang, P., Li, L., Chen, L., et al. (2024). Large Language Models are not Fair Evaluators. Proceedings of ACL 2024. https://aclanthology.org/2024.acl-long.511/ [22] Panickssery, A., Bowman, S. R. and Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. Advances in Neural Information Processing Systems 37 (NeurIPS 2024). https://arxiv.org/abs/2404.13076 [23] Shankar, S., Zamfirescu-Pereira, J. D., Hartmann, B., et al. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. Proceedings of UIST 2024. https://doi.org/10.1145/3654777.3676450 [24] Miller, E. (2024). Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations. arXiv:2411.00640. https://arxiv.org/abs/2411.00640 ## Cite this paper ```bibtex @techreport{qantara2026compoundingagents, title = {Compounding agents: evaluation and A/B testing on live operations}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/compounding-agents} } ``` ## Disclosure Cited: every published result, taken from the source named and checked on 14 October 2026. Ours: the sample sizes, minimum detectable effects, Wilson intervals and the comparison of designs, computed with the code in Section 4, and the evaluation ladder as a method. Illustrative: the volumes in the introduction and Section 4, the correlation and disagreement rates behind Figure 3, the 45-of-50 example and the threshold rule in Section 6. No customer data and no Qantara results are reported. Canonical: https://qantara.systems/insights/compounding-agents --- # Inside the workflow engine: durable execution for operational agents Technical report. Qantara Research, Qantara. 14 October 2026. 21 min read. > How we build agents that carry an order across three days and five systems without losing it, doing it twice or doing it unseen. ## Abstract Operational agents do not answer a question and stop. A sales order taken on WhatsApp by a Gulf distributor can take three days to finish and touch five systems: the chat, the ERP, a manager's phone, the e-invoicing authority and the delivery schedule. This technical report asks what an agent needs beneath the model to carry such work to the end without losing it, doing it twice or doing it unseen. We review work on language-model agents, durable execution, sagas, idempotency, event sourcing and connector standards, and set out the design we follow: a workflow written as code whose every step is recorded before the next begins, model calls treated as recorded steps, writes that carry idempotency keys, compensating actions declared beside the steps they undo, approval gates that wait durably for a person above the customer's threshold, and an identity and a log line for every read and write an agent makes. We work the design through an illustrative order that survives a crash, and through Saudi e-invoicing clearance, whose official guidelines prescribe retries, evidence and credit notes. We report no measurements; the contribution is the design and its reasoning. ## Key findings 1. A chat loop keeps its state in one process's memory, so a restart, a lost response or a day's wait for a person loses the work; operations need state that outlives the process. 2. Durable execution records each step's result in an append-only history and rebuilds a workflow by replaying it, which lets a model's answer be recorded once and read back as data instead of being asked for again. 3. Replay makes a workflow resumable, not exactly-once: the step in flight when a worker dies can run twice, so every write to a customer's system carries an idempotency key, and steps that cannot be undone come after the checks that could stop them. 4. Some Gulf systems define recovery in writing: Saudi e-invoicing guidelines prescribe retrying an unanswered clearance, keeping evidence of the attempts and cancelling only by credit note, which map directly onto retries, logs and compensating actions. 5. An approval gate is a durable wait, not a prompt: the workflow can wait days for a person above the threshold at no cost, and the decision becomes a line in the log with the approver's name. ## 1. Introduction An agent that answers a question is finished when the answer is sent. An agent that runs an operation is not. Take an illustrative order at a Gulf food distributor: a hotel group writes on WhatsApp asking for forty cartons for Wednesday. The order must be checked against stock and credit in the ERP, approved by the sales manager because it is above the customer's limit, written to the ERP, cleared as an e-invoice where the country requires it and scheduled for delivery, with the customer told at each turn in the language they wrote in. It spans three days and five systems, and for most of that time it is waiting: for a person, for an authority's server or for a van. Most agents in the literature are built for a different shape of work: a loop in which a model reasons, calls a tool, reads the result and reasons again until it can answer [1, 2]. Wrapped around an operation, that loop fails in ways unrelated to the model's intelligence. The process restarts and the order is forgotten; a timeout hides whether the ERP accepted a write, and the retry creates a second order; the wait for approval outlives the session. Distributed systems engineering has names and tested answers for each, from sagas [3] to durable execution (Running a program so that it finishes despite crashes of the machines running it, by recording each step's result and rebuilding the program's state from that record.) [4]. This report sets out how Qantara designs the layer beneath the model, the workflow engine, for agents that run operations in Gulf companies. It is written for the IT teams asked to give an agent a login, and for engineers who want to know how we think. It contributes: - An account of why chat loops fail on operational work (section 3). - A design that puts the model inside a durable workflow: recorded steps and model calls, idempotent writes, declared compensations and durable approval gates (sections 4 to 8). - A treatment of timeouts, retries, dead letters, replay and audit, with a table of failure modes (sections 9 and 10). - Two Gulf constraints worked through the design: Saudi e-invoicing clearance [5] and the 24-hour customer service window on WhatsApp [6]. This is a design and its reasoning. We report no performance figures, and the worked examples, the order above among them, are illustrative. ## 2. Background and related work ### Workflows and agents Anthropic's guidance on building agents draws the distinction we rely on. In a workflow, models and tools are orchestrated through code paths fixed in advance; in an agent, the model directs its own process and tool use [1]. The guidance recommends the simplest arrangement that works, notes that agents trade cost and compounding errors for flexibility, and suggests pausing for human feedback at checkpoints [1]. Operational work mixes the two: the order of the steps is known and belongs in code, while reading a voice note or drafting a reply inside a step is where a model earns its place. ### Tool use and reliability ReAct showed that interleaving reasoning with actions lets a model act on an environment and revise its plan from what it observes [2]; Toolformer, that a model can teach itself when and how to call APIs [7]. Together they made the tool-calling loop the default shape of an agent. Evaluation has since turned to reliability. In τ-bench, where agents serve simulated customers under a domain policy, even strong function-calling agents completed under half the tasks, and gpt-4o's pass^k (The chance that an agent succeeds on all of k independent attempts at the same task. Unlike pass@k, it falls as k rises unless the agent is consistent.) over eight trials was below 25 percent in the retail domain [8]. For operations, consistency is what matters: the same kind of order arrives many times a day. ### Durable execution and event sourcing Temporal runs application code as a durable execution: a workflow runs to completion, and if the process running it crashes, another rebuilds its state and resumes where the first stopped [4]. The mechanism is the event history (The append-only list of everything that has happened in one workflow execution: steps scheduled and completed, timers started and fired, messages received.), a durable log of everything that happened in an execution, which a worker replays to recreate state [9]. Microsoft's Durable Functions use the same design under the name event sourcing [10]. Both require orchestration code to be deterministic, and both push anything that touches the outside world into separately executed, retried units [11, 10]. Fowler described event sourcing in 2005: every change to application state is captured as an event, so state can be rebuilt by replaying the log. He also named the difficulty that matters for agents: external systems cannot tell a replay from the real thing, so calls to them must be switched off, or answered from recorded responses, during replay [12]. ### Sagas, idempotency and the outbox Garcia-Molina and Salem introduced the saga (A long business transaction written as a sequence of steps, each paired with a compensating step that undoes its effect if the whole sequence cannot finish.) in 1987: a long-lived transaction is written as a sequence of shorter ones, and if it cannot complete, compensating transactions undo the parts that did [3]. Microsoft's pattern guidance adds that compensation is application-specific, need not restore the original state and can itself fail, and that points of no return should come only after every critical check [13]. Stripe's API accepts a client-generated idempotency key (A unique value sent with a write so that the receiving system can recognise a retry and return the first result instead of acting twice.) on each write and returns the first result to any retry with the same key, so a request repeated after a connection error creates nothing new [14]. The Idempotent Receiver pattern generalises this to any server that identifies requests and ignores duplicates [15]. The transactional outbox writes a state change and its outgoing message in one local transaction and relays the message later, which can publish it twice, so consumers must be idempotent [16]. ### Connectors and excessive agency The Model Context Protocol (MCP), specified in November 2024, standardises how applications expose tools and data to models, over JSON-RPC between hosts, clients and servers [17]. Its tools specification says a human should always be able to deny a tool invocation, and that clients should time out tool calls and log tool use for audit [18]; the 2025-03-26 revision added an authorisation framework based on OAuth 2.1 [19]. OWASP's 2025 list of risks for language-model applications names excessive agency, rooted in too much functionality, permission or autonomy, and recommends minimal permissions, human approval of high-impact actions and logging [20]. ### Industry writing HappyRobot's engineering team describes a deterministic workflow layer beneath every agent: an orchestrator holding the global view of the workflow graph, node actors that each run one step, rate limits for large loops, and signals that pause a workflow during a voice call [21]. We share its central choice, a deterministic layer the agent works inside rather than a prompt that holds the process. The post concentrates on graph execution and concurrency and does not discuss persistence, crash recovery, retries or approvals, which are the subject of most of this report. ## 3. Why a chat loop is not an operation The simplest agent is a loop in one process: the model receives the conversation and a list of tools, calls tools, and continues until it answers. Everything it knows about the order lives in the context window and in the process's memory. Put that loop in charge of the order from section 1 and five things go wrong, none of them the model's fault. 1. The process restarts. Deployments, crashes and scaling end processes, and the loop's state ends with them. The order is half done, and nothing knows which half. 2. The wait outlasts the session. The manager approves the next morning. A loop cannot hold a process open for a day, so the wait is dropped or rebuilt by hand. 3. A timeout hides the outcome. The ERP accepts the order but the response is lost. A timeout does not prove the side effect did not happen [22]; the loop retries, and the customer has two orders. 4. The model decides the control flow. Whether to ask for approval becomes a judgement made afresh in each conversation, and repeated trials suggest it will not always be made the same way [8]. A threshold enforced most of the time is not a threshold. 5. Nothing is written down by construction. What the agent read and why it acted sit in a transcript, if anywhere, not in a log the approver or an auditor can open. Figure 1 compares three ways of running an agent. The middle row is what most teams build after the first failure: a queue, a scheduled job and status columns. It works, but every property in it is made by hand. The durable workflow gets most of them by construction; its one partial mark is the subject of section 6. **Figure 1. What each way of running an agent keeps when something fails** Each row is a way of running the same order; each column is a property an operation needs. Yes means the property holds by construction, partial means it holds only in part or only if built by hand. | | Survives a restart | Waits days for a person | Knows which writes landed | Keeps an audit trail | | --- | --- | --- | --- | --- | | A chat loop in one process | no | no | no | partial | | A queue, a scheduled job and status columns | partial | partial | partial | partial | | A durable workflow | yes | yes | partial | yes | Qantara's assessment, from the documentation of Temporal and Durable Functions [4, 10] and the failure modes in section 3. The durable workflow's partial mark is deliberate: replay knows every completed step, but not whether the step in flight when a worker died reached the other system. ## 4. The design: a workflow the agent works inside Our design inverts the chat loop. The workflow, written as code by our engineers with the customer's team, owns the order of the steps, the thresholds and the waits. The model works inside the steps where language is the job: understanding a voice note, proposing a sales order, drafting the reply. The skeleton of the process is a workflow, and agentic behaviour is confined to the steps that need judgement [1]. **Figure 2. One order workflow, from trigger to systems, with one gate** Read left to right: a trigger starts a workflow, the workflow runs its steps in order, and steps reach your systems only through connectors. The dashed arrow is the line each step writes to the record and its log. - Trigger: Message, event or timer - Order workflow: Code, with a history - Record and log: Every read and write - Read stock, credit: Recorded step - Draft the order: Model call, recorded - Approval gate: Above your threshold - Write and invoice: Keyed, compensable - Connectors: The agent's own login - Sales manager: On their phone - Your ERP - E-invoicing: Provider and authority - WhatsApp - Trigger → Order workflow - Order workflow → Read stock, credit - Order workflow → Draft the order - Order workflow → Approval gate - Order workflow → Write and invoice - Order workflow → Record and log (a line per step) - Read stock, credit → Connectors (reads) - Write and invoice → Connectors (writes) - Approval gate → Sales manager - Connectors → Your ERP - Connectors → E-invoicing - Connectors → WhatsApp Qantara's design, drawn for this report. Connectors sign in with the agent's own credentials. The outlined approval gate is the one place the workflow waits for a person. - Trigger. A message, an email, an ERP event or a timer starts one workflow, identified by the business object it concerns. Because its identity is the order's, a second start finds the execution already running; Durable Functions recommends user-chosen instance IDs wherever an orchestration maps one to one onto a purchase order or a document [10]. - Workflow. Deterministic code that calls steps and waits on timers and messages. It never touches a customer's system itself. - Steps. One unit of work each, with a timeout and a retry policy and, where it writes, an idempotency key and a declared compensation. Model calls are steps. - Connectors. The only code that reaches the ERP, the e-invoicing provider, WhatsApp or email, signed in with credentials issued to that agent for that deployment, scoped and revocable by the customer's IT team. - Record and log. Every read, write and approval is a line: who acted, on what, from which channel, approved by whom. ### Model calls are recorded steps A model's answer is not deterministic, so it cannot live in workflow code that replay must re-run identically. Temporal's documentation lists model invocations, with API calls and database queries, among the operations that belong in Activities, which run outside the replay path [11]. Once a model call is a step, its output is written to the history like any other result. After a crash, the workflow does not ask the model again and receive a different draft; it reads back the draft the approver saw. What was approved and what is written to the ERP are, by construction, the same object. ### One agent, one process Each workflow belongs to one agent and one process, with that process's permissions and no others. When the collections agent needs to know an invoice was issued, it reads the line the orders workflow wrote to the record rather than calling into that workflow. Histories stay short enough to read, and credentials narrow enough to grant. ## 5. Durable steps and replay A durable workflow survives the loss of its process because its progress is not kept there. Each step scheduled, timer started or message received is appended to the history. When a worker dies, another loads the history and re-runs the workflow code from the start, taking each completed step's result from the history instead of executing it again, until it reaches the point where the first stopped [9, 10]. A workflow can wait on a durable timer for minutes or months and hold no process while it does [4], which makes a three-day order ordinary. The sketch below shows its shape. ```ts // Illustrative pseudo-code. Each step's result is written to the history // before the next step begins; on replay after a crash, completed steps // return their recorded result instead of running again. export const orderWorkflow = workflow('order', async (ctx, order: Order) => { const credit = await ctx.step('read-credit', erp.readCredit, order.customer); const hold = await ctx.step('reserve-stock', erp.reserve, order.lines, { idempotencyKey: `${ctx.id}:reserve`, // The compensating action, declared beside the step it undoes. compensate: (h) => erp.release(h.id, { idempotencyKey: `${ctx.id}:release` }), }); // A model call is a step like any other: recorded once, replayed as data. const draft = await ctx.step('draft-order', agent.proposeOrder, { order, credit, hold }); // The approval gate: above the customer's threshold, a person decides. if (draft.total > ctx.limits.orderValue || draft.total > credit.headroom) { await ctx.step('ask-approver', approvals.send, { draft, role: 'sales-manager' }); const decision = await ctx.waitFor('approval', { timeout: days(2) }); // A decline, or no answer within two days, counts as not approved. if (decision.approved === false) { return ctx.abandon('declined', decision); // runs compensations in reverse } } // The key is the same on every retry and every replay of this step. const so = await ctx.step('write-order', erp.createSalesOrder, draft, { idempotencyKey: `${ctx.id}:sales-order`, timeout: { perAttempt: seconds(30), deadline: ctx.cutoff('same-day') }, retry: { initial: seconds(1), backoff: 2, maxInterval: seconds(100), jitter: true }, }); // An unanswered submission is retried as the same invoice; // a rejection is not retried, and becomes a case for finance. await ctx.step('clear-invoice', einvoicing.submit, so.invoice, { idempotencyKey: `${ctx.id}:invoice`, nonRetryable: ['rejected'], onDeadLetter: (err) => cases.open('finance', { so, err }), }); await ctx.step('confirm', whatsapp.reply, confirmation(order, so), { idempotencyKey: `${ctx.id}:confirm`, }); }); ``` Illustrative, written for this report: an order workflow with durable steps, an approval gate and a compensating action, in TypeScript-style pseudo-code. It is not the API of any library. Three things carry the weight. Each write's idempotencyKey is derived from the workflow's identity, so it is the same on every retry and replay. The compensation sits beside the step it undoes, so a later failure knows what to release. And the two-day wait for approval is an ordinary line of code, costing nothing but an entry in the history. Figure 3 follows an illustrative order through such a workflow, with a crash at the worst moment. **Figure 3. An illustrative order that survives a crash** Read top to bottom; each entry is an event in one order's life, and the crash is on day 2 at 09:05. - Day 1, 08:12: Order arrives on WhatsApp. A hotel group in Dammam asks for 40 cartons for Wednesday. A workflow starts, keyed to the message. - Day 1, 08:12: Stock reserved, credit read. Two steps; each result is written to the history before the next begins. - Day 1, 08:13: Draft order proposed. A model call, recorded as a step. The order is above the customer's credit headroom. - Day 1, 08:13: Case sent to the sales manager. With what the agent read. The workflow now waits on a message and holds no process. - Day 2, 09:04: Approved on the manager's phone. The decision reaches the waiting workflow and becomes a line in the log, with the approver's name. - Day 2, 09:05: Sales order written; the worker crashes. The ERP has the order. The history does not yet say so. - Day 2, 09:06: Another worker replays and retries. Completed steps return their recorded results. The write is retried with the same key, and the connector finds the existing order. - Day 2, 09:07: E-invoice sent for clearance; no answer. Retried with backoff within the step's deadline; every attempt is logged. - Day 2, 09:31: Invoice cleared; customer told. More than 24 hours since the customer last wrote, so the confirmation goes as an approved template. - Day 3, 07:40: Delivered; the workflow closes. The record holds every read, write and approval, each traceable to its step. Illustrative, written for this report: the customer, the times and the systems are not real. The crash between the ERP accepting the order and the history recording it is the case idempotency keys exist for (section 6). ### Determinism has a cost Replay works only if the workflow code makes the same calls in the same order each time it runs over the same history. Temporal reports a mismatch as a non-determinism error and names two causes: logic that branches on local time or random numbers, and code changes deployed while executions started under the old code are still running [11]. The second matters most for operations, because an order that waits three days will still be running when the next version ships. Temporal recommends worker versioning, which keeps running executions on the code revision that started them [11]. Our rule is the same: orders in flight finish on the code they started with. ### Histories are bounded Temporal caps a single execution's history at 51,200 events or 50 MB, and warns at 10,240 events or 10 MB [23]. An order stays far inside this; a workflow that polls a supplier every hour for a month does not. We scope each workflow to one business object, one order, invoice or shipment, as much for this reason as for readability. ## 6. Writes that happen once in effect Replay makes a workflow resumable, not exactly-once. At day 2, 09:05 in Figure 3, the ERP accepted the sales order and the worker died before the result reached the history. On replay the step shows as started but not completed, so it runs again, and nothing in durable execution can know whether the ERP saw the first attempt. Hence Temporal's expectation that Activities be idempotent, since they will be re-executed after failures [24]. The defence is an idempotency key on every write, derived from the workflow and the step rather than generated at call time, so a retry carries the key of the attempt it repeats. Where the target system supports keys, as Stripe's API does, it returns the first result to every retry [14]. Where it does not, the connector plays the idempotent receiver [15]: it writes the key into a reference field the system keeps, such as the customer's purchase order reference, and searches for that key before creating anything. Two rules close the remaining gaps. Messages that must follow a write are stored in the same local transaction as the step's result and published by a relay, the transactional outbox, to consumers that tolerate duplicates [16]. And steps that cannot be undone come last, after every check that could stop the order [13]. ### A Gulf example: e-invoicing clearance Saudi e-invoicing makes these distinctions concrete. In the integration phase, each tax invoice must pass clearance (The Saudi model for tax invoices between businesses: the authority validates and stamps each invoice in real time, and only then may the seller share it with the buyer.) by ZATCA, the tax authority, before it is shared with the buyer [5]. The authority's detailed guidelines then describe, in effect, a retry policy and a classification of failures. If its servers do not respond, the example taxpayer retries clearance for about five minutes, shares an uncleared invoice while keeping records, and keeps trying about every fifteen minutes, both timings marked as to be confirmed, keeping evidence of its attempts such as an API log. If instead an invoice is rejected, retrying is wrong: the taxpayer corrects it and submits a new invoice with its own counter value and hash, leaving the rejected document's counter and hash unchanged [5]. In our terms, an unanswered request is a retryable failure with a deadline and an evidence requirement, and a rejection is non-retryable and goes to a person. The guidelines also link all invoices from one invoicing unit into a single chain by hash [5], so a duplicate is never harmless. The connector, not the model, assigns each invoice its place in the chain, and the idempotency key ensures an unanswered submission is resent as the same invoice rather than issued again. ## 7. Compensating actions Not every failure can be retried away. The customer cancels after stock is reserved; finance declines to reissue a rejected invoice; the van cannot arrive before the goods expire. A saga pairs each forward step with a compensating step, and runs the compensations for the completed steps when the sequence cannot finish [3]. Compensation is rarely a mirror image. Releasing a stock reservation comes close; reversing an issued invoice does not. The Saudi guidelines forbid modifying or deleting an issued invoice: it is cancelled only by a credit note, itself sent for clearance, and a new invoice [5]. Microsoft's guidance generalises the point: compensation is application-specific, need not restore the original state, can fail, and should be built from idempotent steps so that it can resume [13]. So compensations are declared beside the steps they undo and run as durable steps with their own keys, and any that touches money or a regulator passes the same approval gate as the forward step. Where the better answer is another path, a different van or a partial delivery, the same guidance puts a person in high-impact or ambiguous decisions rather than compensating automatically [13], and so do we. ## 8. Approval gates and agent identity ### The gate is a durable wait Above the thresholds the customer sets, an amount, a customer, a country or an hour of the day, the agent prepares the case and a person decides. In a durable workflow this is a step that sends the case, then a wait on a message with a timeout. Temporal delivers the decision as a Signal, an asynchronous write to the running execution [25]; Durable Functions offers external events for the same purpose and names human interaction as a typical use [10]. The wait can last days at no cost. What the timeout does, remind, escalate or decline, is agreed with the customer, not left to the model. The approver sees what the agent read, the draft and the rule that sent the case to them, on their phone and in Arabic or English, and the decision becomes a line in the log with their name. Because the draft is a recorded step, what was approved is exactly what is written. ### Waits meet the channel's rules On the WhatsApp Business Platform, a customer's message opens a 24-hour customer service window for the business's service messages; after it closes, only pre-approved templates can be sent [6]. An approval that arrives the next morning may land outside the window, so the confirmation step checks the window at send time, from the recorded time of the customer's last message, and uses a template when it must. It is a small rule, and one a chat loop gets wrong on the day a manager is slow to reply. ### Each agent signs in as itself Every connector signs in with credentials issued to that agent for that deployment, never a person's, with permissions the customer's IT team chooses and can revoke. One reason is least privilege: OWASP's 2025 guidance counts excessive permissions among the roots of excessive agency and recommends granting extensions the minimum necessary [20]. The other is attribution. The same guidance suggests acting in the context of the user an action is taken for [20], which suits an assistant working for one person; an operational agent works for the company, so it has an identity of its own, and the ERP's own audit trail says which agent did what. ### Where the Model Context Protocol fits MCP's 2025-03-26 revision adds annotations marking a tool as read-only or destructive, and requires clients to treat them as untrusted unless the server is trusted [26]. We read MCP as a candidate for the connector boundary in Figure 2, beneath the workflow rather than in place of it: the protocol describes how a step calls a tool, while durability, idempotency, compensation and thresholds remain the workflow's job. A tool reached over MCP is still called from a recorded step, with a key, a timeout and the agent's own credentials. ## 9. Timeouts, retries and dead letters Every step has a timeout. Temporal distinguishes a timeout per attempt (Start-To-Close), one across all attempts (Schedule-To-Close), one for time spent queued and a heartbeat timeout, and strongly recommends always setting the first [27]. We set two per step: a per-attempt timeout matched to the system called, and a deadline in business terms, such as the order being in the ERP by the evening cut-off. Temporal retries failed Activities by default with exponential backoff (Waiting longer after each failed attempt, typically doubling the wait, so that a struggling system is not hit with retries at full rate.): one second at first, doubling on each retry up to 100 times the initial interval, with no limit on attempts unless one is set [24]. Figure 4 shows what that means in time. **Figure 4. The default retry schedule never stops on its own** The x axis counts retries of one failing step; the lower line is the wait before each retry and the upper line the total time waited so far, both in seconds. | x | Wait before this retry (seconds) | Total waited so far (seconds) | | --- | --- | --- | | 1 | 1 | 1 | | 2 | 2 | 3 | | 3 | 4 | 7 | | 4 | 8 | 15 | | 5 | 16 | 31 | | 6 | 32 | 63 | | 7 | 64 | 127 | | 8 | 100 | 227 | | 9 | 100 | 327 | | 10 | 100 | 427 | | 11 | 100 | 527 | | 12 | 100 | 627 | Qantara, computed from the default retry policy in Temporal's documentation (initial interval 1 second, backoff coefficient 2.0, maximum interval 100 seconds, unlimited attempts), accessed 14 October 2026 [24]. The time each attempt itself takes, and any jitter, are not included. The wait reaches 64 seconds before the seventh retry and the 100-second ceiling at the eighth, then repeats for as long as the step fails; after twelve retries the step has waited 627 seconds. That suits a passing fault, not a business process, so the deadline matters more than the count. Retries happen at one layer only, because they multiply: in Brooker's example, five layers each retrying independently raise the load on the database at the bottom 243 times [22]. They are spread with jitter, so that workflows failing on the same outage do not retry in step [28]. And errors are classified: a timeout or an unavailable server is retryable, a rejection is not. When the deadline passes or the retries run out, the work becomes a dead letter (A message or piece of work that cannot be completed, set aside in a place of its own for a person to examine, rather than dropped or retried forever.), the messaging pattern for a message a system cannot or should not deliver, set aside on a channel of its own [29]. In our design it is a case for a person, carrying the step, every attempt with its error and what the agent had read, in the place the customer's team already works. Table 1 gathers the failure modes and how each is handled. **Table 1. Failure modes of an operational workflow and how the design handles each. Qantara's design; the mechanisms are those described in sections 4 to 9.** | Failure | What it looks like | How it is handled | Where it shows | | --- | --- | --- | --- | | Worker crash or deployment | A workflow stops in the middle of a step | Another worker replays the history and resumes; completed steps are not run again | The history; the log only if a step is retried | | Timeout on a write | The ERP may or may not have the order | Retried with the same idempotency key; the connector finds the existing document | One log line per attempt | | Transient error | A busy server, a dropped connection, an authority not answering | Retried with exponential backoff and jitter, within the step's deadline | Each attempt in the log | | Non-retryable error | A validation failure, a rejected invoice, a blocked account | No retry; a case for a person, with the error and what was read | A case in the team's queue | | Deadline passed | Retries would run past the business cut-off | Dead letter: the step stops and the workflow waits on a person | A case, with every attempt | | No answer from the approver | The person above the threshold does not reply | The timeout agreed with the customer: remind, escalate or decline | A log line for each reminder | | A later step cannot finish | The van cannot deliver; finance will not reissue | Compensating steps run in reverse, each keyed; money and regulator steps pass the gate | Each compensation as its own line | | Model output fails a check | A draft that does not match the order or the rules | The step fails validation and the case goes to a person | The draft and the failed check in the log | | Code changed in flight | A new version deployed while orders wait | Executions finish on the version that started them | The version, recorded per execution | | Channel window closed | A WhatsApp reply more than 24 hours after the customer wrote | An approved template is sent instead of a free-form message | The template sent, in the log | ## 10. Replay and audit A durable workflow keeps two records. The execution history says how the program ran: which step was scheduled, what it returned, when the timer fired. It is what replay reads, and a debugging tool of the first order, since a failed execution can be replayed against corrected code. Durable Functions notes that its append-only history also gives audit trails that support compensating actions [10]. The record and its log say what the business did: which order moved, for whom, at what cost, why, and who approved it. We keep the two apart. Microsoft describes its history table as a debugging aid whose format and content may change [10], and log lines written from workflow code would be duplicated on replay, a behaviour Durable Functions documents for orchestrator logging [10]. Log lines are therefore written by steps, through the outbox, keyed so that a replayed or retried step writes its line once. Table 2 shows one line. **Table 2. The fields of one log line, as a step writes it. Illustrative values, written for this report.** | Field | Illustrative value | Why it is kept | | --- | --- | --- | | When | Day 2, 09:06 | The order of events across systems | | Actor | Orders agent, on its own credential | Which identity acted; never a person's login | | Action | Created a sales order | What was done | | Target | Your ERP: sales order for a hotel group in Dammam | Where it was done | | Read | Stock, credit headroom, the WhatsApp message | What the action rested on | | Approved by | Sales manager, day 2, 09:04 | Who decided above the threshold | | Workflow and step | order/wa-msg-0193, write-order, attempt 2 | Joins the line to the history for replay | | Idempotency key | order/wa-msg-0193:sales-order | Shows a retry was a retry, not a second order | | Channel | WhatsApp | Where the work came from | Regulation points the same way: the Saudi guidelines require an invoicing system to log all user activity in generating invoices, and forbid any modification of those logs [5]. An agent that issues invoices is part of that activity. The history holds every step's inputs and outputs, messages, drafts and model answers included, so it carries the record's data and falls under the same residency answer: the customer's country, with any model call that leaves it named in writing before the workflow goes live. ## 11. Implications for deployment For a Gulf company, the design becomes a short list of decisions, most of them made on site with the team that runs the process today. - Map the steps before the model. Our engineers work inside the operation and write down how an order really moves, waits and workarounds included. The workflow is that map, in code. - Name the points of no return. A cleared invoice, a released credit, a message sent: what cannot be undone, and its compensation. These go last, behind the gate. - Set the thresholds. An amount, a customer, a country, an hour. Above them a person decides, on their phone, in Arabic or English; the thresholds are the customer's to set and to lower. - Issue the credentials. Each agent gets its own login with its process's permissions, scoped to the deployment and revocable. Every read and write is a line in the log. - Agree deadlines and dead letters. For each step, how long is too long in business terms, and who receives the case. - Run it on past cases. Each agent is run on the customer's past cases before it goes live, with their team marking what good looks like; recorded steps make each run inspectable. - Say where it runs. The record, the log and the workflow history stay in the customer's country, and for each workflow we state in writing which model reads what, and where it runs. None of this replaces a system. Connectors read the ERP where the data already is, and write back only what the workflow allows, after the checks and approvals the customer has set. ## 12. Limitations This report describes a design; it does not measure it. We give no figures for crash recovery, duplicate rates or approval times, because we have none we could publish to this paper's standard, and an invented figure would be worse than none. Several parts rest on assumptions that do not always hold. Idempotency on a system without native keys depends on a reference field the connector can search; where there is none, the gap between a write and its record remains, and a person may have to reconcile. Exactly-once effects are never guaranteed across systems we do not control, only made likely and detectable. Durable execution moves complexity into determinism and versioning, which demand discipline from engineers changing workflows that are still running [11]. Our account of Saudi clearance rests on the May 2023 guidelines, whose retry timings are marked as to be confirmed [5], and other Gulf countries are bringing in e-invoicing under their own rules. MCP's authorisation framework was added within months of its first specification [19], and our reading of where it fits may change with it. Finally, the design governs whether work survives and is seen, not whether the model's judgement inside a step is right. Putting control flow in code narrows the inconsistency τ-bench found [8] without removing it; each step a model performs still has to prove itself on the customer's own cases. ## 13. Conclusion An agent that runs an operation is a long-running program that happens to call a model, and it should be built like one. The parts are old and well understood: an append-only history and replay, keys that make retries safe, compensations beside the steps they undo, timeouts and deadlines, and a place for work that cannot finish. Putting a model inside them is simpler than it sounds, once a model call is one more recorded step. In the Gulf the case is sharper. Orders arrive on WhatsApp and are approved on phones, and a tax authority clears invoices in real time and says in writing how to retry and what to keep. An engine that records every step, waits for people without forgetting and logs every read and write is how an agent earns a login to the systems a company depends on. ## References [1] Schluntz, E. and Zhang, B. (2024). Building effective agents. Anthropic engineering blog, 19 December 2024. https://www.anthropic.com/engineering/building-effective-agents (accessed 14 October 2026) [2] Yao, S., Zhao, J., Yu, D., et al. (2022). ReAct: Synergizing reasoning and acting in language models. arXiv:2210.03629; International Conference on Learning Representations (ICLR 2023). https://arxiv.org/abs/2210.03629 [3] Garcia-Molina, H. and Salem, K. (1987). Sagas. Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, pp. 249-259. https://doi.org/10.1145/38713.38742 [4] Temporal Technologies (2026). Understanding Temporal. Temporal documentation. https://docs.temporal.io/evaluate/understanding-temporal (accessed 14 October 2026) [5] Zakat, Tax and Customs Authority (ZATCA) (2023). Detailed guidelines for e-invoicing, version 2 (May 2023). Zakat, Tax and Customs Authority, Kingdom of Saudi Arabia. https://zatca.gov.sa/en/E-Invoicing/Introduction/Guidelines/Documents/E-Invoicing_Detailed__Guideline.pdf (accessed 14 October 2026) [6] Meta (2026). Service messages. WhatsApp Cloud API documentation, Meta for Developers. https://developers.facebook.com/docs/whatsapp/cloud-api/guides/send-messages (accessed 14 October 2026) [7] Schick, T., Dwivedi-Yu, J., Dessì, R., et al. (2023). Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems 36 (NeurIPS 2023); arXiv:2302.04761. https://arxiv.org/abs/2302.04761 [8] Yao, S., Shinn, N., Razavi, P., et al. (2024). τ-bench: A benchmark for tool-agent-user interaction in real-world domains. arXiv:2406.12045. https://arxiv.org/abs/2406.12045 [9] Temporal Technologies (2026). Event History. Temporal documentation. https://docs.temporal.io/encyclopedia/event-history (accessed 14 October 2026) [10] Microsoft (2026). Durable orchestrations overview. Microsoft Learn, Azure documentation. https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-orchestrations (accessed 14 October 2026) [11] Temporal Technologies (2026). Temporal Workflow Definition. Temporal documentation. https://docs.temporal.io/workflow-definition (accessed 14 October 2026) [12] Fowler, M. (2005). Event Sourcing. martinfowler.com. https://martinfowler.com/eaaDev/EventSourcing.html [13] Microsoft (2026). Compensating Transaction pattern. Azure Architecture Center, Microsoft Learn. https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction (accessed 14 October 2026) [14] Stripe (2026). Idempotent requests. Stripe API reference. https://docs.stripe.com/api/idempotent_requests (accessed 14 October 2026) [15] Joshi, U. (2023). Idempotent Receiver. Patterns of Distributed Systems, martinfowler.com. https://martinfowler.com/articles/patterns-of-distributed-systems/idempotent-receiver.html [16] Richardson, C. (2026). Pattern: Transactional outbox. microservices.io. https://microservices.io/patterns/data/transactional-outbox.html (accessed 14 October 2026) [17] Model Context Protocol project (2024). Model Context Protocol specification, version 2024-11-05. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2024-11-05 (accessed 14 October 2026) [18] Model Context Protocol project (2024). Tools, specification version 2024-11-05. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2024-11-05/server/tools (accessed 14 October 2026) [19] Model Context Protocol project (2025). Key changes, specification version 2025-03-26. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2025-03-26/changelog (accessed 14 October 2026) [20] Open Worldwide Application Security Project (2025). LLM06:2025 Excessive Agency. OWASP Top 10 for LLM Applications 2025, Gen AI Security Project. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ (accessed 14 October 2026) [21] Pahawa, K. (2026). Inside HappyRobot's workflow engine. HappyRobot blog, updated 22 September 2026. https://www.happyrobot.ai/blog/inside-happyrobots-workflow-engine (accessed 14 October 2026) [22] Brooker, M. (2019). Timeouts, retries, and backoff with jitter. Amazon Builders' Library, AWS. https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter (accessed 14 October 2026) [23] Temporal Technologies (2026). Workflow Execution limits. Temporal documentation. https://docs.temporal.io/workflow-execution/limits (accessed 14 October 2026) [24] Temporal Technologies (2026). What is a Temporal Retry Policy?. Temporal documentation. https://docs.temporal.io/encyclopedia/retry-policies (accessed 14 October 2026) [25] Temporal Technologies (2026). Temporal Workflow message passing: Signals, Queries and Updates. Temporal documentation. https://docs.temporal.io/encyclopedia/workflow-message-passing (accessed 14 October 2026) [26] Model Context Protocol project (2025). Tools, specification version 2025-03-26. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2025-03-26/server/tools (accessed 14 October 2026) [27] Temporal Technologies (2026). Detecting Activity failures. Temporal documentation. https://docs.temporal.io/encyclopedia/detecting-activity-failures (accessed 14 October 2026) [28] Brooker, M. (2015). Exponential backoff and jitter. AWS Architecture Blog. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ [29] Hohpe, G. and Woolf, B. (2003). Dead Letter Channel. Enterprise Integration Patterns (Addison-Wesley), online pattern catalogue. https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html (accessed 14 October 2026) ## Cite this paper ```bibtex @techreport{qantara2026workflowengine, title = {Inside the workflow engine: durable execution for operational agents}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/workflow-engine} } ``` ## Disclosure Cited: the definitions, mechanisms, defaults and limits of the systems, standards and guidelines named, each checked against its own documentation or paper on 14 October 2026. Ours: the design, the assessment in Figure 1, the computation in Figure 4 and the failure modes in Table 1. Illustrative: the order in the introduction and Figure 3, the code sketch and the log line in Table 2, all written for this report; no customer, deployment or measurement is described. Canonical: https://qantara.systems/insights/workflow-engine --- # Right-sizing models: routing between small and frontier models Research. Qantara Research, Qantara. 14 October 2026. 16 min read. > Most steps in an operational workflow do not need the largest model: how to send each one to the smallest model that does it well, and why Arabic changes the arithmetic. ## Abstract An operational workflow is a chain of steps: classify a message, extract an order, draft a reply, reconcile an invoice. Many deployments send every step to one frontier model. We ask how much of that spend buys quality, and what changes when the work is in Arabic. We review the published evidence on routers and cascades, on distilled, small and quantized models and on caching, and combine it with measured tokenizer costs for Arabic and with list prices read on 14 October 2026. On their own benchmarks, routers and cascades keep most of a frontier model's quality for a fraction of its cost, but the saving varies several-fold by task and depends on how closely the router's training data resembles the traffic it meets. Arabic adds a multiplier: the tokenizer behind ChatGPT and GPT-4 needed 3.04 times as many tokens for Standard Arabic as for the same English text, while tokenizers built for Arabic come close to parity. Routing should therefore be set step by step, on the customer's own past cases, with tokens counted in Arabic, among the models that residency allows. ## Key findings 1. Routers and cascades keep most of a frontier model's quality for much less: FrugalGPT matched GPT-4 on a financial headlines task at 98.3% lower cost, and RouteLLM reached 95% of GPT-4's MT Bench score with a cost saving ratio of 3.66 [1, 2]. 2. The saving depends on the task: the same RouteLLM routers achieved ratios of 1.41 on MMLU and 1.49 on GSM8K, so no published figure transfers to a Gulf workflow without a test on its own past cases [2]. 3. English-centric tokenizers tax Arabic: the one used by ChatGPT and GPT-4 needed 3.04 times as many tokens for Standard Arabic as for the same English text, while the bilingual Jais tokenizer brings Arabic fertility to 1.050 against 1.010 for English [3, 4]. 4. List prices read on 14 October 2026 put the frontier and small models we priced 40 to 100 times apart per token, so the share of steps a small model can take, not its own price, decides most of the bill [5, 6]. 5. The two first-party APIs we reviewed offered in-country inference in the Gulf only in the UAE, for a few models; where data must stay in the country, small open-weight Arabic models run locally become the default [7, 8, 9, 10]. ## 1. Introduction A workflow in a Gulf distributor or logistics company is a chain of steps. An order that arrives on WhatsApp is classified, extracted into lines, checked against the catalogue, confirmed with a reply and, weeks later, reconciled against a delivery note and an invoice. Each step can go to a different model. Most first deployments send all of them to the most capable model available, because that is the surest way to make the first workflow work. That default grows expensive with success. Vendors bill per token (A piece of text, often part of a word, that a model reads or writes. Vendors bill per million tokens read and per million written.), and on the pricing pages we read on 14 October 2026, OpenAI listed gpt-6-astra at $10.00 per million input tokens and $50.00 per million output tokens and gpt-6-luna at $0.10 and $0.50, while Anthropic listed Claude Opus 5.5 at $4 and $20 and Claude Haiku 5.5 at $0.10 and $0.50 [5, 6]. In 2023, Chen, Zaharia and Zou noted that the fees of language model APIs could differ by two orders of magnitude [1]. They still do. The Gulf sharpens the question. The work arrives in Arabic and English, often in the same message, and English-centric tokenizers need several times as many tokens for the same Arabic text [3, 11]. Some data cannot leave the country, which rules models out before price is discussed. And a reply in Gulf Arabic, the output a customer actually reads, is where published evaluations are thinnest and hardest to automate [12]. We ask how a company can keep frontier-level quality at lower cost by sending each step to the smallest model that does it well. This is a review of published evidence with our own arithmetic, not a report on a measured deployment. It contributes: - A review of routing, distillation, quantization and caching (section 2). - A cost model and a calculator at list prices read on 14 October 2026 (section 3). - The Arabic tokenizer premiums, quoted from the studies that measured them (section 4). - A mapping of four common workflow steps to model size, offered as our starting judgement (section 5). - A router design, and a procedure for testing any routing change on the customer's past cases (sections 6 and 7). ## 2. Background and related work Three lines of work bear on the question: choosing which model handles a request, making small models capable of more, and not paying twice for the same tokens. Tokenization follows in section 4. ### Cascades and routers FrugalGPT framed the problem in 2023 [1]. Its cascade sends a query to a cheap model first and moves to a dearer one only when a small scorer, in its case study a DistilBERT regression model, judges the answer unreliable. Matched to the accuracy of the best single model, the cascade cost 98.3% less on HEADLINES, a financial news task, 73.3% less on OVERRULING, a legal one, and 59.2% less on the reading set COQA. A router decides before any model is called. Hybrid LLM predicts from the query alone whether a small model's answer will come close to a large one's, and reports up to 40% fewer calls to the large model with no drop in response quality [13]. The gain shrank as the gap between the pair grew: between Llama-2 7B and 13B, its deterministic router sent 40% of queries to the small model for a 0.2% drop in quality; between Llama-2 13B and GPT-3.5-turbo, the same share cost up to 4% in quality. AutoMix lets the small model check itself through few-shot self-verification, and a router built on a partially observable decision process uses that estimate to decide whether to escalate. It reports more than 50% lower computational cost for comparable performance across five models and five datasets [14]. RouteLLM learned routers from 80,000 human preference battles in Chatbot Arena, augmented with comparisons judged by GPT-4, and sends each query to one of GPT-4 or Mixtral 8x7B [2]. Its best routers reached 95% of GPT-4's score on MT Bench [15] with a cost saving ratio of 3.66 against a random router, and its most expensive router added under 0.4% to the cost of GPT-4 generation. **Table 1. Four published approaches to sending queries to a cheaper model, and what each reports on its own benchmarks.** | Method | Decides | Learns from | Reported result | | --- | --- | --- | --- | | FrugalGPT [1] | After the cheap model answers | Labelled answers, for a small scorer | The best single model's accuracy at 59.2% to 98.3% lower cost | | Hybrid LLM [13] | Before any call | Quality gaps on 10,000 training instructions | Up to 40% fewer calls to the large model, with no drop in quality | | AutoMix [14] | After the small model checks itself | Few-shot self-verification | Over 50% lower computational cost for comparable performance | | RouteLLM [2] | Before any call | 80,000 human preferences, plus GPT-4 judgements | A cost saving ratio of 3.66 at 95% of GPT-4's MT Bench score | All four were measured on English benchmarks with models of 2023 and 2024; none on Arabic or on operational data. ### Smaller models Distillation (Training a small model to reproduce a larger model's outputs, so that the small one can do the task alone.) trains a small model to reproduce a large one [16]. Gemma 2's 2B and 9B models were trained this way, and their authors describe them as competitive with models two to three times larger [17]. FrugalGPT applies the idea to a single task: fine-tune a small model on an expensive model's answers, which also allows shorter prompts and faster answers [1]. Read the vendor's terms first: Anthropic's prohibit using its services to train competing AI models without its approval [18]. Small general models are often English-first: the authors of Phi-3-mini, a 3.8-billion-parameter model that scored 69% on MMLU, mostly restricted its language to English [19]. Quantization (Storing a model's weights in fewer bits, for example 4 instead of 16, so that it needs less memory and runs faster, sometimes at a cost in quality.) cuts the cost of serving any model. LLM.int8() ran a 175-billion-parameter model in 8 bits without performance loss [20], and AWQ keeps 4-bit models accurate by protecting about 1% of salient weights [21]. For Arabic the caveat is direct. Quantization hurt non-Latin-script languages most, and automatic metrics understated the damage: a 1.7% automatic drop in Japanese matched a 16.0% drop reported by human evaluators [22]. Arabic was evaluated automatically but not by people, so any hidden loss there is unknown. ### Caching and serving Both vendors we priced offer prompt caching (The vendor keeps the start of a prompt that repeats across requests and bills those tokens at a reduced rate when they are read again.). Anthropic bills cache reads at 0.1 times the input price on most models and 0.05 times on Claude Opus 5.5 and Claude Sonnet 5.5 [6]; OpenAI discounts cached input by up to 95% when the whole rendered prefix matches [23]. An agent's instructions, catalogue and customer rules repeat on every call, so they go first and the incoming message last. GPTCache reuses whole answers to similar requests and reports responses 2 to 10 times faster on a hit [24]; that suits stable lookups, not answers that depend on today's stock or balance. For models run on one's own hardware, serving matters as much as size. vLLM's PagedAttention raised throughput 2 to 4 times at the same latency [25], and speculative decoding, in which a small model drafts tokens that the large one verifies, ran T5-XXL 2 to 3 times faster with identical outputs [26]. ## 3. What a step costs A step costs the tokens it reads times the input price, plus the tokens it writes times the output price. Routing changes the prices; caching and shorter prompts change the input tokens; tokenization, in section 4, changes both token counts at once. **Figure 1. List prices of two large and two small models** Each pair of bars is one model's price in US dollars for a million input tokens and a million output tokens; the small models barely register at this scale. | | Input | Output | | --- | --- | --- | | OpenAI gpt-6-astra | 10 | 50 | | Anthropic Claude Opus 5.5 | 4 | 20 | | OpenAI gpt-6-luna | 0.1 | 0.5 | | Anthropic Claude Haiku 5.5 | 0.1 | 0.5 | Source: OpenAI and Anthropic pricing pages, read 14 October 2026 [5, 6]. Standard tier, without caching, batch or regional adjustments; OpenAI prices are for prompts up to 272,000 tokens, Claude Haiku 5.5's for prompts up to 100,000. Within each vendor, the large model costs 40 to 100 times the small one per token, and for all four models output costs five times as much as input, so drafting a reply costs more per token than classifying a message. Prices across vendors are not like for like, because each model counts tokens its own way: Anthropic notes that the tokenizer it introduced with Claude Opus 4.7 produces about 30% more tokens for the same text than the one before [6]. At a 100-fold gap, routing a share of steps to the small model saves almost exactly that share: routing 70% saves 69.3%. A cascade also pays the small model on the steps it escalates, but at a 30% escalation rate and the gaps above, that adds under one percentage point to the bill, so the choice between a router and a cascade turns on latency and the quality of the check, not on price. As an illustrative example, 50,000 steps a month, each reading 3,000 tokens and writing 500, cost $2,750 on gpt-6-astra alone and $844.25 with 70% of them on gpt-6-luna; with Claude Opus 5.5 and Claude Haiku 5.5, the figures are $1,100 and $349.25. **Figure 2. What routing a share of steps to a small model saves** (interactive on the page) Choose the two models, the steps a month, the tokens each step reads and writes and the share the small model takes, and read the monthly bill at list prices read on 14 October 2026 [5, 6]. List prices in US dollars per million tokens, read 14 October 2026. | Model | Input | Output | Source | | --- | --- | --- | --- | | OpenAI gpt-6-astra | 10 | 50 | https://developers.openai.com/api/docs/pricing | | OpenAI gpt-6-luna | 0.1 | 0.5 | https://developers.openai.com/api/docs/pricing | | Anthropic Claude Opus 5.5 | 4 | 20 | https://platform.claude.com/docs/en/about-claude/pricing | | Anthropic Claude Haiku 5.5 | 0.1 | 0.5 | https://platform.claude.com/docs/en/about-claude/pricing | The calculator leaves out three adjustments. Anthropic bills batch requests at half price [6], which suits steps that can wait, such as a nightly reconciliation. Caching cuts the input term. Regional processing costs more: OpenAI adds 10% for data residency on models released from 5 March 2026, and Anthropic charges 1.1 times the standard rate for US-only inference [5, 6]. Prices also move on their own: Google lists Gemini 4 Argon at $2.00 per million input tokens through 30 November 2026 and $4.00 from 1 December 2026 [27]. A routing decision should carry the date of the prices it was made on. ## 4. The tokenizer tax on Arabic A token is not a fixed amount of text. A tokenizer (The component that cuts text into tokens. One trained mostly on English cuts Arabic words into more, smaller pieces.) learned mostly from English cuts Arabic into more pieces, so the same message costs more, takes longer and fills more of the model's context. Petrov and colleagues measured this on FLORES-200 (A benchmark of the same sentences, taken from Wikipedia, translated into about 200 languages, so that languages can be compared on identical content.) as a tokenization premium (The number of tokens a language needs for a text, divided by the number English needs for the same text. A premium of 3 means three times the tokens.) [3]. On cl100k_base, the tokenizer of ChatGPT and GPT-4, Standard Arabic had a premium of 3.04, and so did Najdi Arabic, spoken in central Saudi Arabia; on GPT-2 the premium was 4.40. The authors tie premiums directly to cost, since vendors bill per token, and to latency, since processing time in their measurements grew linearly with the number of tokens. **Figure 3. Tokens needed for Standard Arabic, relative to the same English text** Each bar is one tokenizer's premium: 1.00 would match English and 3.04 means three times as many tokens; the orange bar is the tokenizer of ChatGPT and GPT-4. | | × English | | --- | --- | | GPT-2 and RoBERTa (2019) | 4.4 | | LLaMA (2023) | 3.42 | | ChatGPT and GPT-4 (2023) | 3.04 | | Qwen-VL (2023) | 1.63 | | mT5 (2021) | 1.35 | | XLM-R (2020) | 1.18 | | BLOOM (2022) | 1.14 | | Arabic BERT (2020) | 0.55 | Source: Petrov et al. [3], Tables 1 and 4 and appendix C; FLORES-200, tokenizers published from 2019 to 2023; read 14 October 2026. The tokenizers of the models in Figure 1 were not studied. The multilingual tokenizers in the study's main comparison sit between 1.14 and 1.40, and one trained for Arabic reverses the premium: Arabic BERT needs fewer tokens for the Arabic text than for its English translation. It also stays near parity across 25 Arabic dialects, at 0.91 for Jeddah, 0.92 for Doha and Riyadh and 0.94 for Muscat relative to Standard Arabic [3]. Ahia and colleagues, studying OpenAI's API in 22 languages, found languages with their own scripts needing up to five times as many tokens as English, and their speakers overcharged while obtaining poorer results [11]. Their Arabic results are shown only in figures. ### Tokenizers built for Arabic Jais trained a byte-pair tokenizer of 84,992 entries on 10 billion words, half English and half Arabic; Table 2 gives its fertility (The average number of tokens a tokenizer produces per word. Close to 1 means that words are rarely split.) comparison [4]. ALLaM instead merged an Arabic vocabulary into the tokenizer of Llama-2 and reports that this lowers fertility in Arabic [28]. **Table 2. Fertility of four tokenizers on English, Arabic and code validation sets, as reported by the Jais authors [4].** | Tokenizer (vocabulary size) | English | Arabic | Code | | --- | --- | --- | --- | | GPT-2 (50,257) | 1.095 | 4.171 | 1.294 | | BERT Arabic (32,000) | 1.632 | 1.125 | 1.313 | | BLOOM (250,000) | 1.083 | 1.195 | 1.000 | | Jais (84,992) | 1.010 | 1.050 | 1.006 | Lower is better. These are the Jais authors' measurements on their own validation sets, not an independent comparison. For routing, the price of a step in Arabic is the vendor's price times a premium that depends on each model's tokenizer, and the premium can differ between the frontier model and the small one. As an illustrative calculation, a premium of 3.04 on reading and writing would turn the $2,750 month of section 3 into $8,360 for the same work. We found no published measurement on Arabic of the tokenizers behind the models in Figure 1, and tokenizers change between versions of a model [6]. The premium has to be measured on the customer's own messages and documents, in both languages, with each candidate model's own token count. ## 5. Matching steps to models Table 3 takes four steps that recur in Gulf distribution and logistics and sets out where we would start each one. It is our judgement from the evidence above, and every row is a hypothesis to test on the customer's past cases (section 7). **Table 3. Four common workflow steps and the model we would start each on. Our starting judgement; the inputs are illustrative.** | Step | Illustrative input | Start on | Why | Escalate when | | --- | --- | --- | --- | --- | | Classify a message | A WhatsApp message in Arabic and English: an order, a complaint or a promise to pay | A small model or a fine-tuned classifier | Fixed labels, a short input and a one-word output; a wrong label surfaces at the next step | Confidence is low, or no label fits | | Extract an order | A message or a photographed delivery note with items, quantities, a branch and a date | A small model with a fixed output schema | Code can check the output against the schema, the catalogue and the customer's usual quantities | Any of those checks fails | | Draft a reply in Gulf Arabic | A reply to a hotel group's buyer about a late delivery | A frontier model, or the strongest Arabic model the data may reach | Free text in dialect, read by a customer; the hardest output to check automatically | A person reviews it wherever the customer's thresholds say so | | Reconcile an invoice | The invoice, purchase order and signed delivery note for one order | Code for the arithmetic, a small model to match lines, a frontier model for exceptions | Totals belong in code; matching lines is extraction; explaining a short delivery needs judgement | Lines do not match; above the customer's threshold, a person decides | Mixed-language messages and Arabizi belong in the small model's test set, not in automatic escalation. Three principles sit behind the table. Give a step a contract where one exists: an extraction that code can check can start on a small model, and Anthropic itself describes its smallest current model as meant for tasks such as classification, extraction and routing [29]. Keep arithmetic in code, which does it exactly. And spend the frontier model on free text that a customer reads, especially in dialect. AraDiCE found Arabic-centric models such as Jais and AceGPT ahead of multilingual ones on dialect tasks, with significant challenges remaining in dialect identification, generation and translation [12]. Models did better on Gulf Arabic than on Levantine or Egyptian, which the authors attribute to its closeness to Standard Arabic; but they had to replace free generation with a multiple-choice task, because models often explained the prompt instead of replying in the dialect. Free text in dialect is where automatic evaluation is weakest, so people judge it. ## 6. A router for operations Figure 3 shows our design for one step. A router decides before the call where the step's type makes the decision easy, and a cascade's check catches what the router lets through. **Figure 4. A router for one workflow step** From the left: routine steps go to the small model and are checked; steps that fail the check, or that the router knows are hard, go to the frontier model; every outcome is recorded and joins the past cases. - Step arrives: Message, order, invoice - Router: Rules, then a classifier - Small model: Named for the workflow - Check: Schema, rules, confidence - Frontier model: Hard or free-text steps - Record: Model, tokens, cost, result - Past cases: Re-run before a change - Step arrives → Router - Router → Small model - Router → Frontier model (hard) - Small model → Check - Check → Frontier model (fails) - Check → Record (passes) - Frontier model → Record - Record → Past cases Qantara's design, drawn for this paper, not a measured system: a router before the call [13] joined to a cascade's check after it [1]. Rules come first, because many steps announce their difficulty. An order from a known customer, in a known pattern, with items in the catalogue, is routine; a dispute, a legal notice or an amount above the customer's threshold is not. A learned classifier takes only what the rules leave undecided, and as section 2 showed, its cost is small next to generation. The check should be as deterministic as the step allows: the schema, the catalogue and the customer's usual quantities for an extraction; the classifier's confidence and a list of labels that always escalate for a classification; a model only for free text, as in AutoMix's self-verification or FrugalGPT's scorer [14, 1]. A deterministic check also leaves a reason in the log when it fails. Latency decides between routing first and checking after, because a cascade that escalates calls two models in sequence [2]. For a customer waiting on WhatsApp, known-hard steps should go straight to the frontier model; a nightly reconciliation can wait, and can go in a batch. ```json { "step": "extract_order", "routed_to": "small", "reason": "known customer, known order pattern", "model": "gpt-6-luna", "tokens_in": 2140, "tokens_out": 310, "check": "passed: schema, catalogue, quantity range", "escalated": false, "cost_usd": 0.00037 } ``` An illustrative log line for one routed step, costed at the list price read on 14 October 2026. The step and its numbers are made up for the example. Logging each routing decision makes routing auditable. Every escalation is a case the small model could not do, and every pass that a person later corrects is a case the check missed. Both become past cases for the next test. ## 7. Testing a routing change on past cases Every figure in section 2 was measured on someone else's data, in English. RouteLLM's routers saved most on MT Bench, the benchmark closest to their training data, and far less on MMLU and GSM8K [2]; FrugalGPT's savings ranged from 59.2% to 98.3% [1]; Hybrid LLM's loss of quality grew with the gap between its models [13]. The only reliable estimate of what routing will save on a step, and at what cost in quality, comes from that step's own past cases. **Figure 5. The same router saves more on some tasks than on others** Each bar is how many times fewer GPT-4 calls the best router needed than a random one to recover half the quality gap between Mixtral 8x7B and GPT-4; the brackets give the quality reached as a share of GPT-4's score. | | times fewer GPT-4 calls | | --- | --- | | MT Bench (95% of GPT-4's score) | 3.66 | | GSM8K (87% of GPT-4's score) | 1.49 | | MMLU (92% of GPT-4's score) | 1.41 | Source: Ong et al. [2], Table 6; English benchmarks; read 14 October 2026. The MMLU result carries the practical lesson. Routers trained only on Chatbot Arena conversations did no better than random on MMLU; adding about 1,500 labelled MMLU examples, under 2% of the training data, brought every router to roughly 20% fewer GPT-4 calls than random at the same quality [2]. Our reading is that a modest number of a company's own labelled cases may matter more to a router than any amount of public data. ### The procedure 1. Write the step's contract with the team that does the work today: the fields of an extraction, the labels of a classification, what a good reply says. 2. Collect past cases as they arrived, including mixed Arabic and English, Arabizi and photographed documents. The team marks the correct output for each. 3. Run both models on every case with the same prompt and the same check, recording tokens, cost and latency, with tokens counted by each model's own tokenizer. 4. Score with the step's own measure: field match, label accuracy, or people's ratings for Arabic free text. GPT-4 judges agreed with people over 80% of the time on English chat [15], but we found no such evidence for Gulf Arabic, and automatic scores can miss losses that people see [22]. 5. Set the routing rule at the threshold where the routed step meets the quality bar the team chose, and read off the share routed, the escalation rate and the saving. 6. Run it in shadow mode beside the live step before it acts, and send every difference to the team. 7. Run it again when anything changes: a model version, a tokenizer, a price or a new kind of message. ## 8. When the data cannot leave Where a customer, or a rule in its sector, keeps data in the country, a model that runs abroad is not eligible for the steps that read that data, whatever it costs. On 14 October 2026, Anthropic's API offered inference in two geographies, global and the United States, and kept data at rest only in the United States [8]. OpenAI listed ten data residency regions; the UAE was one of three with inference in the region, limited to named models such as gpt-5.6-luna and subject to additional approval [7]. Neither page mentioned Oman, Saudi Arabia, Qatar, Bahrain or Kuwait. Models offered through the large clouds' marketplaces follow each cloud's own regional rules, which we did not review. That leaves open-weight models run on hardware in the country, and there are now small ones built for Arabic. The Jais family spans 590 million to 70 billion parameters under the Apache 2.0 licence [9]. ALLaM-7B-Instruct-preview comes from the National Center for Artificial Intelligence at the Saudi Data and AI Authority [30]. Fanar Prime, a 9-billion-parameter model from the Qatar Computing Research Institute at Hamad Bin Khalifa University, was continually trained from Gemma-2 9B [10], itself a distilled model [17]. Where a workflow must keep personal data in the country, routing and residency meet. Steps that read personal data, such as a customer's name and phone number, can go to a model run in the country; steps without it may go abroad under paper agreed with the customer. That model then carries the routine volume for reasons of cost and the sensitive volume for reasons of law, and the test in section 7 has to show it is good enough for both. Self-hosting is billed in hardware and operations rather than tokens, and serving software and quantization decide how much it can carry [25, 21]. ## 9. Implications for deployment The evidence points to six rules. - Start on the strongest model, then earn the move down, step by step, on past cases. - Decide per step. Classification and extraction are the usual first candidates for a small model; free text in dialect is the last. - Count tokens in Arabic, on the customer's own documents, before comparing prices. - Let residency choose before price does. Decide which models may read which data, then route among those. - Cache the stable part of every prompt and batch what can wait [6, 23]. - Date every price. A routing decision is only as current as its price list. This is how we approach it at Qantara. Our engineers work on site inside the customer's operation, write down how each workflow really runs and record a baseline. Each agent is run on the customer's past cases before it goes live, with their team marking what good looks like, and we treat a routing change as a new version of the agent that must pass the same cases. For each workflow we state in writing which model reads what and where it runs. The record and its log are kept in the customer's country, every read and write is a line in the log, including which model did each step, and above the customer's thresholds a person approves, whichever model did the work. ## 10. Limitations The paper is limited in seven ways. - Every routing result we cite was measured in English with models of 2023 and 2024; none on Arabic, mixed-language messages or operational data. - The Arabic premiums are for tokenizers published up to 2023. The tokenizers of the models priced here are unmeasured in the literature we found, and their premiums may be lower or higher. - Prices are one day's list prices for two vendors' first-party APIs at the standard tier. Negotiated, marketplace and regional prices differ, and some are already scheduled to change [27]. - Self-hosting costs are not modelled, and the calculator does not apply to them. - Table 3 and Figure 3 are design judgements to be tested, not findings. - The residency review covers two vendors' documentation on one date, and it is not legal advice. - The evidence that automatic metrics miss quantization losses comes from languages other than Arabic [22]. A router that transfers to Arabic operational data without labelled cases from it, or frontier prices that fall to the level of today's small models, would weaken the case for routing step by step. ## 11. Conclusion The published evidence agrees on the direction: most requests do not need the largest model, and routers and cascades keep most of the quality for much less. It disagrees on the size of the saving, which depends on the task, on the gap between the models and on how closely the router's training data matches its traffic. In the Gulf, two more terms enter the arithmetic: Arabic text costs several times as many tokens on English-centric tokenizers, and some data cannot leave the country at all. The answer is to decide per step, on the customer's own past cases, with tokens counted in Arabic and English, among the models the data may reach, and to log every decision. Done that way, right-sizing is a routine rather than a one-off saving: every new model, price or tokenizer is another run of the same cases. ## References [1] Chen, L., Zaharia, M. and Zou, J. (2023). FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv:2305.05176. https://arxiv.org/abs/2305.05176 [2] Ong, I., Almahairi, A., Wu, V., et al. (2024). RouteLLM: Learning to Route LLMs with Preference Data. Proceedings of ICLR 2025, arXiv:2406.18665. https://arxiv.org/abs/2406.18665 [3] Petrov, A., La Malfa, E., Torr, P. H. S., et al. (2023). Language Model Tokenizers Introduce Unfairness Between Languages. Advances in Neural Information Processing Systems 36 (NeurIPS 2023). https://arxiv.org/abs/2305.15425 [4] Sengupta, N., Sahu, S. K., Jia, B., et al. (2023). Jais and Jais-chat: Arabic-Centric Foundation and Instruction-Tuned Open Generative Large Language Models. arXiv:2308.16149. https://arxiv.org/abs/2308.16149 [5] OpenAI (2026). Pricing. OpenAI API documentation. https://developers.openai.com/api/docs/pricing (accessed 14 October 2026) [6] Anthropic (2026). Pricing. Claude API documentation. https://platform.claude.com/docs/en/about-claude/pricing (accessed 14 October 2026) [7] OpenAI (2026). Data controls in the OpenAI platform. OpenAI API documentation. https://developers.openai.com/api/docs/guides/your-data (accessed 14 October 2026) [8] Anthropic (2026). Data residency. Claude API documentation. https://platform.claude.com/docs/en/manage-claude/data-residency (accessed 14 October 2026) [9] Inception (2024). Jais Family Model Card. Hugging Face. https://huggingface.co/inceptionai/jais-family-590m (accessed 14 October 2026) [10] Fanar Team (2025). Fanar: An Arabic-Centric Multimodal Generative AI Platform. arXiv:2501.13944. https://arxiv.org/abs/2501.13944 [11] Ahia, O., Kumar, S., Gonen, H., et al. (2023). Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models. Proceedings of EMNLP 2023. https://aclanthology.org/2023.emnlp-main.614 [12] Mousi, B., Durrani, N., Ahmad, F., et al. (2025). AraDiCE: Benchmarks for Dialectal and Cultural Capabilities in LLMs. Proceedings of COLING 2025. https://aclanthology.org/2025.coling-main.283/ [13] Ding, D., Mallick, A., Wang, C., et al. (2024). Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing. Proceedings of ICLR 2024, arXiv:2404.14618. https://arxiv.org/abs/2404.14618 [14] Aggarwal, P., Madaan, A., Anand, A., et al. (2024). AutoMix: Automatically Mixing Language Models. Advances in Neural Information Processing Systems 37 (NeurIPS 2024), arXiv:2310.12963. https://arxiv.org/abs/2310.12963 [15] Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks Track, arXiv:2306.05685. https://arxiv.org/abs/2306.05685 [16] Hinton, G., Vinyals, O. and Dean, J. (2015). Distilling the Knowledge in a Neural Network. NIPS 2014 Deep Learning Workshop, arXiv:1503.02531. https://arxiv.org/abs/1503.02531 [17] Gemma Team (2024). Gemma 2: Improving Open Language Models at a Practical Size. arXiv:2408.00118. https://arxiv.org/abs/2408.00118 [18] Anthropic (2025). Commercial Terms of Service. Anthropic legal, section D.4, effective 17 June 2025. https://www.anthropic.com/legal/commercial-terms (accessed 14 October 2026) [19] Abdin, M., Aneja, J., Awadalla, H., et al. (2024). Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone. arXiv:2404.14219. https://arxiv.org/abs/2404.14219 [20] Dettmers, T., Lewis, M., Belkada, Y., et al. (2022). LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale. Advances in Neural Information Processing Systems 35 (NeurIPS 2022), arXiv:2208.07339. https://arxiv.org/abs/2208.07339 [21] Lin, J., Tang, J., Tang, H., et al. (2024). AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. Proceedings of MLSys 2024, arXiv:2306.00978. https://arxiv.org/abs/2306.00978 [22] Marchisio, K., Dash, S., Chen, H., et al. (2024). How Does Quantization Affect Multilingual LLMs?. Findings of EMNLP 2024, arXiv:2407.03211. https://arxiv.org/abs/2407.03211 [23] OpenAI (2026). Prompt caching. OpenAI API documentation. https://developers.openai.com/api/docs/guides/prompt-caching (accessed 14 October 2026) [24] Bang, F. (2023). GPTCache: An Open-Source Semantic Cache for LLM Applications Enabling Faster Answers and Cost Savings. Proceedings of the 3rd Workshop for Natural Language Processing Open Source Software (NLP-OSS 2023). https://aclanthology.org/2023.nlposs-1.24/ [25] Kwon, W., Li, Z., Zhuang, S., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. Proceedings of SOSP 2023, arXiv:2309.06180. https://arxiv.org/abs/2309.06180 [26] Leviathan, Y., Kalman, M. and Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. Proceedings of ICML 2023, arXiv:2211.17192. https://arxiv.org/abs/2211.17192 [27] Google (2026). Gemini Developer API pricing. Gemini API documentation. https://ai.google.dev/gemini-api/docs/pricing (accessed 14 October 2026) [28] Bari, M. S., Alnumay, Y., Alzahrani, N. A., et al. (2025). ALLaM: Large Language Models for Arabic and English. Proceedings of ICLR 2025, arXiv:2407.15390. https://arxiv.org/abs/2407.15390 [29] Anthropic (2026). Models overview. Claude API documentation. https://platform.claude.com/docs/en/models/overview (accessed 14 October 2026) [30] National Center for Artificial Intelligence, Saudi Data and AI Authority (2025). ALLaM-7B-Instruct-preview. Hugging Face model card. https://huggingface.co/ALLaM-AI/ALLaM-7B-Instruct-preview (accessed 14 October 2026) ## Cite this paper ```bibtex @techreport{qantara2026rightsizingmodels, title = {Right-sizing models: routing between small and frontier models}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/right-sizing-models} } ``` ## Disclosure Cited: the routing, distillation, quantization, caching and tokenization results, and the list prices and residency options, which we read on the vendors' own pages on 14 October 2026. Ours: the cost arithmetic in sections 3 and 4, the calculator, Table 3, the router in Figure 3 and the testing procedure in section 7, which describe our approach and are not measured results. Illustrative: the inputs in Table 3, the worked monthly bills and the log line in section 6. Canonical: https://qantara.systems/insights/right-sizing-models --- # The operating record: a data model for how a company runs Technical report. Qantara Research, Qantara. 14 October 2026. 19 min read. > One line per event, written by agents and people, kept beside the ERP, and traceable to the message, call, document or person it came from. ## Abstract Agents that work inside a company's operations need a record of how it actually runs, and the systems most companies have do not keep one. ERP tables are reliable but incomplete, data warehouses inherit their gaps, and many decisions that move goods in the Gulf are taken on a call and corrected on WhatsApp. This technical report asks what data model should sit under every agent. We review event sourcing, process mining and its object-centric event log standard, W3C provenance, knowledge graphs and bitemporal databases, and compare five models on five properties: capturing decisions made off-system, keeping provenance, separating valid time from record time, being readable by agents, and being exportable. We then specify the operating record: an append-only log of one line per event, written by agents and people, kept beside the ERP, with eleven fields in Arabic and English and two times per line. No prior model we reviewed has all five properties; OCEL 2.0 comes closest and is our export target. This is a design report and reports no deployment results. ## Key findings 1. The process mining manifesto rates ERP tables as trustworthy but not necessarily complete, and events recorded by hand, where off-system decisions live, as the lowest of its five quality levels. 2. Of the five data models we compare, only the operating record is designed to have all five properties an agent needs; this is a property of the design, not a measured result. 3. OCEL 2.0 is the closest open model, but it gives each event one timestamp and has no field for who wrote a line or who approved it. 4. Provenance and time belong inside the line: a knowledge graph needs reification, named graphs or edge attributes to express them, so the record stays a flat log. 5. Compounding is a property of the data model: a second agent starts from the lines the first wrote. ## 1. Introduction On a Sunday morning a caterer's buyer in Sohar confirms the weekly order on WhatsApp: ghee, and fifty cartons of oil. On Monday the sales manager of the distributor's Dammam branch agrees a discount with a contractor by phone. On Tuesday the buyer writes again: the oil should have been forty cartons. In many companies none of these decisions reaches the ERP as it was taken. The discount surfaces weeks later as a lower price with no reason attached; the correction is typed over the original quantity, and what the warehouse was told on Monday is gone. These events are an illustrative example, written by us, and recur through this report. This matters more once software acts. An agent that confirms orders or chases payments reads some record of the company before it acts and writes something after. If it reads only the ERP, it acts on the part of the operation that was keyed in. If what it writes cannot be traced to the message it acted on and the person who approved it, nobody can check it. What sits under the agents decides what they can know and what can be audited. The Gulf sharpens the problem. Operations often run partly outside their software: a delivery note is signed on a tailgate and photographed into a WhatsApp group, terms are agreed on a call in Arabic, and a spreadsheet beside the ERP holds what the ERP has no field for. An order may arrive in Arabic and be invoiced in English, and a distributor with branches in Oman and Saudi Arabia works in two currencies and two time zones. A data model for agents here must hold both scripts, every channel and the reason behind each event, and say where each line came from. This report makes four contributions: 1. A comparison of five data models against five properties that a record read and written by agents needs (section 3). 2. A specification of the record line: eleven fields, two times and two scripts, with an illustrative example (section 4). 3. A mapping of each field to OCEL 2.0 and W3C PROV, for reading with open tools and for export (sections 4, 6 and 9). 4. An account of how a second agent starts from what the first wrote, which is what we mean by compounding (section 8). ## 2. Background and related work ### What the ERP and the warehouse keep The manifesto of the IEEE Task Force on Process Mining, published in 2012, grades event logs on five levels [1]. Tables in ERP systems sit at three stars of five: recorded automatically and trustworthy, in that a payment the ERP records actually exists, but not necessarily complete. One level down, people can bypass the system, so events may be missing. At the lowest level, events are recorded by hand and may neither match reality nor be complete; the manifesto's examples are trails left in paper documents. A decision taken on a call or corrected on WhatsApp sits below even that: unless someone writes it down, it is not recorded at all. The data warehouse cannot repair this, because it is built from the same systems. In Kimball's dimensional method the grain (What one row of a fact table stands for: one scan at a till, one invoice line, one shipment. Kimball's method fixes it before anything else in the design.) of a transaction fact table is a measurement event at a point in space and time [2], and those events are the ones the source systems captured. The warehouse can also lose what the source kept: a type 1 change overwrites the old value, which, the method's documentation notes, destroys history [3]. Both designs keep accounts and report on them well. Neither was built to keep the reasons, channels and people behind each event. Information systems research has studied the gap between the process as designed and the process as run. Alter's theory of workarounds, which covers most situations in which workarounds occur in operational systems, describes how and why they are created and helps explain compliance and noncompliance with management mandates [4]. A record of the designed process misses the adaptations an agent most needs to know. ### Event sourcing and the append-only log Event sourcing (A way of building software in which every change is stored as an event, in order, and the current state is computed from the events rather than overwritten in place.), as Fowler described it in 2005, captures every change to an application's state as a sequence of events, so the state at any past moment can be rebuilt by replaying them [5]. Helland takes the idea down to the database, where transaction logs record every change and tables hold only the latest values; his analogy is the ledger, corrected by adding entries, never by erasing [6]. > The truth is the log. The database is a cache of a subset of the log. > > Pat Helland, Immutability Changes Everything, CIDR 2015 [6] The operating record applies the same stance to the business rather than the software. ### Process mining and the object-centric event log Process mining discovers, monitors and improves real processes, not assumed ones, from event logs [1]. Its classic input gives each event a case identifier, an activity and a timestamp; its exchange format, XES, has been an IEEE standard since 2016, revised in 2023 [7]. One case is often not enough: an order may ship in several deliveries, and one delivery may carry lines of several orders [1]. Van der Aalst named the failures that follow from forcing such data into single cases: one event related to several cases (convergence) and repeated activities within one case (divergence) [8]. The answer was the object-centric event log. OCEL 1.0, introduced in 2020, related each event to objects of several types. OCEL 2.0 (Object-centric event log, version 2.0: an open format from the process-mining community in which each event can relate to many objects, such as an order, its items and a delivery, rather than to a single case.), specified in 2024, added qualified relations between objects, qualifiers naming the role an object plays in an event, and object attributes that change over time, in three exchange formats: SQLite, XML and JSON [9]. Its site also lists CSV and a bundled CSV and Parquet format, as read on 14 October 2026 [10]. Of the open models we reviewed, OCEL 2.0 is the closest to what an operating record needs. ### Provenance The W3C PROV family, published on 30 April 2013, defines provenance (The record of where a piece of data came from: who or what produced it, from what, and how, so that someone else can judge whether to trust it.) as information about the entities, activities and people involved in producing a piece of data or thing, used to judge its quality, reliability or trustworthiness [11]. Its data model, PROV-DM, has three types: an entity is a thing with some fixed aspects, an activity occurs over time and acts upon or with entities, and an agent bears some responsibility for an activity [12]. An entity is attributed to an agent, an activity is associated with an agent in a role, and one entity is derived from, or is a revision of, another. PROV-O encodes the model for the semantic web [11]. The record borrows PROV's first distinction: the agent who did a thing and the agent a line is attributed to are not always the same. ### Knowledge graphs Hogan and colleagues' survey sets out how knowledge graphs represent data, schema, identity and context [13]. Context is the part that matters here. Many facts hold only from a date, in a place or according to a source. To attach a date or a source to one edge, a graph must turn the relation into a node, or use reification (Making a statement about a statement: turning one edge of a graph into a node of its own, so that a date, a source or an approver can be attached to it.), named graphs, property-graph edge attributes or RDF-star; and a reified edge does not assert the edge it reifies. Graphs are also commonly read under an open-world assumption (The rule that a fact missing from the data is unknown rather than false. Its opposite, the closed-world assumption, treats what is not recorded as not true.). Both suit joining knowledge across many sources. Both are costs for a record whose questions are closed: was this order delivered in full, and who approved the discount? ### Two times Snodgrass and Ahn named the two times in 1985: valid time, when a fact holds in reality, and transaction time, when it was stored; a database that keeps both shows what was believed at one moment about another, retroactive changes included [14]. SQL:2011 standardised both, as application-time period tables and system-versioned tables, which one table may combine [15]. Fowler calls them actual history and record history, and works through a pay rise recorded late and then corrected [16]. We say valid time and record time. ### Memory for agents Agent research reached a similar structure from another side. Park and colleagues' generative agents store a complete record of each agent's experiences in natural language and retrieve from it to plan [17]. A longer prompt is no substitute: language models use information at the start or end of a long input better than in the middle [18]. An agent should read the slice of the record its task needs. **Figure 1. Every part of the record is older than the agents that write to it** Read top to bottom: each item is a published model or standard that the operating record draws on, with the month or year it appeared. - May 1985: Valid time and transaction time named. Snodgrass and Ahn, SIGMOD 1985: keep both, and see what was known when. - Dec 2005: Event sourcing described. Fowler: every change to state captured as a sequence of events. - Dec 2011: Temporal tables in SQL:2011. Application-time and system-versioned tables enter the SQL standard. - 2012: Process mining manifesto. ERP tables at three stars of five; events recorded by hand at one. - Apr 2013: W3C PROV published. Entities, activities and agents, and how each was derived and attributed. - Jan 2015: Immutability changes everything. Helland, CIDR 2015: correct by appending, never by erasing. - 2016: XES becomes IEEE 1849. The exchange format for single-case event logs; revised in 2023. - 2019: Object-centric process mining. Van der Aalst: one case notion causes convergence and divergence. - 2021: Knowledge graphs surveyed. Hogan and colleagues, ACM Computing Surveys: context on an edge needs reification, named graphs or edge attributes. - Mar 2024: OCEL 2.0 specified. Qualified object relations and changing object attributes, in SQLite, XML and JSON. Sources: Snodgrass and Ahn [14]; Fowler [5]; Kulkarni and Michels [15]; the process mining manifesto [1]; W3C PROV [12]; Helland [6]; IEEE 1849 [7]; van der Aalst [8]; Hogan and colleagues [13]; Berti and colleagues [9]. Compiled by Qantara, 14 October 2026. ## 3. What an agent needs from a record We take five properties from the gaps above. Each is a question that an owner, an auditor or the next agent will ask of a line. - Captures decisions made off-system. There is a place for an event that reached no system, such as a call, a WhatsApp message or a signed note, with the channel it came on. - Keeps provenance. Every line names its source document, who did the thing, who wrote the line and who approved it. - Separates valid time from record time. A correction is a new line, and the record answers both what happened and what was known at a given moment. - Readable by agents. An agent can pull the lines for one order, customer or week, in a form a language model reads without first learning a schema. - Exportable. The whole record can leave in open formats that other tools already read. **Figure 2. Five data models against five properties** Each row is a data model and each column a property; a filled mark means the model has a place for the property by design, a half mark that it can be made to hold it with extra work, an empty mark that it does not. | | Captures off-system decisions | Keeps provenance | Valid and record time | Readable by agents | Exportable | | --- | --- | --- | --- | --- | --- | | ERP | no | partial | partial | partial | partial | | Data warehouse | no | partial | partial | yes | yes | | Knowledge graph | partial | partial | partial | partial | yes | | Event log (OCEL 2.0) | no | partial | no | yes | yes | | Operating record | yes | yes | yes | yes | Design goal | Qantara's assessment, 14 October 2026, from the sources discussed in section 2: the process mining manifesto [1], Kimball [2, 3], Hogan and colleagues [13] and the OCEL 2.0 specification [9]. The operating record's row describes its design, not a measured deployment; its export is a design goal. The ERP records what was keyed in, and the manifesto places hand-recorded events, where off-system decisions live, at its lowest level [1]. An ERP typically records which user entered a transaction, not the message it came from; its documents carry business dates and many systems keep change logs, but master data is commonly updated in place; and its tables, which the manifesto counts in the thousands for an ERP such as SAP, are hard for an agent to read without a guide. The warehouse is readable and exports easily, but its rows are the events the source systems captured [2], and whether it keeps history depends on the modeller's choice of change type [3]. The knowledge graph can represent provenance and time, but only through the context mechanisms above [13]. The OCEL 2.0 log is flat, readable and exportable, and its attributes can name who performed an event; but each event has one timestamp, nothing records when or by whom the event was logged, and the log is filled by extraction from information systems, not from calls and messages [9]. ## 4. The record line ### One line per event The unit of the operating record is the line: one event in the operation, such as an order confirmed, a delivery moved, a discount given or a carton found short. Following OCEL 2.0 [9], a line links to the objects the event concerns, each link carrying a qualifier (In OCEL 2.0, a short label on a link between an event and an object that says what role the object played, such as the customer, the approver or the source.): the order, its products, the delivery, the customer. Objects carry attributes that change over time and relate to one another, as an invoice to a delivery and a delivery to an order. Lines are appended, never edited, and an order's current state is what its lines add up to. Two kinds of line share one shape. Operational lines say what happened in the business; log lines say what an agent did: what it read, proposed and wrote, and what it asked a person. So "what did the collections agent read before that reminder?" is answered by the same kind of query as "what happened to this order?". The record sits beside the ERP, which remains where the accounts are kept. When an agent writes to the ERP it also writes a line to the record, with the ERP's document number as its source, and an event that reaches the ERP by another route can be written from the ERP entry. The record adds what the ERP does not hold: the channel, the reason, the writer, the approval and the events that never reached the ERP. **What the record is not** It is not a new ERP: nobody keys accounts into it. It is not a dashboard, though a dashboard could be drawn from it. It is not a graph of everything the company knows, but a log of what happened, one line per event. ### The fields A line has eleven content fields, the questions an owner asks of any event, and two that keep time and corrections. The table defines each, with its nearest place in OCEL 2.0 and W3C PROV, which governs export. **Table 1. The fields of a record line, with their nearest equivalents in OCEL 2.0 [9] and PROV-DM [12]. The first eleven are the line's content; the last two keep time and corrections. The mappings are ours.** | Field | What it holds | In OCEL 2.0 | In W3C PROV | | --- | --- | --- | --- | | Who | The person, agent or party who did what the line records, which may differ from who wrote it | An object linked with a qualifier such as actor | An agent associated with the activity | | What | The type of event, from a short list agreed for each workflow, with a one-line description in both scripts | The event type | The activity | | Where | The site: branch, warehouse, port or customer's premises | An event attribute, or an object of type site | The prov:location attribute | | When | Valid time: when it happened in the operation, with the place's offset from UTC | The event timestamp | The activity's start or end time | | For whom | The party the event serves: customer, supplier or branch | An object linked with a qualifier such as customer | An agent associated with the activity, with a prov:role | | Channel | How it reached the record: WhatsApp, email, call note, ERP entry, photo or paper | An event attribute | An attribute of the source entity | | Document | A pointer to the original, kept as it came: a message identifier, a file, an ERP document number, a call note | An object of type document, linked with a qualifier such as source | The entity the line was derived from | | Cost | Amount and currency, where the event has one | An event attribute | Not modelled; an attribute | | Why | The reason given, in the words of the person or message that gave it | An event attribute | Not modelled; an attribute | | Written by | The agent or person who wrote the line, under credentials of their own | Not modelled; an event attribute | Attribution of the line to an agent | | Approved by | The person who approved it above a threshold and the rule that applied, or the rule under which no approval was needed | Not modelled; a separate event | A separate approval activity that informed this one | | Recorded at | Record time: when the line was written | Not modelled | The line's generation time | | Supersedes | The line this one corrects, if any | Not modelled | A revision of the earlier line | Each line also has an identifier and a list of the objects it links to. Who, for whom and where point to objects (people, parties, sites) rather than holding free text. ### Two scripts on one line Every value a person reads is kept in Arabic and in English under the same field names, so the agent that writes a line and the person who checks it see the same thing. The source's value is kept as written, and the other script is marked as a rendering. Names of people, places and products link to their objects rather than being re-spelt in each line, so a customer whose name is written three ways in Latin script stays one customer. Mixed-direction text is stored in logical order and displayed by the Unicode Bidirectional Algorithm [19]. Times carry the local offset from UTC, as RFC 3339 allows [20], so lines from Sohar and Dammam sort correctly. Amounts carry their currency, and a Hijri date on a document is kept as written beside its Gregorian equivalent. ### An illustrative line Below is an illustrative example of one operational line, written by us: Sunday's order as an orders agent would write it from the buyer's WhatsApp message. The document reference follows the shape of the identifier the WhatsApp Cloud API gives each incoming message, which arrives with its own timestamp [21]. JSON exchanged between systems must be UTF-8 [22], so the Arabic travels intact. ```json { "id": "line-000318", "what": { "type": "order.confirmed", "en": "Order confirmed: ghee and oil", "ar": "تأكيد الطلب: سمن وزيت" }, "who": { "type": "person", "id": "person-0291", "role": "buyer", "of": "customer-0412" }, "where": { "type": "site", "id": "site-sohar", "en": "Sohar branch", "ar": "فرع صحار" }, "when": "2026-10-11T08:40:00+04:00", "for_whom": { "type": "customer", "id": "customer-0412", "en": "A caterer", "ar": "شركة تموين" }, "objects": [ { "type": "order", "id": "order-55120", "qualifier": "confirmed" }, { "type": "product", "id": "ghee-tin", "qualifier": "ordered", "quantity": 20 }, { "type": "product", "id": "oil-carton", "qualifier": "ordered", "quantity": 50 } ], "channel": "whatsapp", "document": { "type": "whatsapp_message", "ref": "wamid.illustrative-0001", "language": "ar" }, "cost": { "amount": 412.5, "currency": "OMR" }, "why": { "en": "Their weekly order", "ar": "طلبهم الأسبوعي" }, "written_by": { "type": "agent", "id": "orders-agent", "deployment": "deployment-01" }, "approved_by": { "status": "not_needed", "rule": "Order within the customer's credit limit" }, "recorded_at": "2026-10-11T08:41:12+04:00", "supersedes": null } ``` An illustrative record line, written by us. Identifiers, quantities and the amount are invented; the Arabic values are renderings for the example. **Figure 3. What a record line joins** Follow the arrows into the line from the left, and out of it to the right: a channel delivers a document, an actor does the thing, a person may approve it, and the line links the objects it concerns and is read by the next agent. - Channel: WhatsApp, email, call, ERP - Document: The original, as it came - Actor: Who did it; who wrote it - Threshold: Set by the customer - Approval: A person decides above it - Record line: One event, appended - Objects: Order, delivery, invoice - The next agent: Reads before it acts - Channel → Document - Document → Record line (source) - Actor → Record line - Threshold → Approval - Approval → Record line (approves) - Record line → Objects (links) - Record line → The next agent (read by) Qantara's design of the operating record, 14 October 2026. The entities follow OCEL 2.0 for events and objects [9] and PROV-DM for actors, documents and attribution [12]. ## 5. Valid time and record time Every line carries two times, which makes the record bitemporal (Keeping two times for every fact: when it was true in the world, and when the record learned it. Corrections then add to the history instead of overwriting it.). When is valid time, the moment the event happened in the operation; recorded at is record time, the moment the line was written. In operations they often differ: a call note is written hours after the call, a photograph of a signed delivery note reaches the WhatsApp group the next morning, and a correction about Sunday's order arrives on Tuesday. Corrections never edit a line. A correction is a new line with the same valid time as the line it corrects, a later record time and a pointer to the line it supersedes. The table follows the introduction's week. **Table 2. Three lines from the introduction's week, an illustrative example. Line 327 corrects line 318: the same valid time, a later record time. Times are local to each branch.** | Line | What | When (valid time) | Recorded at | Written by | Supersedes | | --- | --- | --- | --- | --- | --- | | 318 | Order confirmed: ghee, and 50 cartons of oil | Sun 08:40, Sohar | Sun 08:41 | Orders agent, from the buyer's WhatsApp message | None | | 322 | Discount given: repeat buyer | Mon 14:10, Dammam | Mon 16:30 | Sales manager, from their note of the call; approved by the sales manager, above the agent's limit | None | | 327 | Order corrected: 40 cartons of oil, not 50 | Sun 08:40, Sohar | Tue 09:05 | Orders agent, from the buyer's WhatsApp message | 318 | Two questions now have two honest answers. Asked on Monday evening, what had the caterer ordered? Fifty cartons: that is what the warehouse was told, and if a van was loaded with fifty on Monday, the record shows why. Asked today, what did the caterer order on Sunday? Forty. A system that overwrites the quantity gives only the second answer. The bitemporal record gives both, which is what an auditor, a dispute over a short delivery or the next agent needs [14, 16]. Whether Tuesday's message corrects Sunday's order or amends it is a business question. A correction changes what was true on Sunday; an amendment is a new event on Tuesday. The engineers settle the rule for each workflow with the team that runs it, and the line's type carries the distinction, so no agent has to guess. ## 6. Provenance and approval Four fields carry the trace, channel, document, written by and approved by: where a line came from, what it was read from, who put it in the record and who allowed it. Who and written by are kept apart because they often differ: the buyer confirmed the order and the orders agent wrote the line; the sales manager gave the discount and wrote the line from their own note. In W3C PROV terms, the event is an activity associated with the buyer, the line is an entity attributed to the agent that wrote it, and the message is the entity it was derived from [12]. Approval is a line of its own. Above a threshold the customer has set, the agent prepares the case and a person decides; the decision is written as a line with the approver, the rule that sent the case to them and the time, and the approved line points to it. Below the threshold, the field names the rule under which no approval was needed. Either way the record shows what the approver saw, because what the agent read before asking is in the log lines. Agents write under their own names. Each signs in with credentials of its own, scoped to one deployment and revocable, so written by names one agent in one deployment, never a shared account, and every read and write it makes is a line in the log. In our design, an agent that cannot attribute an event to a source does not write the line; it raises the event to a person. ## 7. Why the record is not a knowledge graph A knowledge graph could hold all of this. We keep the record simpler, for three reasons. - Context is the common case. Every line needs a time, a source and a writer, and many need an approver. A graph attaches that context through reification, named graphs or edge attributes [13]; the record makes it a field. A line is already the node a graph would create to carry its context. - The questions are closed. Was the order delivered in full? Who approved the discount? These want definite answers, and absence is information: no approval line means no approval. The open-world reading that suits joining knowledge across sources is the wrong default for operations. - People and agents both read it. A line of named fields in two scripts can be read by the person who checks it and by a language model, with no query language or schema to learn. The record keeps a graph's best idea, objects related to one another, through the qualified object-to-object relations of OCEL 2.0 [9]. A graph can be built from the record later. The reverse, recovering when a fact was learned and from which message, cannot be done once it was never written down. ## 8. How the next agent starts Compounding, as we use the word, is a property of the data model. Nobody tells the collections agent an invoice went out: it reads the line the orders agent wrote when the invoice was issued, on the day the customer's terms say, and writes its own line when it sends a reminder in Arabic. Later the supplier follow-ups agent reads the delivery lines both depend on. Each workflow added starts from what earlier ones wrote: customers, terms, and the reasons behind past exceptions. Three choices make this work: 1. Shared objects. Agents refer to the same order, customer and invoice by the same identifiers, so one agent's line is found by another. 2. Narrow reads. An agent pulls the lines for one object, event type or window of time, in order of valid time, not the whole record, because language models use long inputs unevenly [18]. 3. Reasons as data. The why field shows the next agent that a price was lowered for a repeat buyer, with approval, before it flags the invoice as wrong. This resembles the memory stream of generative agents [17], with two differences: the record is shared by many agents and people rather than private to one, and every entry carries its source, writer and approver, because in operations the question is not only what an agent remembers but whether anyone can check it. ## 9. Export in open formats A record that only one vendor's software can read is a risk for the company that relies on it. We therefore treat export as a design goal of the data model: the record should be able to leave at any time in standard, readable formats. This report states the goal; it is not a contractual commitment, and the formats a deployment exports are agreed in writing. The mapping is direct. Lines become OCEL 2.0 events, objects become OCEL 2.0 objects with changing attributes, and qualifiers carry roles [9], written in the standard's JSON, XML or SQLite formats for process-mining tools. The fields OCEL 2.0 does not model, record time, written by and approved by, travel as event attributes, and the full trace can be written in W3C PROV [12]. UTF-8 JSON keeps the Arabic as written [22]. Export loses one thing, and we say so: a process-mining tool sees one timestamp per event, so it sees the record as it stands now, not as it was known at a past moment. That history stays in the export's attributes, but standard tools will not use it unaided. ## 10. Implications for deployment For a Gulf company putting agents into its operations, the data model is the decision that is hardest to change later. Four practical points follow. - Start the record with one process. The first workflow defines the first objects and event types; later ones reuse them. Our engineers work on site, write down how the work really runs, including the calls and WhatsApp groups, and record a baseline before any agent acts. - Write off-system events on purpose. A call leaves no record unless someone writes one. The record has a channel for call notes and a field for the reason; the habit of using them is built with the team. - Decide where it lives before it fills. The record and its log are kept in the customer's country, and for each workflow we state in writing which model reads what, and where it runs. Each agent is run on the customer's past cases before it goes live, with their team marking what good looks like, and acts alone only within the customer's thresholds. - Ask any vendor the same questions. For a given line: which message did it come from, who wrote it, who approved it, when was it known, and can it leave in an open format? A data model that cannot answer will not improve with more agents on top. The record keeps Arabic and English on the same line because the same order, message and call are in both. That is in the fields from the first line, not a translation step added at the end. ## 11. Limitations This is a design report. It describes a data model and compares it with prior work; it reports no deployment, measurement or customer result. Figure 2 is our assessment from the cited sources, not a benchmark, and other readers could grade some cells differently. - Capture depends on people. The record has a place for a decision taken on a call, filled only if someone writes the note or an agent is party to the conversation. We have no evidence yet on how complete the record becomes in practice. - The why field is only as good as its source. A reason given in a message may be partial or wrong; the record keeps what was said and by whom, not what was true. - Event types drift. Two workflows can name one event differently, and a shared list of types needs upkeep, as any schema does. - Personal data. Lines name people and carry their messages. Data protection law differs across the Gulf states, and the data model does not settle what may be kept, for how long or where; that is agreed country by country and workflow by workflow. - The mappings are incomplete. OCEL 2.0 does not model record time, writer or approver, and PROV-DM has no term for cost or reason; both travel as attributes that standard tools may ignore. - Scale is untested. We have not measured the record at a large distributor's volume, or how quickly agents can query it. One development would change the conclusion: if an open standard for object-centric event logs added record time and per-line provenance, most of the reason for a separate model would go, and we would adopt that standard as the record's native form. ## 12. Conclusion The systems a Gulf company already runs record what was keyed into them. Many decisions that move its goods are taken elsewhere: on a call, in a WhatsApp group, on a delivery note signed on a tailgate. An agent that reads only the ERP acts on part of the operation, and one whose writes cannot be traced cannot be trusted with more. The operating record is our answer: one line per event, eleven fields in two scripts, two times, and a trace from every line to the message, call, document or person it came from and the person who approved it. Little in it is new; event sourcing, object-centric event logs, W3C PROV and bitemporal databases supplied nearly every part. What we add is the combination, written by agents and people as the work happens, kept beside the ERP, and read by the next agent before it acts. ## References [1] van der Aalst, W., Adriansyah, A., Alves de Medeiros, A. K., et al. (2012). Process Mining Manifesto. BPM 2011 Workshops, Part I, Lecture Notes in Business Information Processing 99, pp. 169-194, Springer. https://doi.org/10.1007/978-3-642-28108-2_19 [2] Kimball Group (n.d.). Transaction Fact Tables. Kimball Dimensional Modeling Techniques, kimballgroup.com. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/transaction-fact-table/ (accessed 14 October 2026) [3] Kimball Group (n.d.). Type 1: Overwrite. Kimball Dimensional Modeling Techniques, kimballgroup.com. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-1/ (accessed 14 October 2026) [4] Alter, S. (2014). Theory of Workarounds. Communications of the Association for Information Systems 34, Article 55. https://aisel.aisnet.org/cais/vol34/iss1/55/ [5] Fowler, M. (2005). Event Sourcing. martinfowler.com, 12 December 2005. https://martinfowler.com/eaaDev/EventSourcing.html (accessed 14 October 2026) [6] Helland, P. (2015). Immutability Changes Everything. Proceedings of CIDR 2015, the 7th Biennial Conference on Innovative Data Systems Research. https://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf [7] Institute of Electrical and Electronics Engineers (2023). IEEE Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams (IEEE 1849-2023). IEEE Standards Association, published 8 September 2023, superseding IEEE 1849-2016. https://standards.ieee.org/ieee/1849/10907/ (accessed 14 October 2026) [8] van der Aalst, W. M. P. (2019). Object-Centric Process Mining: Dealing with Divergence and Convergence in Event Data. Software Engineering and Formal Methods (SEFM 2019), Springer. https://doi.org/10.1007/978-3-030-30446-1_1 [9] Berti, A., Koren, I., Adams, J. N., et al. (2024). OCEL (Object-Centric Event Log) 2.0 Specification. arXiv:2403.01975. https://arxiv.org/abs/2403.01975 [10] OCEL 2.0 (Chair of Process and Data Science, RWTH Aachen University) (2026). OCEL 2.0: Formats. ocel-standard.org. https://www.ocel-standard.org/specification/formats/ (accessed 14 October 2026) [11] Groth, P. and Moreau, L. (eds.) (2013). PROV-Overview: An Overview of the PROV Family of Documents (W3C Working Group Note). W3C Working Group Note, 30 April 2013. https://www.w3.org/TR/prov-overview/ [12] Moreau, L. and Missier, P. (eds.) (2013). PROV-DM: The PROV Data Model (W3C Recommendation). W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-dm/ [13] Hogan, A., Blomqvist, E., Cochez, M., et al. (2021). Knowledge Graphs. ACM Computing Surveys 54(4), Article 71 (arXiv:2003.02320). https://arxiv.org/abs/2003.02320 [14] Snodgrass, R. and Ahn, I. (1985). A Taxonomy of Time in Databases. Proceedings of ACM SIGMOD 1985, pp. 236-246. https://doi.org/10.1145/318898.318921 [15] Kulkarni, K. and Michels, J.-E. (2012). Temporal Features in SQL:2011. ACM SIGMOD Record 41(3), pp. 34-43. https://sigmodrecord.org/publications/sigmodRecord/1209/pdfs/07.industry.kulkarni.pdf [16] Fowler, M. (2021). Bitemporal History. martinfowler.com, 7 April 2021. https://martinfowler.com/articles/bitemporal-history.html (accessed 14 October 2026) [17] Park, J. S., O'Brien, J. C., Cai, C. J., et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. arXiv:2304.03442. https://arxiv.org/abs/2304.03442 [18] Liu, N. F., Lin, K., Hewitt, J., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12, pp. 157-173. https://aclanthology.org/2024.tacl-1.9/ [19] Goregaokar, M. and Leroy, R. (eds.) (2026). Unicode Standard Annex #9: Unicode Bidirectional Algorithm. Unicode 18.0.0, revision 52, Unicode Consortium. https://www.unicode.org/reports/tr9/ (accessed 14 October 2026) [20] Klyne, G. and Newman, C. (2002). Date and Time on the Internet: Timestamps. RFC 3339, Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc3339 [21] Meta (n.d.). Messages webhook reference. WhatsApp Cloud API documentation, Meta for Developers. https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks/payload-examples (accessed 14 October 2026) [22] Bray, T. (ed.) (2017). The JavaScript Object Notation (JSON) Data Interchange Format. RFC 8259, Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc8259 ## Cite this paper ```bibtex @techreport{qantara2026operatingrecord, title = {The operating record: a data model for how a company runs}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/operating-record} } ``` ## Disclosure Every source is cited by number and was opened on or before 14 October 2026; dated web pages carry the date they were read. The comparison in figure 2, the field definitions and their mappings to OCEL 2.0 and PROV-DM, and the design of the operating record are Qantara's. The Sunday order, the Monday discount, the Tuesday correction, the record line in JSON and the table of three lines are illustrative examples written by us: names, identifiers, quantities and amounts are invented. Export in standard formats is described as a design goal, not a commitment. Canonical: https://qantara.systems/insights/operating-record --- # Generating complex and realistic benchmarks through evolutionary data degradation Research. Qantara Research, Qantara. 14 October 2026. 17 min read. > A search that makes Gulf business documents harder to read one defect at a time, and checks at every step that the answer can still be recovered. ## Abstract Tests for document extraction are usually built from clean documents, and the documents Gulf operations run on are rarely clean: delivery notes photographed after signing, purchase orders in two scripts, orders confirmed on WhatsApp in Arabic, English and Arabizi. We ask whether an evolutionary search can generate harder versions of such documents while keeping every one of them answerable. We wrote 48 synthetic Gulf business documents, eleven degradation operators (from Arabic letters that differ only by dots to struck-through handwritten corrections), a rule-based validator that rejects any variant whose item, quantity, unit, price or date can no longer be recovered, and a quality-diversity archive that keeps the hardest variant for each operator family and degradation level. Over 16 generations the hardest variant per document went from a mean character error rate of 7.0% to 35.0%, while 88.6% of all children stayed recoverable. With the same number of evaluations, random degradation reached 24.0%, and only 43.4% of random variants carrying twelve operators stayed recoverable. Selection favoured code-switching, Arabizi and handwritten corrections. We have not yet evaluated any model on the result; that is the next step. ## Key findings 1. Under a recoverability constraint, evolution raised the mean character error rate of the hardest variant per document from 7.0% in the first generation to 35.0% in the sixteenth, while between 86.5% and 90.3% of each generation's children stayed recoverable. 2. At the same 384 evaluations per document, evolved variants were harder than the hardest random ones: a mean character error rate of 35.0% against 24.0%, and harder in 47 of 48 documents. 3. Random degradation loses the answer quickly: the share of random variants whose key fields a rule-based parser could still recover fell from 93.1% with one operator to 43.4% with twelve, which is why a generated benchmark needs a validator. 4. Selection reshaped a uniform proposal: code-switching, handwritten corrections and Arabizi made up 60.9% of the operator applications in the hardest variants, against 1.0% to 2.3% each for keyboard typos, Arabic dot confusions, stray marks and Latin OCR confusions. 5. Field deletion and Latin and digit OCR confusions were the operators most likely to destroy an answer, making 36.7% and 19.1% of children unrecoverable when each was applied alone, and prices were the field lost most often. ## 1. Introduction A model that reads operational documents is usually tested on documents easier than the ones it will meet. Public extraction benchmarks are collected, cleaned and labelled before anyone measures anything: the scanned receipt competition at ICDAR 2019, for instance, released 1,000 whole scanned receipt images with annotations [1]. Consider an illustrative case from Gulf distribution. A delivery note is printed in English and Arabic; a quantity is struck through and rewritten by hand when a carton is short; the note is photographed and sent to a WhatsApp group; and the customer's confirmation of the next order arrives in the same group in a mix of Arabic, English and Arabizi (Arabic written in Latin letters, with digits standing for sounds Latin lacks: 3 for ع, 7 for ح, 2 for the glottal stop.). A test set of clean documents says little about how a model will read that. Noise of this kind is known to matter. Across six downstream tasks, van Strien et al. found that OCR errors had a consistent effect, with some tasks harmed far more than others [2]. OHRBench, 8,561 document images with questions over them, separates OCR noise into semantic and formatting noise and traces both into retrieval-augmented generation [3]. Character-level noise, synthetic or natural, breaks neural translation of text that people read without trouble [4]. Arabic adds failure modes of its own. Almost half its letters share a base shape, or rasm (The skeleton of an Arabic letter without its dots. ب, ت and ث share one rasm and differ only in the number and position of their dots.), and are told apart only by dots [5]; in a test of four Arabic OCR systems on 240 text images, characters without dots were recognised significantly better than characters with one, two or three [6]. Collecting and labelling degraded documents by hand is slow, and it yields one level of difficulty, fixed when the documents were gathered. A fixed test set also ages: once its items reach training data, a high score may reflect memory rather than skill, the problem known as benchmark contamination (Test items, or their answers, appearing in a model's training data, so that a score measures recall of the item rather than the ability the benchmark was built to test.) [7, 8]. A generator with a seed can produce fresh variants whenever they are needed, at the difficulty asked for, with the answer known. This paper builds such a generator and studies how it behaves. Its contributions are: - A degradation model for Gulf business documents: eleven operators in four families, from OCR confusions between Arabic letters that differ only by dots to Arabizi, code-switching and handwritten corrections, applied to documents held as typed fields so that their structure survives for measurement. - A recoverability validator: a rule-based reference parser whose reading is aligned field by field with the ground truth, so that every variant kept still has a correct answer for its item, quantity, unit, price and date. - An evolutionary search with a quality-diversity archive that produces, for each document, a ladder of variants from lightly to heavily degraded, compared with random degradation at the same cost. - Code and output that reproduce every number in this paper from a fixed seed. What this paper does not do is evaluate a model. It shows that the generator produces harder documents that can still be answered; whether models find them harder is the next experiment, set out under Limitations. ## 2. Background and related work ### Making evaluation data harder on purpose Several lines of work make data harder by rewriting it. Evol-Instruct uses a language model to rewrite instructions step by step into more complex ones, deepening or broadening each, and discards evolutions that fail [9]. Dynabench puts people in the loop: annotators write examples that a target model gets wrong but another person would not [10]. GSM-Symbolic generates variants of grade-school mathematics questions from symbolic templates, and reports that accuracy falls when only the numbers change, and by up to 65% when a single clause that seems relevant, but does not change the answer, is added [11]. Our setting differs in two ways: the rewriting is a search over defects rather than a rewrite by a model, and the difficulty is bounded by a constraint, checked by code, that the answer must survive. ### Perturbation and behavioural testing CheckList organises behavioural tests by capability and test type and generates large numbers of test cases from templates [12]. NL-Augmenter collects an initial set of 117 transformations and 23 filters contributed by a large community, several of them perturbations of the kind used here [13]. Belinkov and Bisk's synthetic noise includes keyboard typos, a letter replaced by a neighbouring key, which our typo operator follows [4]. These libraries apply one perturbation, or a fixed mix, at a set rate. We compose many, search over their combinations, and keep only the variants that can still be answered. ### OCR error, Arabic script and Arabizi Post-OCR correction for Arabic has a long history, including the correction of character segments with the help of language models [14], and dots are among the main sources of the errors such correction meets [6]. Arabizi is a different problem, of transcription rather than recognition: Arabic typed in Latin letters, with numerals for the letters that have no Latin equivalent, which Darwish detects and converts back to Arabic script [15]. To measure damage we use the character error rate (CER (Character error rate: the number of characters that must be inserted, deleted or substituted to turn the degraded text back into the clean one, divided by the length of the clean text.)), computed with Myers' bit-vector algorithm for edit distance [16]. Standard CER first turns a page into a single string, so a block read in the wrong order is counted as many character errors; Clausner et al. proposed a flexible measure for that reason [17]. We take a simpler route, described in the next section. ### Search with populations and archives Genetic algorithms evolve a population of candidates by selection, recombination and mutation [18, 19]. A search that maximises one score tends to converge on one kind of answer. MAP-Elites, a quality-diversity (A family of search methods that keep many good candidates spread across features the user chooses, rather than a single best candidate.) method, divides a space of features into cells and keeps the best candidate found in each, so the search returns a map of candidates that are both strong and different [20]. Rainbow Teaming applied the idea to evaluation, casting the generation of adversarial prompts as a quality-diversity problem with an archive built on MAP-Elites [21]. Our archive's features are the family of defects that dominates a variant and how many defects it carries. ### Fresh test data Contamination is now a central concern of benchmark design. Sainz et al. argue for measuring it benchmark by benchmark [7]; Jacovi et al. propose encrypting public test data and asking model providers for controls that keep it out of training [8]; LiveBench adds and updates its questions every month [22]. A seeded generator is one more answer: the published code fixes the method, while private templates and a private seed can produce variants that have never been online. ## 3. Method ### Documents The script writes 48 synthetic documents from three templates in turn, a delivery note, a purchase order and a WhatsApp-style order confirmation, so 16 of each. A country is drawn for each document (13 came out Omani, 22 Saudi and 13 Emirati) and with it the place names (Sohar, Nizwa, Jeddah, Dammam, Jebel Ali, Fujairah and others), the currency and its decimals (OMR to three places, SAR and AED to two) and, on purchase orders, the VAT rate. Each document lists three to five items, 3.9 on average, drawn from a catalogue of twenty food and industrial items, each with an English name, an Arabic name, an Arabizi spelling and a SKU. Delivery notes and purchase orders give each item in both languages; a WhatsApp confirmation gives it once, in one language, line by line, sometimes with Arabic-Indic digits. Every document has exactly one date, in one of several formats. The clean documents average 341 characters. Every party, number and code in the documents is synthetic, and every example in this paper is illustrative. The Arabic strings were written by us and have not yet been reviewed by a native Gulf reader. Each document keeps its ground truth: the date and, for each line, the item, quantity, unit and price. ### Eleven operators An operator applies one defect to one field, one line or the line order. The eleven fall into four families: visual defects that come from paper and cameras, script defects that come from writing Arabic and English with the tools at hand, including code-switching (Moving between two languages inside one message or one sentence; here, Arabic and English.), human defects of typing and shorthand, and layout defects of reading order and missing fields. The table gives each with an illustrative example and, from the run itself, how often it alone left a document unrecoverable. **Table 1. The eleven degradation operators. Examples are illustrative, applied to text from the run's synthetic documents; the last column is from the run, counting only children to which no other operator was applied.** | Operator | Family | Illustrative example | Unrecoverable when applied alone | | --- | --- | --- | --- | | OCR confusion, Arabic dots | Visual | أسمنت → أسمنث (one dot pattern read for another) | 3.8% (32 of 837) | | OCR confusion, Latin and digits | Visual | air filter → air filtcr; 0 read as 8; a vertical table rule read as l | 19.1% (162 of 847) | | Handwritten correction | Visual | a struck 22 written before the true 21 | 0.0% (0 of 818) | | Noise characters | Visual | Workshop → Workshop¦ | 0.5% (4 of 821) | | Digit script swap | Script | 25.50 → ٢٥٫٥٠ | 0.0% (0 of 857) | | Arabizi | Script | التاريخ → al tareekh | 5.1% (39 of 761) | | Code-switching | Script | نايلون تغليف → stretch film; يعطيك العافية inserted after a total | 0.6% (5 of 840) | | Abbreviation and unit variants | Human | 4.500 → 4.5; cartons → ctns; 17 Oct 2026 → 17.10.2026 | 3.7% (32 of 872) | | Keyboard typo | Human | Delivery → Delivvery; a letter swapped for its neighbour on the keyboard | 10.8% (87 of 805) | | Line reordering | Layout | an item line read before the header | 0.0% (0 of 877) | | Field deletion | Layout | an empty column where the Arabic item name was | 36.7% (310 of 844) | Computed by scripts/insights/degradation.py; each operator's definition is documented in the script. ### The validator A variant is useful as a test item only if its answer is still in it. The validator is a rule-based reference parser that reads the degraded text as a careful deterministic extractor would. It drops values marked as struck through, folds Arabic-Indic digits into Western ones, strips stray marks, normalises Arabic letter variants (the hamza seats on alif, ta marbuta and alif maqsura), repairs O and l to 0 and 1 inside numbers, and finds each item by fuzzy match against an alias table built from the generator's catalogue: the English, Arabic and Arabizi names and the SKU, with an edit tolerance that grows with the length of the name. On each item's line it reads the unit, the quantity beside it and the price, and it reads the one date in the text. The parser's reading is then aligned with the ground truth field by field. A variant is recoverable if the same items come back with the same quantity, unit and price, and the same date; otherwise it is rejected. All 48 clean documents pass. Separate plausibility bounds reject a variant whose length falls outside 0.75 to 1.5 times the clean length, whose stray marks exceed 4% of the clean length, or which holds more than three handwritten corrections or three inserted phrases. ### Difficulty Fitness is a difficulty proxy: CER plus half the structural damage. We compute CER line by line, each degraded line against its own clean line, summed and divided by the length of the clean text. A line that moved is then not also counted as rewritten, the problem Clausner et al. describe for whole-page measures [17]; the move is counted once, in structural damage. Structural damage is the mean of three shares: how far the line order is from the original, as a normalised Kendall tau distance (The share of pairs of lines that appear in the opposite order to the original: 0 for the original order, 1 for the order fully reversed.), the share of fields deleted, and the share of key fields whose surface form no longer matches the clean text. We also report whole-text CER. ### Search Each document evolves on its own for 16 generations, starting from the clean document as generation 0. Each generation makes 24 children. A parent is drawn, half the time uniformly from the archive and otherwise by a tournament of three among the eight hardest variants found so far; with probability 0.2 it is crossed with a second parent, each line coming from one or the other; then one, two or three operators (with probabilities 0.5, 0.3 and 0.2), each drawn uniformly from the eleven, are applied. A variant may carry at most twelve operator applications. When a mutation would exceed that budget, one damaged line, or the line order, is first restored to its clean state, so that the search keeps moving at the budget; this happened 8,752 times. Children that pass the validator and the bounds, and are not copies of an earlier variant, compete for the archive. Its cells cross the dominant operator family (four values) with the number of operator applications (1 to 3, 4 to 6, 7 to 9, 10 to 12), sixteen cells per document, and each cell keeps its hardest variant. The parents of the following generation are the archive's variants and the eight hardest found so far. That is 384 evaluations per document and 18,432 children in all. **Figure 1. The search loop for one document** Follow the arrows: children are made from parents, checked against the ground truth, and the survivors compete for the cells of the archive, which supplies the parents of the following generation. - Clean document: template and ground truth - Make children: crossover, 1 to 3 operators - Validate: parser against ground truth - Rejected: a key field lost, or implausible - Parents: archive and eight hardest - Archive: hardest per family and level - Clean document → Make children (generation 1) - Make children → Validate - Validate → Rejected (fails) - Validate → Archive (passes, scored) - Archive → Parents - Parents → Make children (each generation) Qantara, the method of this paper as implemented in scripts/insights/degradation.py. ### A random baseline To ask whether the search adds anything, each document also gets 384 random variants, the same number of evaluations: 32 at each level from one to twelve operators, drawn uniformly, applied to the clean document and checked by the same validator and bounds. The script uses only the Python 3 standard library and draws every random number from generators seeded with 20261014. Two runs under different hash seeds wrote byte-identical output, and a run takes about a minute and a half on a laptop. ## 4. Results ### Difficulty rises and answers survive The mean CER of the hardest variant per document rose from 7.0% in generation 1 to 35.0% in generation 16, and the mean over the whole archive from 4.5% to 18.1% (median 4.0% to 16.4%). The rise slows from about generation 6, when the hardest variants reach the budget: the eight hardest per document carried 11.4 operator applications on average in generation 6 and 11.9 in generation 16, so later gains come from choosing which twelve defects to keep, not from adding more. Throughout, between 86.5% and 90.3% of each generation's children stayed recoverable, 16,329 of 18,432 in all (88.6%); 15,945 (86.5%) also passed the plausibility bounds and were not copies of an earlier variant. **Figure 2. Difficulty rises while answers survive** Read across the generations: the top line is the share of children still recoverable; the two lower lines are mean character error rates, for the hardest variant per document and for the whole archive. | x | Children still recoverable (%) | Hardest variant per document, mean CER (%) | Whole archive, mean CER (%) | | --- | --- | --- | --- | | 1 | 88.3 | 7 | 4.5 | | 2 | 89.6 | 12.2 | 7.5 | | 3 | 90.3 | 17 | 10 | | 4 | 88.4 | 21.6 | 12.4 | | 5 | 87.6 | 25.3 | 14 | | 6 | 89.1 | 28 | 15 | | 7 | 87.5 | 29.3 | 15.5 | | 8 | 86.5 | 30.2 | 15.9 | | 9 | 89.4 | 31.1 | 16.4 | | 10 | 88.5 | 32.5 | 16.7 | | 11 | 88.9 | 32.7 | 17 | | 12 | 89.9 | 33.5 | 17.2 | | 13 | 87.2 | 33.7 | 17.5 | | 14 | 90.1 | 34.1 | 17.6 | | 15 | 88 | 34.3 | 17.8 | | 16 | 88.1 | 35 | 18.1 | Qantara, computed by scripts/insights/degradation.py (seed 20261014) on 14 October 2026: 48 synthetic documents, 24 children per document per generation; CER is line-aligned. ### Evolution against random degradation At the same 384 evaluations per document, the hardest evolved variant had a mean CER of 35.0% and the hardest random one 24.0%. The evolved variant was the harder of the two in 47 of 48 documents by CER, and in all 48 by the fitness the search optimised. **Table 2. The hardest variant per document after 384 evaluations: evolution against random degradation, 48 documents.** | Measure | Evolved | Random | | --- | --- | --- | | Mean CER | 35.0% | 24.0% | | Median CER | 31.9% | 22.8% | | Standard deviation of CER | 9.7 points | 6.5 points | | Mean fitness (CER + 0.5 × structural damage) | 0.434 | 0.300 | | Documents where this variant is the harder, by CER | 47 of 48 | 1 of 48 | Computed by scripts/insights/degradation.py, seed 20261014. Random degradation also shows why a validator is needed. With one random operator, 93.1% of variants stayed recoverable; with twelve, 43.4%. A benchmark built by applying a dozen random defects and keeping the original labels would, at that level, hold an answer the text no longer supports in more than half its items. The search avoids this by building each variant one validated step at a time: its children stayed recoverable close to nine times in ten in every generation, including the late ones, in which the hardest variants carried close to the full budget of twelve defects. **Figure 3. Random degradation loses the answer quickly** Read left to right as more random operators are applied to a clean document: the falling line is the share of variants still recoverable, the rising line the mean CER of those kept. | x | Random variants still recoverable (%) | Mean CER of those kept (%) | | --- | --- | --- | | 1 | 93.1 | 1.3 | | 2 | 87.6 | 2.6 | | 3 | 80.9 | 3.7 | | 4 | 74.9 | 5.1 | | 5 | 70.1 | 6.2 | | 6 | 66 | 7.4 | | 7 | 61.6 | 8.5 | | 8 | 57.4 | 9.8 | | 9 | 52.7 | 10.9 | | 10 | 50.4 | 11.9 | | 11 | 47 | 13.1 | | 12 | 43.4 | 13.8 | Qantara, computed by scripts/insights/degradation.py (seed 20261014) on 14 October 2026: 32 random variants per level per document, 1,536 per level in all. ### What selection kept Operators were proposed uniformly: each accounts for between 8.8% and 9.3% of the 31,313 applications made during the search. Selection changed the mix. In the final archive, handwritten corrections account for 19.9% of operator applications, code-switching for 15.3% and Arabizi for 13.2%, while Latin and digit OCR confusions (3.7%), keyboard typos (4.2%), Arabic dot confusions (4.4%) and stray marks (4.5%) fell well below their share of the proposal. In the hardest variant of each document the skew is stronger: code-switching, corrections and Arabizi make up 60.9% of applications, and typos, dot confusions, stray marks and Latin OCR confusions between 1.0% and 2.3% each. **Figure 4. Proposed evenly, kept unevenly** For each operator, the first bar is its share of all applications made during the search and the second its share of the applications carried by the final archive. | | Proposed during the search | Kept in the final archive | | --- | --- | --- | | Handwritten correction | 9.1 | 19.9 | | Code-switching | 9.1 | 15.3 | | Arabizi | 8.8 | 13.2 | | Field deletion | 9.1 | 10.7 | | Abbreviation and unit variants | 9.3 | 9.4 | | Line reordering | 9.3 | 9.1 | | Digit script swap | 9.1 | 5.6 | | Noise characters | 9.1 | 4.5 | | OCR confusion, Arabic dots | 9.2 | 4.4 | | Keyboard typo | 8.8 | 4.2 | | OCR confusion, Latin and digits | 9 | 3.7 | Qantara, computed by scripts/insights/degradation.py (seed 20261014) on 14 October 2026: 31,313 applications made; 5,677 applications carried by the 767 variants of the final archive. Part of this is the proxy, and we read it that way. Rewriting a whole field in another script, or inserting a phrase, changes many characters in one application, where a dot confusion changes one; a correction adds a struck value several characters long and costs the parser nothing. CER rewards whatever changes characters, and the search found the cheapest ways to change them. Whether a model finds a struck quantity harder than a missing dot is a question for the next experiment, and the answer may invert this ranking: one dot can turn one word into another, and a reader of the photograph sees a strike that a transcript can only mark. What the archive does guarantee is coverage: 767 of its 768 cells were filled, so for almost every document the benchmark can be sliced by the kind of defect as well as by how much. ### What breaks a document Some operators are far more likely than others to destroy an answer. Counting only children where one operator was applied, field deletion left the document unrecoverable 36.7% of the time (310 of 844), Latin and digit OCR confusions 19.1% (162 of 847) and keyboard typos 10.8% (87 of 805), followed by Arabizi at 5.1%, Arabic dot confusions at 3.8% and abbreviations at 3.7%. Digit script swaps, line reordering and handwritten corrections never did, because the parser folds digits, ignores line order and drops struck values. Of the 2,103 children rejected as unrecoverable, the price was lost in 33.0%, the quantity in 20.7%, the unit in 19.9%, the date in 15.3% and the item in 14.6%; a child can lose more than one. Prices are fragile because every character in them counts: one misread digit, one stray point, or trailing zeros dropped from a price that has no currency beside it is enough. ### A ladder of difficulty Because the archive is divided by the number of operator applications, it holds a graded series for every document. Mean CER in the final archive was 6.5% at one to three applications, 14.1% at four to six, 21.8% at seven to nine and 29.8% at ten to twelve. This ladder, more than the single hardest variant, is what a model evaluation needs: accuracy measured on each rung shows where a model starts to fail. **Table 3. The final archive by degradation level: 48 documents, four operator families at each level.** | Operator applications | Variants | Mean CER | Median CER | | --- | --- | --- | --- | | 1 to 3 | 192 | 6.5% | 5.9% | | 4 to 6 | 192 | 14.1% | 13.0% | | 7 to 9 | 192 | 21.8% | 20.2% | | 10 to 12 | 191 | 29.8% | 28.4% | Computed by scripts/insights/degradation.py, seed 20261014. One cell stayed empty: one document's human family (typos and shorthand) at ten to twelve applications. ### Messages degrade further than forms The hardest WhatsApp confirmations reached a mean CER of 46.4%, against 28.2% for delivery notes and 30.4% for purchase orders. Messages are shorter, 229 characters on average against 422 and 370, so each defect weighs more. Whole-text CER, which counts a moved line as rewritten, was 30.0% over the archive against 18.1% line by line, and 46.9% against 35.0% for the hardest variants: measured over the whole text, reading order alone would overstate the damage by between a third and two thirds. ```text Clean [10:37] Dubai sales: Hello, الطلب مؤكد UHT milk 12 cartons @ 46.50 AED white sugar 5 bags @ 29.00 AED 2 cartons tomato paste, 52.00 AED basmati rice 9 bags @ 40.75 AED [10:39] Dubai sales: التوصيل 16 أكتوبر 2026 إلى سوبرماركت الشارقة Hardest variant after 16 generations [10:37] Dubai مبيعات: Hello, UHT milk 12 cartons @ 46.50 AED white sugar مثل المرة الماضية -6- 5 bags @ ۲۹٫۰۰ AED 2 cartons tomato paste, 5̶8̶.̶0̶0̶ 52.00 AED أرز بسمتي 9 مثل المرة الماضية bags @ ۴۰٫۷۵ AED [10:39] Dubai sales: al tawseel 1̶3̶ ̶أ̶ك̶ت̶و̶ب̶ر̶ ̶2̶0̶2̶6̶ 16 أكتوبر 2026 إلى سوبرماركت al shariqa ``` An illustrative synthetic WhatsApp order confirmation (document 2 of the run, Emirati) and its hardest recoverable variant after 16 generations: 12 operator applications, line-aligned CER 58.3%. The reference parser still reads every item, quantity, unit and price, and the date. ### One document, generation by generation The widget follows one illustrative document, a synthetic Emirati delivery note, along the line of ancestors of its hardest final variant. In generation 1 a line moved, a dot changed in أسمنت and the total was struck and rewritten; by generation 7 two Arabic labels were in Arabizi, two item names were gone and the date carried a struck correction; by generation 16 the CER was 0.371, with every key field still recoverable. The budget forced restorations along the way, which is why the moved line returns to its place and some defects appear and later disappear. **Figure 5. One synthetic delivery note, generation by generation** (interactive on the page) Step through the generations. Each text is an ancestor of the hardest variant of this illustrative delivery note, with its line-aligned character error rate as a fraction of the clean text's length. | Generation | Character error rate | Text | | --- | --- | --- | | 0 | 0.0% | Delivery note / إشعار تسليم No. DN-38263 Date / التاريخ: 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop, Fujairah / ورشة، الفجيرة AFL-9934 \| air filter \| فلتر هواء \| 34 box \| 73.25 AED STF-1982 \| stretch film \| نايلون تغليف \| 29 rolls \| 25.50 AED CEM-5318 \| cement \| أسمنت \| 21 bags \| 15.75 AED Total / المجموع: 3560.75 AED Driver: vehicle 2817 | | 1 | 4.6% | Delivery note / إشعار تسليم AFL-9934 \| air filter \| فلتر هواء \| 34 box \| 73.25 AED No. DN-38263 Date / التاريخ: 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop, Fujairah / ورشة، الفجيرة STF-1982 \| stretch film \| نايلون تغليف \| 29 rolls \| 25.50 AED CEM-5318 \| cement \| أسمنث \| 21 bags \| 15.75 AED Total / المجموع: 3̶1̶6̶0̶.̶7̶5̶ 3560.75 AED Driver: vehicle 2817 | | 2 | 10.4% | Delivery note / إشعار تسليم AFL-9934 \| air filter \| \| 34 box \| 73.25 AED No. DN-38263 Date / al tareekh: 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop¦, Fujairah / ورشة، الفجيرة STF-1982 \| stretch film \| نايلون تغليف \| 29 rolls \| 25.50 AED CEM-5318 \| cement \| أسمنث \| 21 bags \| 15.75 AED Total / المجموع: 3̶1̶6̶0̶.̶7̶5̶ 3560.75 AED Driver: vehicle 2817 | | 4 | 15.1% | Delivery note / إشعار تسليم AFL-9934 \| air filter \| \| 34 box \| 73.25 AED No. DN-38263 Date / al tareekh: 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop¦, Fujairah / ورشة، الفجيرة STF-1982 \| stretch film \| نايلون تغليف \| 29 rolls \| 25.50 AED CEM-5318 \| cemeht \| asmnth \| 21 bags \| 15.75 AED Total / al majmoo3: 3̶1̶6̶0̶.̶7̶5̶ 3560.75 AED Driver: vehicle 2817 | | 7 | 29.0% | Delivery note / Delivery note AFL-9934 \| air filter \| \| 34 box \| 73.25 AED No. DN-38263 Date / al tareekh: 1̶1̶ ̶O̶c̶t̶ ̶2̶0̶2̶6̶ 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop¦, Fujairah / ورشة، الفجيرة STF-1982 \| stretch film \| \| 29 rolls \| 25.50 AED CEM-5318 \| cemeht \| asmnth \| 21 bags \| 15.75 AED Total / al majmoo3: 3̶1̶6̶0̶.̶7̶5̶ 3560.75 AED Driver: vehicle 2817 | | 12 | 36.2% | Delivery note / Delivery note No. DN-38263 Date / al tareekh: 1̶1̶ ̶O̶c̶t̶ ̶2̶0̶2̶6̶ 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop, Fujairah / ورشة، الفجيرة AFL-9934 \| air filter \| \| 34 box \| 73.25 AED STF-1982 \| \| \| 29 rolls \| 25.50 AED CEM-5318 \| cemeht \| asmnth \| 21 bags \| 15.75 AED Total / al majmoo3: 3̶1̶6̶0̶.̶7̶5̶ 3560.75 يعطيك العافية AED Driver: vehicle 2817 | | 16 | 37.1% | Delivery note / Delivery note No. DN-38263 Date / al tareekh: 1̶1̶ ̶O̶c̶t̶ ̶2̶0̶2̶6̶ 17 Oct 2026 From: Jebel Ali warehouse To / إلى: Workshop, Fujairah / ورشة، الفجيرة \| air filtcr \| \| 34 box \| 73.25 AED STF-1982 \| \| \| 29 roll \| 25.50 AED CEM-5318 \| cement \| أسمنت \| 21 bags \| 15.75 AED Total / al majmoo3: 3̶1̶6̶0̶.̶7̶5̶ 3560.75 يعطيك العافية AED Driver: vehicle 2817 | ## 5. Implications for deployment For a Gulf company putting a model to work on its documents, the lesson is that the test set should look like the documents, at several levels of damage, with answers known to be right. Three practices follow. - Start from the company's own templates and past cases. The generator here is synthetic. In a deployment, the clean documents and their ground truth come from the company's own records, so the defects land on its item names, its units and the way its customers write. - Validate every generated item. Random degradation at twelve defects left fewer than half the variants answerable. A test item whose answer is no longer in the text measures noise, not the model. - Report accuracy by level and by family. One average hides where a model fails. A ladder shows the level of damage at which accuracy drops, and that is where a threshold belongs: below it the agent proceeds, above it a person checks. This is how we approach evaluation at Qantara. Each agent is run on the customer's past cases before it goes live, with their team marking what good looks like, and the work arrives in Arabic and English on the same document and the same message. Degraded variants of those past cases could extend that test to documents that have not arrived yet, and the thresholds the customer sets, above which a person approves, can be placed with the ladder in hand. Because the record and its log are kept in the customer's country, the variants can be generated where the record already lives. ## 6. Limitations This paper does not evaluate any model on the benchmark. It shows that the search produces variants that are harder by a character-level proxy and still answerable by a rule-based parser. It does not show that models find them harder, or which defects hurt models most. The next step is to measure model accuracy against degradation level: run extraction models, from rule-based parsers to small and frontier language models, on every rung of the ladder and every family, and report where accuracy falls. - Text, not images. The operators act on transcribed text, and OCR confusions are simulated character by character. A fuller pipeline would render each document, damage the image and run an OCR engine, whose errors are correlated in ways ours are not. - Hand-written operators, uncalibrated rates. The operators, their probabilities, the budget of twelve applications and the plausibility bounds are our choices. None is calibrated against how often each defect occurs in real Gulf documents, which we have not measured. - A gameable proxy. CER rewards defects that change many characters, and the search exploited that with code-switching and inserted phrases. A proxy closer to model difficulty, or model accuracy itself, would change what the search keeps. - One validator. Recoverable means recoverable by our parser. A person might recover fields the parser cannot, or be misled where it is not, and the currency, fixed by the country, is not checked. - Small and synthetic. 48 documents from three templates and twenty items, one seed and one run. The Arabic was written by us and has not been reviewed by a native Gulf reader. ## 7. Conclusion Evolutionary degradation under a recoverability constraint does what a benchmark generator needs. In sixteen generations it made synthetic Gulf business documents much harder by character error rate, harder than random degradation at the same cost, while keeping close to nine children in ten answerable and filling a ladder of difficulty for every document. The search also showed what a character-level proxy rewards, which is not necessarily what makes a document hard for a model. The generator and its output are published with this paper. The next step is to put models on the ladder and measure where each one starts to fail. ## References [1] Huang, Z., Chen, K., He, J., et al. (2019). ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction. Proceedings of ICDAR 2019, IEEE; arXiv:2103.10213. https://arxiv.org/abs/2103.10213 [2] van Strien, D., Beelen, K., Coll Ardanuy, M., et al. (2020). Assessing the Impact of OCR Quality on Downstream NLP Tasks. Proceedings of ICAART 2020, Volume 1: ARTIDIGH, SciTePress. https://www.scitepress.org/Papers/2020/91690/ [3] Zhang, J., Zhang, Q., Wang, B., et al. (2024). OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation. arXiv:2412.02592 (ICCV 2025). https://arxiv.org/abs/2412.02592 [4] Belinkov, Y. and Bisk, Y. (2018). Synthetic and Natural Noise Both Break Neural Machine Translation. Proceedings of ICLR 2018; arXiv:1711.02173. https://arxiv.org/abs/1711.02173 [5] Al-Shaibani, M. S. and Ahmad, I. (2025). Dotless Arabic Text for Natural Language Processing. Computational Linguistics 51(2), 557-598. https://aclanthology.org/2025.cl-2.5/ [6] Alghamdi, M. and Teahan, W. (2017). Experimental evaluation of Arabic OCR systems. PSU Research Review 1(3), 229-241. https://www.emerald.com/insight/content/doi/10.1108/PRR-05-2017-0026/full/html [7] Sainz, O., Campos, J., García-Ferrero, I., et al. (2023). NLP Evaluation in trouble: On the Need to Measure LLM Data Contamination for each Benchmark. Findings of the Association for Computational Linguistics: EMNLP 2023. https://aclanthology.org/2023.findings-emnlp.722/ [8] Jacovi, A., Caciularu, A., Goldman, O., et al. (2023). Stop Uploading Test Data in Plain Text: Practical Strategies for Mitigating Data Contamination by Evaluation Benchmarks. Proceedings of EMNLP 2023. https://aclanthology.org/2023.emnlp-main.308/ [9] Xu, C., Sun, Q., Zheng, K., et al. (2023). WizardLM: Empowering Large Pre-Trained Language Models to Follow Complex Instructions. arXiv:2304.12244 (ICLR 2024). https://arxiv.org/abs/2304.12244 [10] Kiela, D., Bartolo, M., Nie, Y., et al. (2021). Dynabench: Rethinking Benchmarking in NLP. Proceedings of NAACL-HLT 2021. https://aclanthology.org/2021.naacl-main.324/ [11] Mirzadeh, I., Alizadeh, K., Shahrokhi, H., et al. (2024). GSM-Symbolic: Understanding the Limitations of Mathematical Reasoning in Large Language Models. arXiv:2410.05229. https://arxiv.org/abs/2410.05229 [12] Ribeiro, M. T., Wu, T., Guestrin, C., et al. (2020). Beyond Accuracy: Behavioral Testing of NLP Models with CheckList. Proceedings of ACL 2020. https://aclanthology.org/2020.acl-main.442/ [13] Dhole, K. D., Gangal, V., Gehrmann, S., et al. (2021). NL-Augmenter: A Framework for Task-Sensitive Natural Language Augmentation. arXiv:2112.02721. https://arxiv.org/abs/2112.02721 [14] Magdy, W. and Darwish, K. (2006). Arabic OCR Error Correction Using Character Segment Correction, Language Modeling, and Shallow Morphology. Proceedings of EMNLP 2006. https://aclanthology.org/W06-1648/ [15] Darwish, K. (2014). Arabizi Detection and Conversion to Arabic. Proceedings of the EMNLP 2014 Workshop on Arabic Natural Language Processing (ANLP). https://aclanthology.org/W14-3629/ [16] Myers, G. (1999). A fast bit-vector algorithm for approximate string matching based on dynamic programming. Journal of the ACM 46(3), 395-415. https://doi.org/10.1145/316542.316550 [17] Clausner, C., Pletschacher, S. and Antonacopoulos, A. (2020). Flexible character accuracy measure for reading-order-independent evaluation. Pattern Recognition Letters 131, 390-397. https://doi.org/10.1016/j.patrec.2020.02.003 [18] Holland, J. H. (1992). Adaptation in Natural and Artificial Systems: An Introductory Analysis with Applications to Biology, Control, and Artificial Intelligence. MIT Press (first published 1975, University of Michigan Press). https://openlibrary.org/isbn/0262581116 [19] Goldberg, D. E. (1989). Genetic Algorithms in Search, Optimization, and Machine Learning. Addison-Wesley. https://openlibrary.org/isbn/0201157675 [20] Mouret, J.-B. and Clune, J. (2015). Illuminating search spaces by mapping elites. arXiv:1504.04909. https://arxiv.org/abs/1504.04909 [21] Samvelyan, M., Raparthy, S. C., Lupu, A., et al. (2024). Rainbow Teaming: Open-Ended Generation of Diverse Adversarial Prompts. Advances in Neural Information Processing Systems 37 (NeurIPS 2024); arXiv:2402.16822. https://arxiv.org/abs/2402.16822 [22] White, C., Dooley, S., Roberts, M., et al. (2024). LiveBench: A Challenging, Contamination-Limited LLM Benchmark. arXiv:2406.19314 (ICLR 2025). https://arxiv.org/abs/2406.19314 ## Cite this paper ```bibtex @techreport{qantara2026evolutionarydatadegradation, title = {Generating complex and realistic benchmarks through evolutionary data degradation}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/evolutionary-data-degradation} } ``` ## Disclosure The documents, operators, validator, search and every number in the method and results are ours, computed by scripts/insights/degradation.py (seed 20261014) and published with its output; the documents and every example drawn from them are synthetic and illustrative, and no real company, person or document appears. Statements about prior work are cited to the sources listed, read on 14 October 2026. Reproduce: `python3 scripts/insights/degradation.py` (script `scripts/insights/degradation.py`, output `content/insights/data/degradation.json`). Canonical: https://qantara.systems/insights/evolutionary-data-degradation --- # From pilot to production: why AI stalls in Gulf operations Report. Qantara Research, Qantara. 14 October 2026. 19 min read. > What public surveys say about the distance between an AI pilot and AI in production, why that distance is longer in Gulf operations, and what the evidence says shortens it. ## Abstract Most companies that try AI do not yet run it in production, and fewer still find it in their profit and loss. We asked why, and whether the gap is wider in Gulf operations, using public evidence only: ten surveys and three analyst forecasts published between July 2024 and August 2026, one agent benchmark, one Arabic dialect benchmark, and the dated record of Gulf AI strategies and data laws. Under the strictest definitions, between 5 and 12 percent of organisations report value from AI, and the Gulf sits close to the global figures: 11 percent of GCC organisations are value realizers in McKinsey's 2025 survey. The sources that study causes place them in implementation rather than in the models: integration, data, exceptions and ownership. Gulf operations add Arabic dialect, data residency law, scarce deployment talent, buying that runs on introductions, and work that still moves on paper and WhatsApp; the last is an observation, not a statistic. The evidence points to engineers inside the operation, one workflow at a time, a baseline on the company's own numbers and a person above set thresholds. ## Key findings 1. Under each survey's strictest definition, 5 to 12 percent of organisations report value from AI; looser definitions reach 26 to 40 percent, and none finds a majority. 2. The Gulf is not behind on adoption and is close to the global average on value: 84 percent of GCC organisations use AI, 11 percent are value realizers, and 39 percent are AI leaders in BCG's terms against 40 percent globally. 3. The sources that study causes place them in implementation, not the models: poor fit with workflows and systems, data that is not ready, inconsistent handling of exceptions, and no owner or measure once the pilot ends. 4. Gulf operations add frictions global surveys do not measure: Arabic dialect, data residency law, scarce deployment talent, introduction-led buying, and records on paper and WhatsApp, the last shown only indirectly. 5. The practices associated with reaching production recur across sources: builders inside the workflow, narrow scope, a measured baseline, and human approval above set limits; the evidence is correlational. ## 1. Introduction A pilot is easy to start. A model is called through an interface, a demonstration is built on a sample of documents, and a team sees something that looks like the work being done. The hard step is the one after: the system reads the live records, handles the case nobody planned for, writes back what it did, and is still running six months later because someone owns it and can show what it changed. Most enterprise AI does not take that step. Of the organisations in MIT NANDA's 2025 study, 60 percent had evaluated custom or vendor-built AI tools for their workflows and 5 percent had them in production [1]. In McKinsey's 2026 global survey, 37 percent of respondents attribute any EBIT (Earnings before interest and taxes, or operating profit. Surveys ask about it to learn whether AI shows up in the accounts, not only in individual productivity.) impact to AI, about the same share as a year earlier [2]. It matters more in the Gulf. Gulf leaders are among the most committed to AI anywhere: more than a third of Middle East CEOs in PwC's 2026 survey report integrating AI directly into their offerings, against fewer than one in five globally [3]. Yet the operations Qantara is built for, logistics, distribution, manufacturing and automotive, are the places where a pilot meets the most friction: documents in two scripts, approvals that can sit with the head of a family group, records that live on phones, and data that must stay in the country. Ambition is not the constraint. The distance between a pilot and the working day is. This report reads the public evidence on that distance and contributes four things: 1. A reading of ten surveys and three forecasts on the pilot gap, each number quoted as published, with its definition and date (Figures 1 and 2, Table 1). 2. An account of why operational work is harder for AI than conversation, from the causes those sources name and one agent benchmark. 3. The frictions specific to Gulf operations, separating what public sources show from what we observe (Figure 3, Table 2). 4. A mapping from causes to the remedies the evidence supports, and what follows for a Gulf company (Figure 4). ## 2. Background and related work Four kinds of public evidence describe the gap. The first is executive surveys run by consulting firms. McKinsey's global survey on the state of AI has asked about company use of AI for nearly a decade [2], and its 2025 GCC edition asks the same questions of Gulf organisations [4]. BCG surveyed 1,000 executives in 2024 and 1,250 in 2025 on their AI capabilities [5, 6], and published the GCC results of the 2025 survey in January 2026 [7]. PwC's annual CEO survey reached 4,454 chief executives in 2026 [8]. These surveys are large but self-reported, and each firm defines value its own way. The second is research that studies deployments directly. MIT NANDA's The GenAI Divide combines a review of more than 300 publicly disclosed AI initiatives, structured interviews with representatives of 52 organisations and 153 survey responses from senior leaders, collected from January to June 2025, and calls its findings preliminary [1]. Its headline, that 95 percent of organisations are getting zero return, travelled further than its caveats. We use its finer-grained numbers and quote its own limitations alongside them. The third is analyst forecasts, of which Gartner's are the most cited: at least 30 percent of generative AI projects abandoned after proof of concept (A small trial built to show that something can work, usually on sample data and outside the live systems. Passing one says little about running in production.) by the end of 2025 [9], 60 percent of AI projects unsupported by AI-ready data abandoned through 2026 [10], and over 40 percent of agentic AI projects cancelled by the end of 2027 [11]. These are predictions, not measurements. The first has passed its date, and we found no published count of whether it held. The fourth is benchmarks, which are narrower but more exact. τ-bench measures whether an agent completes customer-service tasks with tools and a simulated customer, and whether it does so consistently across repeated attempts [12]. AraDiCE measures how language models handle Arabic dialects and regional cultural knowledge, with a cultural benchmark covering the Gulf, Egypt and the Levant [13]. Neither measures a Gulf operation, but both measure properties an operation depends on. Gulf evidence is thinner. We found no survey of what happens to a pilot inside a mid-sized Gulf operating company, and none of how much of its work still runs on paper, calls and WhatsApp; where we describe that work, we call it an observation. ## 3. The pilot gap in the global evidence ### The funnel narrows at production MIT NANDA separates two kinds of tool. General-purpose models such as ChatGPT and Copilot were investigated by 80 percent of the organisations it studied, piloted by 50 percent and implemented by 40 percent. Embedded or task-specific tools, the kind that sit inside a workflow, were investigated by 60 percent, piloted by 20 percent and successfully implemented by 5 percent [1]. The report counts a tool as successfully implemented when users or executives describe a marked and sustained effect on productivity or profit and loss, and warns that its figures are directionally accurate, drawn from interviews rather than company reporting. **Figure 1. General tools reach use; tools inside a workflow rarely reach production** Each pair of bars is the share of organisations in the MIT study at one stage, for general-purpose models and for tools embedded in a specific task; read down the rows to see how many fall away. | | General-purpose models | Embedded or task-specific tools | | --- | --- | --- | | Investigated | 80 | 60 | | Piloted | 50 | 20 | | Successfully implemented | 40 | 5 | Source: MIT NANDA, The GenAI Divide: State of AI in Business 2025 (July 2025), exhibit on the drop from pilots to production, research period January to June 2025. The report describes these figures as directionally accurate, based on interviews. Read 14 October 2026. McKinsey's 2026 survey shows the same split from the other side. Chatbots are the most widely scaled AI tool, with 47 percent of respondents saying their organisations are scaling them across the enterprise; about two in ten say the same of AI agents [2]. Tools that answer scale readily. Tools that act inside a process scale far less often. ### Value is rarer than use Use is now close to universal: nearly nine in ten respondents to McKinsey's 2026 survey report regular use of AI in at least one function, and 44 percent say it is scaling across their enterprise, up from 38 percent [2]. Value has not kept pace. The share attributing any EBIT impact to AI is 37 percent, essentially unchanged from 2025, and high performers, who attribute at least 5 percent of EBIT to AI, are about 6 percent. PwC finds that 56 percent of CEOs have seen neither higher revenues nor lower costs from AI in the past year, and 12 percent have seen both [8]. BCG found 74 percent of companies yet to show tangible value from AI in 2024 [5], and in 2025 classed 60 percent as laggards reporting minimal revenue and cost gains, 35 percent as scalers and 5 percent as future-built [6]. **Figure 2. However value is defined, no survey finds a majority** Each bar is the share of surveyed organisations that meet one survey's own definition of getting value from AI, sorted from smallest to largest share; the definitions differ, so read the bars as a range, not a ranking. | | % of organisations surveyed | | --- | --- | | BCG 2025, global: future-built | 5 | | McKinsey 2026, global: high performers | 6 | | McKinsey 2025, GCC: value realizers | 11 | | PwC 2026, global CEOs: both revenue and cost gains | 12 | | BCG 2024, global: beyond proof of concept | 26 | | McKinsey 2026, global: any EBIT impact | 37 | | BCG 2026, GCC: AI leaders | 39 | | BCG 2025, global: future-built and scalers | 40 | Sources: BCG, The Widening AI Value Gap (30 September 2025) and its GCC results (28 January 2026); McKinsey, The state of AI in 2026 (25 August 2026) and The state of AI in GCC countries (13 November 2025); PwC, 29th Global CEO Survey (19 January 2026); BCG, Where's the Value in AI? (24 October 2024). GCC bars highlighted. The global BCG 2025 bar adds BCG's future-built (5%) and scaler (35%) shares, which BCG itself reports together as 40%. Read 14 October 2026. Table 1 sets out the headline numbers with their samples and definitions, because the definitions carry most of the difference between them. MIT's 95 percent and BCG's 74 percent are not in conflict: MIT measures return within six months of a pilot, BCG whether a company has built the capabilities to move beyond proofs of concept [1, 5]. **Table 1. Headline statistics on the pilot gap, as each source published them** | Source and date | Sample | What was measured | Figure | | --- | --- | --- | --- | | MIT NANDA, July 2025 | 52 interviews, 153 survey responses, 300+ public initiatives | Organisations with task-specific AI tools in production | 5% (60% evaluated) | | MIT NANDA, July 2025 | As above | Organisations getting zero return from generative AI | 95% | | McKinsey, August 2026 | 1,719 respondents in 97 nations, fielded 4 May to 8 June 2026 | Respondents attributing any impact on operating profit to AI | 37% | | McKinsey, August 2026 | As above | High performers: 5% or more of EBIT from AI, value called significant | About 6% | | McKinsey GCC, November 2025 | GCC organisations; sample size not given in the article text | Value realizers: scaling AI and 5% or more of earnings from it | 11% | | BCG, October 2024 | 1,000 executives in 59 countries | Companies yet to show tangible value from AI | 74% | | BCG, September 2025 | 1,250 executives and AI decision makers | Laggards with minimal revenue and cost gains | 60% | | BCG GCC, January 2026 | GCC organisations in BCG's 2025 survey | AI laggards (global: 60%) | 61% | | PwC, January 2026 | 4,454 CEOs in 95 countries and territories | CEOs reporting neither revenue nor cost benefit from AI | 56% | | Gartner, July 2024 | Forecast | Generative AI projects abandoned after proof of concept by end of 2025 | At least 30% | | Gartner, February 2025 | Forecast; survey of 1,203 data management leaders | AI projects without AI-ready data abandoned through 2026 | 60% | | Gartner, June 2025 | Forecast; poll of 3,412 webinar attendees | Agentic AI projects cancelled by end of 2027 | Over 40% | Survey figures are self-reported. Gartner figures are predictions. All sources read on 14 October 2026. Beneath the different definitions, three findings are consistent. Adoption is no longer the constraint. The loss happens at the step from pilot to production. And the organisations that make the step differ in how they deploy more than in what they buy: nearly three-quarters of McKinsey's high performers report fundamentally redesigning workflows around AI, against one quarter of other respondents, and they are twice as likely to have defined processes to measure the impact of their AI initiatives [2]. BCG put the same point as a budget rule in 2024: its leaders put 10 percent of their resources into algorithms, 20 percent into technology and data, and 70 percent into people and processes [5]. ### What the forecasts add Gartner's forecasts name reasons the surveys imply: generative AI projects abandoned for poor data quality, inadequate risk controls, escalating costs or unclear business value, with some deployment approaches costing $5 million to $20 million [9]. Agentic AI projects would be cancelled for escalating costs, unclear business value or inadequate risk controls, with many vendors engaged in agent washing (Gartner's term for relabelling existing chatbots, assistants or robotic process automation as agents without adding the ability to act and decide.); Gartner estimates only about 130 of the thousands of agentic AI vendors are real, and warns that integrating agents into legacy systems often disrupts workflows and requires costly modifications [11]. Together they describe projects that are cheap to start, expensive to finish, and hard to justify without a number agreed in advance. ## 4. Why operations are harder than chat A conversation with a model ends when the person asking is satisfied. An operational task ends when the order is in the ERP, the customer has been told, the exception has been handled, and someone can show what happened and why. The sources above name four reasons the second is harder. ### Integration In MIT NANDA's interviews, professionals who praised consumer chat tools called custom and vendor AI tools brittle, overengineered or misaligned with actual workflows, and buyers ranked minimal disruption to current tools among their selection criteria [1]. Gartner makes the same point about agents and legacy systems [11]. In an operation, integration means reading from and writing to the ERP, the shared mailbox, the messaging channel and the call log, under credentials scoped to the job, with a trace of every read and write. ### Data Gartner's 2024 survey of 1,203 data management leaders found 63 percent of organisations either lack, or are unsure they have, the right data management practices for AI [10]. In McKinsey's GCC survey, 53 percent of respondents named output inaccuracy as one of the most significant barriers to adoption, and the report discusses it under data integrity: poor data quality, missing values, bias and outliers [4]. The same report calls for data that captures conversations, case history and workflow state, and records how decisions were made. That is the data an operation tends not to keep: why a discount was given, why a delivery was short, who agreed to a new date. ### Exceptions Much operational work is exceptions: a short delivery, a customer over their credit limit, a supplier who moved a date in a voice note. In τ-bench, state-of-the-art function-calling agents such as gpt-4o succeeded on fewer than half of the tasks, and their pass^k (The share of tasks an agent completes correctly in every one of k repeated attempts. It measures consistency, which matters more in operations than one good attempt.) at k = 8 fell below 25 percent in the retail domain [12]. Models have improved since 2024, so the number dates; the metric does not. An operation needs an agent that is right on the same kind of case every time. MIT NANDA's respondents describe the same problem: tools that break on edge cases, need context re-entered each time, and do not learn from feedback [1]. ### Ownership A pilot built by an innovation team often has nobody in the operation who runs it once the team moves on. MIT NANDA found that the organisations crossing the gap decentralise implementation authority but keep accountability, and that many of the strongest deployments were sourced from frontline managers rather than central labs [1]. In McKinsey's GCC interviews, a chief AI officer described the rule plainly: every use case needs a clear definition of success, and if it succeeds it moves to the business team, which then owns it [4]. Without that handover, a working pilot becomes an unowned system, switched off at its first error. ## 5. The Gulf specifics On adoption, the Gulf is not behind. In McKinsey's GCC survey, 84 percent of organisations had adopted AI in at least one business function, up from 62 percent in 2023 and four points below the global figure, and 60 percent said they were using AI agents to some extent [4]. Employees use AI more than their global peers: 87 percent of GCC respondents in BCG's 2025 AI at Work survey use AI tools at work at least several times a week, against 72 percent globally, and 63 percent would use them without company authorisation [14]. On value, the Gulf is close to the global figures, and the gap opens in the same place. Only 31 percent of McKinsey's GCC respondents said AI was being scaled or had been fully deployed across the organisation, more than two-thirds had not moved beyond pilots, and 11 percent were value realizers [4]. BCG counts 39 percent of GCC organisations as AI leaders against 40 percent globally, but reports that the maturity of GCC operations capabilities declined compared with 2024 and that the enablers, technology, data, operating model and people, still lag [7]. The Gulf pilots readily, and its pilots stall where everyone's do, in the operating core, where the regional context adds frictions the global surveys do not measure. ### Arabic and dialect The text an operation produces in the Gulf is rarely Modern Standard Arabic alone. As an illustrative example, written by us: a branch manager sends a photograph of a delivery note printed in English, with a shortage written in Arabic in the margin, followed by a WhatsApp message in Gulf dialect that switches to English for the product code, and a voice note from the driver. Some of it may be in Arabizi (Arabic written in Latin letters, with digits such as 3 and 7 standing for Arabic sounds that have no Latin letter.). On public benchmarks, Arabic-specific models outperform multilingual ones on dialect tasks, but significant challenges persist in dialect identification, generation and translation [13]. A pilot tested on clean Modern Standard Arabic or English samples can pass its demonstration and then fail on the live channel. ### Data residency Oman's Personal Data Protection Law, issued by Royal Decree 6/2022, came into force on 13 February 2023 and provides fines of up to OMR 500,000 for the unlawful transfer of personal data outside Oman [15]. Saudi Arabia's law took effect on 14 September 2023 and became fully enforceable a year later; where no adequacy decision applies, transfers abroad rely on standard contractual clauses, binding corporate rules or a certificate of accreditation, with a risk assessment [16]. A pilot on a foreign cloud with sample data never meets these rules. Production with customer records does, and raises a question a pilot can ignore: where the model that reads the data runs, which may differ from where the data is stored. ### Talent The people who carry a pilot into production are scarce everywhere. McKinsey's GCC report names forward-deployed engineers (Engineers who work inside one customer's operation and build what that customer needs, rather than building one product feature for many customers.), context engineers and AI product owners as emerging roles for which relatively few people qualify [4]. In Oman the constraint is also legal and deliberate: Ministerial Decision 501/2024 reserves the professions of computer programmer, computer engineer and computer operator for Omanis from 1 January 2026, and website designer and operations analyst from 1 January 2027 [17]. For a team that writes software in Muscat, that is one more reason to build and train the capability locally, around Omani engineers, rather than fly it in. ### Introductions and family groups The US government's commercial guide to Oman states that regular personal contact and familiarity with business partners are key to doing business there [18]. The pattern is not only regional. MIT NANDA found that referrals, prior relationships and introductions from investors predict enterprise adoption better than functionality does; the leaders it surveyed found AI vendors through existing vendor partnerships (20 percent), new integrations or partner referrals (15 percent), informal peer recommendations (13 percent) and board or adviser referrals (10 percent) [1]. Much of the Gulf's private economy sits inside family groups: a frequently repeated estimate, cited by the Atlantic Council in 2021, puts family-owned businesses at about 60 percent of GCC GDP, a figure we could not trace to primary statistics and use only as an order of magnitude [19]. The consequence for a pilot is specific. It is often approved at the top, through an introduction, and arrives in an operation whose managers did not ask for it: the ownership problem above, in its regional form. ### Paper, phone and WhatsApp No public survey we found measures how much Gulf operational work runs on paper, calls and WhatsApp; the public record shows it only indirectly. When Saudi Arabia's first phase of e-invoicing came into force on 4 December 2021, the tax authority required taxpayers to stop issuing handwritten invoices altogether, an indirect sign that some still did [20]. Saudi Arabia's communications regulator, in its Saudi Internet 2025 report, lists WhatsApp as the most used social media application in the Kingdom, at 92.7 percent, and above 96 percent among users aged 30 to 59 [21]. That shortages are reported, deliveries moved and approvals given on WhatsApp and on calls that leave no record is our observation, the one our thesis starts from, not a measured share. Its consequence is plain, though: a pilot that reads only the ERP misses the part of the operation that never reached it. ### Ambition set from the top Every Gulf government in this report has published a national AI strategy or programme, most under a national vision (Figure 3). Saudi Vision 2030 was approved in April 2016 [22]. The UAE announced its National Strategy for AI in October 2017 [23], Qatar launched its National Artificial Intelligence Strategy in October 2019 [24], and Saudi Arabia its National Strategy for Data and AI in October 2020 [25]. Oman Vision 2040 came into effect in January 2021 [26], and Oman's National Program for Artificial Intelligence and Advanced Digital Technologies, for 2024 to 2026, was launched in September 2024 [27]. The expected prize is large: PwC estimated in 2018 that AI could add $320 billion to the Middle East economy by 2030, 11 percent of GDP, with 12.4 percent for Saudi Arabia, almost 14 percent for the UAE and 8.2 percent for Bahrain, Kuwait, Oman and Qatar together [28]. The strategies set the direction; the gap they leave lies between national ambition and the delivery note on the tailgate. **Figure 3. A decade of Gulf national AI strategies** Read top to bottom: each entry is the date a national vision, AI strategy or AI programme was approved, announced or launched, as reported at the time. - 25 Apr 2016: Saudi Vision 2030 approved. The national reform plan, approved by King Salman and the cabinet. - Oct 2017: UAE National Strategy for AI announced. The strategy for 2031, run by the UAE AI Office. - 29 Oct 2019: Qatar National Artificial Intelligence Strategy launched. Announced at the Qatar IT conference; prepared by the Qatar Computing Research Institute; six pillars. - 21 Oct 2020: Saudi National Strategy for Data and AI launched. Launched by the Saudi Data and AI Authority at the first Global AI Summit, with 2030 targets. - Jan 2021: Oman Vision 2040 comes into effect. Carried out through four five-year plans, starting with the tenth plan for 2021 to 2025. - 2022: Oman executive programme for AI. The Executive Program for Artificial Intelligence and Advanced Technologies. - Sep 2024: Oman National Program for AI and Advanced Digital Technologies. Runs from 2024 to 2026 under Oman Vision 2040: adoption, localisation and governance. Sources: Argaam (25 April 2016; 21 October 2020); OECD.AI Policy Navigator entry for the UAE strategy; Gulf Times (29 October 2019); Oman Observer (9 January 2021); Telecom Review (23 September 2024). Some sources date the formal adoption of the UAE strategy document to 2019. Read 14 October 2026. **Table 2. What Gulf operations add to the pilot gap** | Friction | What public sources show | Evidence type | What it changes in a deployment | | --- | --- | --- | --- | | Arabic and dialect | Dialect identification, generation and translation remain hard for current models | Peer-reviewed benchmark (2025) | Evaluate on the live channel's language, not on clean samples | | Data residency | Oman's law in force since February 2023; Saudi Arabia's enforceable since September 2024; transfers abroad need paper | Law, via law-firm summaries | Decide where data is stored and where each model runs before building | | Talent | Deployment roles scarce; in Oman, programming and computer engineering reserved for Omanis from January 2026 | Survey (2025); ministerial decision (2024) | Build and train the team locally | | Introductions | Personal contact is key to business in Oman; referrals predict adoption globally | Government guide (2025); research report (2025) | Expect approval at the top; name an operational owner early | | Family groups | About 60% of GCC GDP attributed to family businesses | Secondary estimate, untraced | A workflow proven in one group company can be carried to the next | | Paper and WhatsApp | Handwritten invoices common enough to be banned in 2021; WhatsApp used by 92.7% in Saudi Arabia | Regulator texts (2021, 2026); the operational share is our observation | Read photos, messages and voice notes, not only the ERP | Sources as cited in this section. Read 14 October 2026. ## 6. What the evidence says works The sources that study the minority that makes the step describe four recurring practices. The evidence is correlational, as MIT NANDA says of its own build-or-buy result [1]. ### Builders inside the operation In MIT NANDA's sample, external partnerships with customised, learning-capable tools reached deployment about 67 percent of the time, against about 33 percent for tools built internally. The buyers who succeeded treated AI vendors less like software suppliers and more like business service providers: they demanded deep customisation, benchmarked tools on operational outcomes rather than model scores, and stayed with the partner through early failures [1]. Palantir described its forward-deployed engineers in 2019 as focused on one customer and many capabilities, where a product engineer builds one capability for many customers [29]. McKinsey's GCC report lists the role among those the region now needs and lacks [4]. The common element is where the work happens: inside the customer's workflow, with the people who run it. ### One workflow, end to end The successful builders in MIT NANDA's research started with narrow, high-value workflows and expanded from there; simple, narrow work such as spend categorisation and contract review produced fast wins, while full procurement orchestration failed. The top-performing mid-market companies averaged 90 days from pilot to full implementation, against nine months or more for large enterprises [1]. Gartner advises pursuing agents only where they deliver clear value, and rethinking the workflow rather than attaching an agent to it [11]. One workflow end to end means from the message that starts it to the entry that closes it, with its exceptions included, rather than one step of many workflows. ### A baseline on the company's own numbers Value that is not measured is not seen, and value that is not seen is cancelled. Unclear business value is among the reasons in Gartner's forecasts for both generative and agentic AI projects, and Gartner notes that productivity gains are hard to translate into financial benefit [9]. McKinsey's high performers are twice as likely as others to have defined processes for measuring the impact of their AI initiatives [2]. McKinsey's GCC interviewees recommend tying each deployment to measurable indicators such as cost savings, revenue uplift or cycle time [4]. The practical form is a baseline (A measurement of how a process performs before any change, taken from the company's own records, so that any later result can be checked against it.) taken before anything is built: days to collect, hours from order to dispatch, the share of invoices corrected after issue. MIT NANDA observed that budgets favour sales and marketing partly because their results are easy to measure, while the back office, where some of the clearest savings appeared, is not [1]; a baseline removes that disadvantage. ### A person above thresholds GCC respondents to BCG's 2025 survey named decisions taken without human oversight and unclear accountability for mistakes among the potential risks of AI agents [14]. In a Harris Poll survey for Dataiku, 94 percent of UAE data leaders said they lack full visibility into how AI systems make decisions, and half had delayed or blocked the deployment of an AI agent over explainability [30]. McKinsey's 2026 report lists human-in-the-loop design among the practices that set its high performers apart [2], and Gartner names inadequate risk controls among the reasons agentic projects will be cancelled [11]. The operational answer is a threshold the owner sets, by amount, customer, country or hour, below which the agent acts and above which a person approves, with every action written to a log before anyone asks to see it. Given the consistency results above, this is the condition under which an agent that is right most of the time can be trusted with the rest. **Figure 4. Which practice addresses which cause** Each row is a cause of stalled pilots named in the sources; each column is a practice; yes means the practice addresses the cause directly, partial means it helps without settling it, no means it does not touch it. | | Engineers inside the operation | One workflow end to end | Baseline on own numbers | Person above thresholds | Data location stated per workflow | | --- | --- | --- | --- | --- | --- | | Tools that do not fit the workflow or its systems | yes | yes | no | no | no | | Data that is not ready | yes | partial | partial | no | no | | Inconsistent handling of exceptions | partial | yes | partial | yes | no | | No owner after the pilot | partial | yes | yes | partial | no | | Value not measured | no | partial | yes | no | no | | Distrust of decisions nobody can trace | partial | no | partial | yes | partial | | Arabic dialect on live channels | yes | partial | no | partial | no | | Data residency law | partial | no | no | no | yes | Qantara's mapping, not a measured result. Causes as named by MIT NANDA (2025), Gartner (2024, 2025), McKinsey (2025, 2026), BCG (2025), Dataiku (2025), Yao et al. (2024) and Mousi et al. (2025); practices as described in this section. Read 14 October 2026. ## 7. Implications for deployment For a Gulf company, the evidence translates into decisions to make before anything is built, not after the pilot. 1. Choose one workflow whose result shows in a number the company already tracks, such as days to collect or hours from order to dispatch. 2. Record the baseline on the company's own records before work starts, and agree in writing what change would count as success. 3. Test the agent on the company's past cases, exceptions included, and measure whether it is right on the same kind of case every time. 4. Set the thresholds, and who approves above them, before the agent goes live; widen them only when results hold. 5. Put residency in writing: where the record and its log are kept, which model reads what, and where that model runs. 6. Name the person in the operation who will run the workflow once the engineers step back. 7. Evaluate on the channels the work arrives on: Arabic and English, photographs of documents, voice notes and WhatsApp messages. This is how Qantara, based in Muscat and working across the Gulf, approaches a deployment; it is our method, not a result we report. Named engineers work on site inside the customer's operation, write down how the work really runs, record a baseline and stay until the team runs it. Agents work inside the customer's own systems, the ERP, WhatsApp and email, in Arabic and English on the same document, message and call, and every agent writes to one operating record of how the company runs. Each agent is run on the customer's past cases before it goes live, with the customer's team marking what good looks like. The customer sets the thresholds, and above them a person approves. The record and its log are kept in the customer's country, and for each workflow we state in writing which model reads what and where it runs. Through partners, AI built in Silicon Valley is deployed inside Gulf companies. ## 8. Limitations Most of the evidence is self-reported, and each firm defines value differently, which is why Figure 2 is a range rather than a ranking. The large samples skew towards large companies: 36 percent of McKinsey's 2026 respondents work for organisations with more than $1 billion in revenue [2]. The GCC samples are smaller; in McKinsey's GCC survey, 13 respondents from value-realizing organisations answered the question on capabilities [4]. MIT NANDA's study is preliminary and interview-based. It warns that its success definitions vary between organisations, that a six-month window may understate success for complex systems, and that its build-or-buy gap may reflect the organisations rather than the approach [1]. Gartner's figures are forecasts, and the one whose date has passed has not, to our knowledge, been checked. τ-bench dates from 2024, and AraDiCE's dialect sets are machine-translated and post-edited, not messages written by Gulf staff. The Gulf evidence has specific gaps: no public measurement of pilot-to-production rates in Gulf mid-market companies, no primary source for the family-business share of GDP, and no measurement of how much operational work runs on paper and WhatsApp. The data-law summaries come from law firms, not the official texts, and we read sources in English only. The practices in the previous section are associated with success, not shown to cause it. Three kinds of evidence would change these conclusions: a Gulf survey that measures production rather than adoption; controlled comparisons in which internal builds reach production as often as partnered ones; and a measurement of how Gulf operations record their work, which could show less of it on paper and WhatsApp than we observe. ## 9. Conclusion The public evidence agrees on the shape of the problem even where its numbers differ. Use of AI is close to universal, value is reported by a minority under any definition, and the loss happens between the pilot and production. The Gulf adopts quickly, reports value at about the global rate, and stalls in the same place, the operating core, where dialect, residency law, scarce talent, introductions and records on phones make a demonstration a poor guide to the working day. What the evidence supports is unglamorous. Put builders inside the operation, take one workflow from start to finish, measure it against the company's own baseline, and keep a person above the limits the owner sets. None of these depends on a better model. Each depends on someone being there, on site, when the work begins. ## References [1] Challapally, A., Pease, C., Raskar, R., et al. (2025). The GenAI Divide: State of AI in Business 2025. Project NANDA, MIT, preliminary report, July 2025. https://www.artificialintelligence-news.com/wp-content/uploads/2025/08/ai_report_2025.pdf (accessed 14 October 2026) [2] Tinkoff, D., Van der Veken, L., Chui, M., et al. (2026). The state of AI in 2026: On the road to ROI. McKinsey & Company, survey, 25 August 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai (accessed 14 October 2026) [3] PwC Middle East (2026). 88% of CEOs in the Middle East confident in growth: PwC's 29th Global CEO Survey, Middle East findings. PwC Middle East press release, Riyadh, 20 January 2026. https://www.pwc.com/m1/en/media-centre/2026/middle-east-29-ceo-survey.html (accessed 14 October 2026) [4] Alatovic, T., Isherwood, T., Chandran, V., et al. (2025). The state of AI in GCC countries: In pursuit of scale and value. McKinsey & Company, survey, 13 November 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-in-gcc-countries-in-pursuit-of-scale-and-value (accessed 14 October 2026) [5] Boston Consulting Group (2024). AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value. BCG press release on the report Where's the Value in AI?, 24 October 2024. https://www.bcg.com/press/24october2024-ai-adoption-in-2024-74-of-companies-struggle-to-achieve-and-scale-value (accessed 14 October 2026) [6] Boston Consulting Group (2025). AI Leaders Outpace Laggards with Double the Revenue Growth and 40% More Cost Savings. BCG press release on the report The Widening AI Value Gap: Build for the Future 2025, 30 September 2025. https://www.bcg.com/press/30september2025-ai-leaders-outpace-laggards-revenue-growth-cost-savings (accessed 14 October 2026) [7] Mourtada, R., Littig, L., Schetinin, S., et al. (2026). Unlocking Potential: How GCC Organizations Can Convert AI Momentum into Value at Scale. Boston Consulting Group, 28 January 2026. https://www.bcg.com/publications/2026/unlocking-potential-how-gcc-organizations-can-convert-ai-momentum-into-value-at-scale (accessed 14 October 2026) [8] PwC (2026). PwC's 29th Global CEO Survey: Leading through uncertainty in the age of AI. PwC, 19 January 2026. https://www.pwc.com/gx/en/issues/c-suite-insights/ceo-survey.html (accessed 14 October 2026) [9] Gartner (2024). Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025. Gartner press release, Sydney, 29 July 2024. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025 (accessed 14 October 2026) [10] Gartner (2025). Lack of AI-Ready Data Puts AI Projects at Risk. Gartner newsroom, Q&A with R. Edjlali, 26 February 2025. https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk (accessed 14 October 2026) [11] Gartner (2025). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Gartner press release, Sydney, 25 June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027 (accessed 14 October 2026) [12] Yao, S., Shinn, N., Razavi, P., et al. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045. https://arxiv.org/abs/2406.12045 [13] Mousi, B., Durrani, N., Ahmad, F., et al. (2025). AraDiCE: Benchmarks for Dialectal and Cultural Capabilities in LLMs. Proceedings of COLING 2025, pages 4186-4218. https://aclanthology.org/2025.coling-main.283/ [14] Littig, L., Mourtada, R. and Bollettino, E. (2025). From Pilots to Progress: AI at Work in the GCC. Boston Consulting Group, 25 September 2025. https://www.bcg.com/publications/2025/ai-at-work-gcc-pilots-to-progress (accessed 14 October 2026) [15] Clyde & Co (2022). Data Protection Law issued in Oman. Clyde & Co insights, 15 February 2022. https://www.clydeco.com/en/insights/2022/2/data-protection-law-issued-in-oman (accessed 14 October 2026) [16] Clyde & Co (2024). Saudi Arabia's Personal Data Protection Law becomes enforceable: essential insights for businesses. Clyde & Co insights, 10 September 2024. https://www.clydeco.com/en/insights/2024/09/saudi-arabia-s-personal-data-protection-law-become (accessed 14 October 2026) [17] Times of Oman (2024). Ministry of Labour lists 32 new professions to be reserved for Omanis. Times of Oman, 6 September 2024. https://timesofoman.com/article/149542-ministry-of-labour-lists-32-new-professions-to-be-reserved-for-omanis (accessed 14 October 2026) [18] International Trade Administration, US Department of Commerce (2025). Oman: Business Travel, Country Commercial Guide. trade.gov, last published 18 December 2025. https://www.trade.gov/country-commercial-guides/oman-business-travel (accessed 14 October 2026) [19] Ahmad, A. and El Agamy, F. F. (2021). Family businesses in the Gulf must not be left behind. Atlantic Council, MENASource, 31 March 2021. https://www.atlanticcouncil.org/blogs/menasource/family-businesses-in-the-gulf-must-not-be-left-behind/ (accessed 14 October 2026) [20] Zakat, Tax and Customs Authority (2021). First Phase of E-invoicing Enters into Force. ZATCA news, 4 December 2021. https://zatca.gov.sa/en/MediaCenter/News/Pages/E-invoicing-Enter-Into-Force.aspx (accessed 14 October 2026) [21] Communications, Space and Technology Commission (2026). Saudi Internet 2025. Communications, Space and Technology Commission, Kingdom of Saudi Arabia, 18 July 2026. https://www.cst.gov.sa/en/knowledge-center/reports/saudi-internet-25 (accessed 14 October 2026) [22] Argaam (2016). King Salman approves 'Vision 2030' reform plan. Argaam, 25 April 2016. https://www.argaam.com/en/article/articledetail/id/423373 (accessed 14 October 2026) [23] Organisation for Economic Co-operation and Development (2017). UAE National Strategy for AI. OECD.AI Policy Navigator, initiative entry, strategy announced October 2017. https://oecd.ai/en/dashboards/policy-initiatives/uae-national-strategy-for-ai-8711 (accessed 14 October 2026) [24] Gulf Times (2019). Qatar launches strategy to tap AI for future. Gulf Times, 29 October 2019. https://www.gulf-times.com/story/645930/qatar-launches-strategy-to-tap-ai-for-future (accessed 14 October 2026) [25] Argaam (2020). Saudi Arabia rolls out national strategy for data, artificial intelligence. Argaam, 21 October 2020. https://www.argaam.com/en/article/articledetail/id/1415333 (accessed 14 October 2026) [26] Oman Observer (2021). New Renaissance begins. Oman Observer, 9 January 2021. https://www.omanobserver.om/ampArticle/5328 (accessed 14 October 2026) [27] Telecom Review (2024). Oman launches national AI and advanced digital technologies program. Telecom Review, 23 September 2024. https://telecomreview.com/articles/reports-and-coverage/8411-oman-launches-national-ai-and-advanced-digital-technologies-program (accessed 14 October 2026) [28] Oman Observer (2018). AI could contribute $320 billion to ME economy in 2030: PwC. Oman Observer, 21 February 2018, reporting PwC Middle East's report US$320 billion by 2030?. https://www.omanobserver.om/ampArticle/61982 (accessed 14 October 2026) [29] Palantir (2019). Dev versus Delta: Demystifying engineering roles at Palantir. Palantir Blog, 8 April 2019. https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87 (accessed 14 October 2026) [30] Intelligent CIO Middle East (2025). 94% of UAE data leaders admit they can't fully trace AI decisions, reveals new Dataiku AI Confessions Report. Intelligent CIO Middle East, 11 November 2025, reporting a Harris Poll survey for Dataiku. https://www.intelligentcio.com/me/?p=134793 (accessed 14 October 2026) ## Cite this paper ```bibtex @techreport{qantara2026pilottoproduction, title = {From pilot to production: why AI stalls in Gulf operations}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/pilot-to-production} } ``` ## Disclosure Every number in this report is quoted from a cited public source, read on 14 October 2026; the only arithmetic is the global BCG 2025 bar in Figure 2, which adds two shares BCG itself reports together. The cause-and-remedy mapping in Figure 4, the description of Gulf operational work on paper and WhatsApp, and the delivery-note example are ours: the first is analysis, the second an observation and the third illustrative. Qantara's approach is described as method, not as results. Canonical: https://qantara.systems/insights/pilot-to-production --- # AI and personal data in the GCC: a country-by-country guide Guide. Qantara Research, Qantara. 14 October 2026. 19 min read. > What each Gulf data protection regime asks before an AI agent reads personal data: the law and its dates, the regulator, the lawful bases, the rules for sending data abroad, the breach clock, and where the cloud and the model actually run. ## Abstract A Gulf company that puts AI agents on its operational data, its orders, invoices, delivery notes and customer messages, puts personal data in front of a model. We asked what the data protection regimes of the six Gulf Cooperation Council states require before that happens, and what in-country cloud can and cannot promise. We read the laws and the regulators' own texts where we could open them, law-firm summaries where we could not, and the four large cloud providers' own region and model documentation, all as of 14 October 2026. Five states have a general data protection law in force; Kuwait's privacy regulation covers only licensed telecom and internet providers. Consent is central everywhere, but transfer rules diverge, from Oman's explicit consent to Qatar's presumption that data may flow, and breach clocks run from 24 to 72 hours. Public cloud regions exist in Saudi Arabia, the UAE, Qatar and Bahrain, and Oracle runs dedicated regions in Oman, but the frontier models offered in Gulf regions are documented as able to run abroad. Where data is stored and where the model reads it are separate questions, each needing a written answer. This guide is not legal advice. ## Key findings 1. Five of the six Gulf states have a general personal data law in force, Oman's fully enforceable since 5 February 2026; Kuwait's privacy regulation covers only licensed telecom and internet providers, and the UAE's federal law still awaits the executive regulations that its own Article 28 required within six months of its issue in September 2021. 2. Consent is central in every regime, but the rules for sending data abroad diverge the most: Oman's Executive Regulation asks for the data subject's explicit consent before a transfer, Saudi Arabia requires a safeguard and a risk assessment because no adequacy list has been published, the UAE and Bahrain combine adequacy with listed alternatives, and Qatar forbids controllers to restrict cross-border flows unless the processing breaks the law. 3. Breach clocks run from 24 hours for Kuwait's licensees to 72 hours in Oman, Saudi Arabia, Qatar's guideline, Bahrain and Abu Dhabi Global Market, while the UAE federal law and the Dubai International Financial Centre set no fixed number of hours. 4. Public regions of AWS, Microsoft Azure, Google Cloud or Oracle exist in Saudi Arabia, the UAE, Qatar and Bahrain, with Microsoft's and AWS's first Saudi regions due in the last quarter of 2026; Oman has two Oracle dedicated regions rather than a public one, and Kuwait has none. 5. A region in the country settles where data is stored, not where the model reads it: the providers' own documentation offers frontier models in Gulf regions through global routing, so the place of inference must be stated per model and per workflow, in writing. ## 1. Introduction An AI agent inside a company's operations reads what its people read: a WhatsApp order with a buyer's name and number, a delivery note signed by a driver, an invoice addressed to a contractor. Much of that is personal data under Gulf law, so the agent faces the questions asked of any new system: on what basis the data is processed, where it is stored, whether it leaves the country, and what happens if it leaks. It adds one that older systems rarely raised: where the model that reads the data runs. The answers moved in 2026. Oman's law became fully enforceable on 5 February 2026 [1]. Saudi Arabia, enforcing its law since September 2024 with 48 penalty decisions in 2025 by one vendor's count [2], opened consultation on 6 October 2026 on a draft that would require personal data to be stored in the Kingdom [3]. The UAE announced a federal authority for AI and data in June 2026, with its federal law's executive regulations still unissued [4]. Microsoft and AWS say their first Saudi cloud regions open in the last quarter of 2026 [5, 6]. A Gulf operating company rarely sits under one law. A distributor in Muscat sells to hotels in Dubai; a logistics group in Riyadh runs a hub in Bahrain. Six states, two UAE financial free zones with laws of their own and the Qatar Financial Centre give such a group up to nine rulebooks, and each answers the agent's questions differently. This guide contributes four things: 1. A dated reading of each regime: the instrument and its dates, the regulator, the lawful bases, transfer abroad, the breach clock and the sector rules worth knowing (sections 3 and 4). 2. A one-screen comparison of eight regimes on five questions (Figure 2). 3. A dated table of in-country cloud regions by provider, and a table of where the providers say a model's inference runs when called from a Gulf region (Tables 1 and 2). 4. Five questions to answer in writing before an agent reads personal data (Figure 3). **Not legal advice** This guide describes the law as we read it on 14 October 2026. It is not legal advice, and Gulf data rules and cloud regions changed several times in 2026 alone. Take advice from counsel licensed in each country before relying on any part of it. ## 2. Background and related work Gulf data protection law is young. Qatar's law of November 2016 is the oldest of the six states' instruments [7], and the others followed between 2018 and 2024. They resemble the European approach: lawful bases, rights for the person the data is about, duties for the controller (The party that decides why and how personal data is processed. A company putting an agent on its own customer records is usually the controller; a vendor running the agent on its instructions is usually a processor.) and its processors, breach notification, and conditions on sending data abroad. They differ in the details that matter most to an operating company. Two kinds of work cover this ground. Law-firm compendia describe each country in a common template, DLA Piper's Data Protection Laws of the World [8] and the Chambers practice guides [9] the most complete among them, and law-firm notes track instruments as they appear [1, 3, 10]. Separately, the cloud providers document their regions, and the routing of model requests, for engineers [11, 12]. Neither joins the two halves. The legal guides answer whether personal data may leave a country and under what paper; the cloud documentation answers where a request is processed. For an agent the second answer feeds the first: if the model that reads a customer's message runs abroad, the message has travelled, whichever region the database sits in. ### How we read the sources On 14 October 2026 we read the primary text wherever we could open it: Oman's law in English translation and its Executive Regulation in Arabic [13, 14], the UAE's federal decree-law on the government's legislation portal [15], Qatar's law and its regulator's breach guideline [7, 16], and Saudi Arabia's Essential Cybersecurity Controls [17]. SDAIA's website rejected our automated requests for the Saudi texts and the Bahraini authority's denied access, so for Saudi Arabia, Bahrain, Kuwait and the two UAE free zones we rely on law-firm, vendor and practice-guide summaries, marked as such in the references. For cloud regions and model routing we read only the providers' own pages. ## 3. The laws in order Figure 1 sets the instruments in the order they took effect. Enforcement arrived years after enactment: Oman's law was issued in February 2022 and fully enforceable four years later, Saudi Arabia's issued in September 2021 and enforced from September 2024 [13, 1, 8]. And the calendar is still moving, as the last four entries show. **Figure 1. Gulf personal data rules, from issue to enforcement** Read down: each line is one instrument taking effect, or one step in its enforcement, in date order. - Nov 2016: Qatar issues Law No. 13 of 2016. Issued 3 November 2016; in force in 2017, with six months to comply. - Aug 2019: Bahrain's Law No. 30 of 2018 in force. 1 August 2019; ten resolutions followed on 17 March 2022. - Jul 2020: Dubai International Financial Centre: Law No. 5 of 2020 in force - Feb 2021: Abu Dhabi Global Market issues its Data Protection Regulations 2021 - Jan 2022: UAE Federal Decree-Law No. 45 of 2021 in force. 2 January 2022; its executive regulations were still not issued in October 2026. - Feb 2023: Oman's Royal Decree 6/2022 in force. One year after its issue on 9 February 2022. - Sep 2023: Saudi Arabia's PDPL in force. 14 September 2023, with a year to comply; the transfer regulation was first published on 7 September 2023. - Feb 2024: Oman's Executive Regulation takes effect. Ministerial Decision 34/2024, published 4 February 2024, with a year to comply. - Feb 2024: Kuwait repeals its data classification policy. Privacy rules apply only to telecom and internet licensees (Decision No. 26 of 2024). - Sep 2024: Saudi Arabia: grace period ends. Enforced from 14 September 2024; transfer regulation updated on 1 September 2024. - Feb 2026: Oman: transition ends. Fully enforceable from 5 February 2026, after an extension by Ministerial Decision 6/2025. - Feb 2026: Saudi Arabia: rules for certificates of accreditation. 17 February 2026; a third safeguard for transfers abroad. - Jun 2026: UAE announces a Federal Authority for AI and Data. 14 June 2026; it absorbs the UAE Data Office. - Oct 2026: Saudi Arabia consults on storing personal data in the Kingdom. Draft amendments, open 6 October to 5 November 2026; not law. Qantara, compiled from the laws' texts and the law-firm summaries cited in section 4, read 14 October 2026. Months are given where sources differ on the day. ## 4. Country by country Each entry follows the same order: the law and its dates, the regulator, the lawful bases, transfer abroad, the breach clock, and sector rules worth knowing. ### Oman The newest law to reach full enforcement, and the strictest on transfer: the data subject's explicit consent is the main basis for processing and, under the Executive Regulation, for sending data abroad. - Law and dates. Royal Decree 6/2022, issued 9 February 2022 and published in Official Gazette 1429 on 13 February, came into force a year after issue [13]. The Executive Regulation, Ministerial Decision 34/2024, was published on 4 February 2024 and took effect the next day with a year to comply [14]; Ministerial Decision 6/2025 extended the transition to 5 February 2026 [1]. One law-firm note dates the regulation from 29 January 2024 [18]. - Regulator. The Ministry of Transport, Communications and Information Technology (Articles 1 and 7) [13]. - Lawful bases. Processing requires the data subject's explicit consent (Article 10); Article 3 takes some processing, such as performing a contract with the data subject, outside the law; and genetic, biometric, health and other sensitive data need a Ministry permit (Article 5) [13]. CMS notes it is unclear whether the Article 3 exclusions work as lawful bases [1]. - Transfer abroad. Allowed under the Regulation's procedures, never for data processed in breach of the law (Article 23) [13]. The Regulation requires the data subject's explicit consent before a transfer, unless a treaty requires it or the data is anonymised (Article 37), and protection abroad no lower than Oman's (Article 38) [14]. There is no adequacy list, no set of standard clauses and no prior approval [18]. Breaching Article 23 carries a fine of OMR 100,000 to 500,000, against administrative fines of up to OMR 2,000 (Articles 29 and 32) [13]. - Breach. Within 72 hours to the competent department, and to data subjects where the breach may cause serious harm or high risk (Articles 30 and 32) [14]. - Officer. Required, with public contact details, preferably based in Oman; CMS advises treating Arabic as the primary version of privacy notices [1]. - Sector rules. The Ministry's Cloud and Hosting Services Standard (2018) keeps government data, backups included, inside Oman [19]. ### Saudi Arabia The most developed machinery of the six: controller registration, breach reports, standard clauses and a record of penalties. SDAIA's site would not serve us the texts, so this entry rests on DLA Piper, the privacy vendor Securiti and Clyde & Co. - Law and dates. Royal Decree M/19 of 16 September 2021, amended by Royal Decree M/148 of 27 March 2023, in effect from 14 September 2023 with a year to comply, and applied through Implementing Regulations and Transfer Regulations [8]. The transfer regulation was updated on 1 September 2024 and rules for certificates of accreditation issued on 17 February 2026 [2]. - Regulator. SDAIA, with the central bank and the communications regulator keeping their sectors; most controllers register on its National Data Governance Platform [8]. - Lawful bases. Consent is the primary basis, and the law lists the cases where it is not required [8]. - Transfer abroad. Permitted to adequate countries or under safeguards, provided national security and the Kingdom's vital interests are not harmed [8]. With no adequacy list published by September 2026, every transfer rests on SDAIA's standard contractual clauses (A fixed contract text, issued by a regulator, that the sender and the receiver of personal data sign so that a transfer abroad is lawful.), binding common rules or a certificate of accreditation, with a risk assessment before relying on a safeguard and before continuous or large-scale transfers of sensitive data [2]. - Breach. Within 72 hours to SDAIA through the national portal; data subjects without undue delay where required [8]. - Officer and penalties. An officer is required for public entities processing at scale, for regular large-scale monitoring, and where sensitive data is a core activity; fines reach SAR 5 million [8]. - The 2026 draft. Open for comment from 6 October to 5 November 2026: a new Article 23 of the Implementing Regulations would require controllers to store personal data in the Kingdom while still allowing lawful transfers, and registration would become mandatory for controllers that transfer data abroad. If approved, it takes effect 60 days after publication in the Official Gazette [3]. It is a draft, not law. - Sector rules. The Essential Cybersecurity Controls (ECC-2:2024), binding on government agencies, their companies and operators of critical national infrastructure, require third-party contracts to cover non-disclosure, secure removal of data at the end of service and incident communication (4-1-2); the 2024 revision deleted the old in-Kingdom hosting sub-control and moved localisation to SDAIA's National Data Management Office [17]. Banks may need SAMA's approval for cloud outside the Kingdom, capital-market firms must use cloud inside it, and insurers must keep customer data there [10]. ### United Arab Emirates A federal law still waiting for its regulations, and two financial free zones with regimes of their own. - Law and dates. Federal Decree-Law No. 45 of 2021, issued 20 September 2021, in force 2 January 2022. It excludes government data, health and banking data governed by their own laws, and free-zone companies with their own data protection law (Article 2) [15]. - The missing regulations. Article 28 required executive regulations within six months; Article 29 gives six months from their issue to comply [15]. None had been issued by 15 June 2026 [4], and the legislation portal listed none on 14 October 2026 [15]. - Regulator. The UAE Data Office, created by Federal Decree-Law No. 44 of 2021 [15], which never became fully operational and is being absorbed into the Federal Authority for Artificial Intelligence and Data announced on 14 June 2026 [4]. - Lawful bases. Consent, except in listed cases such as performing a contract with the data subject, legal claims and the public interest (Article 4) [15]. - Transfer abroad. To countries with data protection law and a regulator, in cases the Data Office approves, or under an agreement the UAE has joined (Article 22); otherwise under a contract binding the recipient to the law's standards, with explicit consent, to perform a contract with the data subject, or for legal claims or the public interest (Article 23) [15]. - Breach. To the Data Office on becoming aware, within a period the executive regulations are to set (Article 9) [15]. For now no number of hours applies. - Officer. Required for high-risk processing or large volumes of sensitive data, and may sit outside the UAE (Article 10) [15]. - Sector rules. Electronic health data must be stored in the UAE under Federal Law No. 2 of 2019, subject to exceptions, and personal and payment data under the central bank's 2021 retail payments regulation [10]. ### The Dubai and Abu Dhabi financial free zones The Dubai International Financial Centre (DIFC) and Abu Dhabi Global Market (ADGM) sit outside the federal law, closer to the European model. DIFC Law No. 5 of 2020, in force since July 2020 under a Commissioner of Data Protection, admits six lawful bases, asks for breach notice as soon as practicable, and permits transfers on adequacy, safeguards or listed derogations [20]. Its Regulation 10 of September 2023 covers systems that process personal data without a person directing each step: the deployer is deemed the controller, users must be told at first use, and a system offered commercially must serve human-defined or human-approved purposes [21]. The ADGM Data Protection Regulations 2021 require breach notice within 72 hours where feasible and restrict transfers out of ADGM, including to the rest of the UAE [22]. ### Qatar The oldest law in the group and the most open on transfer: rather than restricting cross-border flows, it forbids controllers to restrict them. - Law and dates. Law No. 13 of 2016, issued 3 November 2016 and published in Official Gazette No. 15 of 2016, with six months to comply (Article 30) [7]; in effect from 2017 [9]. - Regulator. The National Cyber Security Agency, through its National Cyber Governance and Assurance Affairs, under Amiri Decree No. 1 of 2021 [16]; a 2026 practice guide still calls the division of roles with the ministry unsettled [9]. - Lawful bases. Consent, unless processing is necessary for a lawful purpose (Article 4) [7]. - Transfer abroad. A controller may not limit cross-border data flow unless the processing breaches the law or may cause serious damage (Article 15) [7]. No transfer mechanism is prescribed, and the 2022 Cloud Policy Framework states that data residency is no longer a requirement [9]. Data of a special nature (Qatar's term for the personal data its law treats as sensitive. Other Gulf laws say sensitive data, with similar lists.), such as health, children's data, religious creeds and criminal offences, needs the competent department's permission (Article 16) [7]. - Breach. Individuals and the competent department must be told of a breach that may cause serious damage (Article 14) [7], within 72 hours under the agency's guideline of September 2022 [16]. - Officer and penalties. No officer is named; controllers identify those responsible for protection (Article 11). Fines reach QAR 1 million, or QAR 5 million for the security, special-nature and children's data articles (Articles 23 and 24) [7]. - A separate regime. The Qatar Financial Centre has its own 2021 regulations, with a permit for transfers to recipients without adequate protection [9]. ### Bahrain A published adequacy (A regulator's finding that another country protects personal data well enough for data to go there without further paperwork.) list with a permission route: the closest of the six to the European model. - Law and dates. Law No. 30 of 2018, in force since 1 August 2019, supplemented by ten resolutions of 17 March 2022 [23]. - Regulator. The Personal Data Protection Authority, whose functions the Ministry of Justice, Islamic Affairs and Endowments performs under Decree No. 78 of 2019 [23]. - Lawful bases. Consent, or necessity for a contract, a legal obligation, vital interests or legitimate interests [23]. - Transfer abroad. Free to the 83 countries that Resolution No. 42 of 2022 lists as adequate; other destinations need the Authority's authorisation, case by case, unless an exclusion applies [24]. - Breach. Within 72 hours, under Resolution No. 43 of 2022 [24]. - Officer and penalties. Optional under Resolution No. 46 of 2022 [24], but required for licensed financial institutions; unlawful transfers can carry up to a year's imprisonment and fines up to BHD 20,000 [23]. ### Kuwait The exception among the six: there is no general data protection statute. - Law and dates. The E-Transactions Law No. 20 of 2014 sets a general baseline. The telecoms regulator CITRA's Data Privacy Protection Regulation, as amended by Decision No. 26 of 2024, applies only to CITRA-licensed telecom and internet providers [25]. - Regulator. No single authority: the telecoms regulator for its licensees, the Central Agency for Information Technology for the E-Transactions Law, and the National Centre for Cybersecurity, mainly for government entities [25]. - Consent, transfer and breach. Licensees must obtain consent before collecting personal data, tell users of transfers outside Kuwait and may need CITRA's approval for them, and notify CITRA and affected users within 24 hours of a breach. Others generally need no approval unless government information is involved [25]. - Classification. The Data Classification Policy, which required certain data to be stored in Kuwait, was repealed in February 2024 [25]. ## 5. The regimes side by side Figure 2 sets the eight regimes against the five questions an agent deployment must answer first. Three patterns matter for an operating company. **Figure 2. Eight regimes, five questions** Each row is one regime and each column one question; the cells are short, and section 4 gives the conditions behind each. | | Consent central | Transfer abroad | Breach notice | Officer | Regulator | | --- | --- | --- | --- | --- | --- | | Oman (Royal Decree 6/2022) | Yes: explicit consent | Explicit consent, and protection no lower than Oman's | 72 hours | Required | Ministry of Transport, Communications and IT | | Saudi Arabia (PDPL, 2021) | Primary basis, with listed exceptions | A safeguard and a risk assessment; no adequacy list yet | 72 hours | In listed cases | SDAIA | | UAE federal (Decree-Law 45/2021) | Yes, with listed exceptions | Adequacy, or a contract, consent and other listed cases | On awareness; the period awaits the regulations | In high-risk cases | UAE Data Office, being folded into a new federal authority | | UAE: DIFC (Law No. 5 of 2020) | One of six bases | Adequacy, safeguards or derogations | As soon as practicable | For systematic high-risk processing | Commissioner of Data Protection | | UAE: ADGM (Regulations 2021) | One of six bases | Adequacy, approved clauses or derogations | 72 hours where feasible | In listed cases | Commissioner of Data Protection | | Qatar (Law No. 13 of 2016) | Yes, or a lawful purpose | Flows may not be restricted; special-nature data needs permission | 72 hours, by guideline | Not named in the law | National Cyber Security Agency | | Bahrain (Law No. 30 of 2018) | Yes, or another listed basis | An 83-country list, or the Authority's permission | 72 hours | Optional; required for licensed financial firms | Personal Data Protection Authority | | Kuwait (Decision No. 26 of 2024) | Yes, for licensees | Tell users the destination countries | 24 hours | Not set out | Telecoms regulator, for its licensees only | Qantara's compilation, read 14 October 2026, from the texts of Oman's law and regulation, the UAE's decree-law and Qatar's law and breach guideline, and from DLA Piper, Securiti, Clyde & Co, Chambers and the Agora copy of the DIFC regulation for the other regimes. Not legal advice. Consent is central everywhere, but its weight differs. In Oman it is also a condition met before data leaves the country (Article 37) [14]; we read that to mean consent given for a delivery does not on its face cover sending the order to a model abroad. In the UAE's federal law consent is the default, with listed exceptions that include performing a contract [15]. The DIFC, ADGM and Bahrain treat it as one basis among several, legitimate interests included [20, 22, 23]. Transfer rules diverge the most, from Oman's consent requirement to Qatar's rule that a controller may not restrict the flow. A group policy that treats 'GCC data' as one category will be too strict for Qatar and too loose for Oman. Breach clocks are short, mostly 72 hours. Kuwait's licensees have 24, and the UAE federal law and the DIFC set no number. A company must be able to say, within one to three days, which records an agent read and where they went: a logging requirement before it is a legal one. ## 6. In-country cloud, and what it does not settle Table 1 lists the in-country regions on each provider's own pages, read on 14 October 2026 [11, 26, 27, 28]. Microsoft's Saudi Arabia East is announced for the fourth quarter of 2026 but was not yet in Azure's list updated on 13 October [5, 26]; AWS's Saudi region is on track for December 2026 [6]. Oman has two Oracle dedicated regions, Muscat and, since October 2025, Ibri, offered to government entities [29, 30]. **Table 1. In-country cloud regions of the four large providers, by country, as listed on each provider's own pages on 14 October 2026** | Country | AWS | Microsoft Azure | Google Cloud | Oracle public regions | Oracle dedicated regions | | --- | --- | --- | --- | --- | --- | | Saudi Arabia | Announced; on track for December 2026 | Saudi Arabia East, announced for Q4 2026; not yet listed | Dammam (me-central2); Saudi customers buy through CNTXT | Riyadh (me-riyadh-1), Jeddah (me-jeddah-1) | Riyadh, Al Khobar | | UAE | Middle East (UAE), me-central-1, 3 zones | UAE North (Dubai), 3 zones; UAE Central (Abu Dhabi), restricted access | None | Abu Dhabi (me-abudhabi-1), Dubai (me-dubai-1) | Two in Abu Dhabi | | Qatar | None | Qatar Central (Doha), 3 zones | Doha (me-central1), 3 zones | None | Doha | | Bahrain | Middle East (Bahrain), me-south-1, 3 zones | None | None | None | None | | Oman | None | None | None | None | Muscat; Ibri, live since October 2025 | | Kuwait | None | None | None | None | None | Sources: AWS, Microsoft, Google and Oracle region pages and announcements [11, 6, 26, 5, 27, 31, 28, 29, 30]. Dedicated regions are built for named customers and are not generally on sale. ### What in-country settles A region in the country settles where data sits at rest (Held in storage, in databases, files, backups and logs, as opposed to moving over a network or being worked on in a processor's memory.): the database, the documents, the logs and, if configured, the backups. That answers most transfer questions for stored data, and meets the rules that require storage in the country, such as the UAE's for health and payments and Oman's for government data [10, 19]. ### What it does not settle: where the model runs It does not settle where the model that reads the data runs. Inference (Running a trained model on an input to produce an output. When an agent asks a model to read an invoice, the reading happens wherever the model's inference runs, which can differ from where the invoice is stored.) is a separate service from storage, and the providers document it separately (Table 2). **Table 2. Where a model's inference runs when it is called from a Gulf region, by the providers' own documentation, read 14 October 2026** | Provider | What stays in the region | Where inference can run | In-region options the provider names | | --- | --- | --- | --- | | AWS Bedrock, UAE and Bahrain regions | Stored data, logs, knowledge bases and configurations | Claude models: global routing only; data may be processed in any commercial region | Amazon Nova Lite and Nova Pro in the UAE region | | Microsoft Azure, Foundry Models | Data at rest, in the chosen geography | Global types: any Azure region. Data Zone types: United States, European Union or Asia Pacific | Standard and Regional Provisioned types keep processing in the geography, where a model offers them | | Google Cloud, Vertex AI | Not guaranteed by the endpoint alone | Global endpoint: the customer cannot control or know the region | Multi-region endpoints with a jurisdictional boundary, for the United States and the European Union | Sources: Amazon Bedrock regional availability and the AWS announcement of 24 February 2026 [12, 32]; Microsoft Learn on deployment types, updated 12 August 2026 [33]; Google Cloud on deployments and endpoints, updated 14 October 2026 [34]. On AWS, every Claude model listed for the UAE and Bahrain regions is offered only through global cross-region inference (A cloud feature that sends a model request from the region where it was made to another region with capacity, and returns the answer to the first.), and none of Bedrock's geographic profiles covers the Gulf [12]; customer data is not stored in the destination region and logs stay in the source region [32]. Storage stays, inference travels. Azure's Data Zones cover only the United States, the European Union and Asia Pacific [33], and Google states that its endpoints do not guarantee in-region processing [34]. So a Dubai distributor whose database sits in the UAE region, calling a frontier model through a global route, sends each prompt wherever the provider routes it. Whether a prompt processed abroad and not stored there counts as a transfer is not settled in the texts we read. The conservative reading, which we follow, treats it as one: under the UAE's federal law it then needs an Article 22 or 23 basis [15], and in Oman the place of inference becomes a consent question [14]. The same call from Qatar raises a much smaller one [7]. ### Continuity In-country also concentrates risk. In early March 2026 AWS reported drone strikes on two of its UAE facilities, impairing two of the three zones of its UAE region, and advised Middle East customers to consider moving workloads to other regions [35]. A backup abroad is itself a transfer; where a continuity copy may go, and under what paper, is best decided before it is needed. ## 7. Five questions before an agent reads personal data Figure 3 turns the guide into five questions, each answer narrowing the next. **Figure 3. Five questions, answered in writing before go-live** Follow the arrows from the data to the paper; the orange box is the question most often left out, and the dashed arrow is the way back when the last question has no good answer. - 1. What data: Which fields; which are personal - 2. Whose: Where people are; which regime - 3. Where stored: Region for record, logs, backups - 4. Where the model runs: Per model, as the provider documents - 5. What transfer paper: Consent, clauses, permit, or none needed - Written down: Per workflow, before go-live - 1. What data → 2. Whose - 2. Whose → 3. Where stored - 3. Where stored → 4. Where the model runs - 4. Where the model runs → 5. What transfer paper - 5. What transfer paper → Written down - 5. What transfer paper → 1. What data (read less, or run it in-country) Qantara, derived from the requirements set out in sections 4 and 6. A method for preparing the facts counsel needs, not a legal test. 1. What data. Which fields the agent reads, which are personal, and whether any are sensitive: health, biometrics, children's data, criminal records. A field the work does not need is better left unread than protected. 2. Whose. Where the people are, and which regime governs the company holding the data; a free-zone entity and its mainland sister answer to different laws. 3. Where stored. The named region or building for the record, the documents, the logs and the backups. 4. Where the model runs. For each model the workflow calls: the provider, the deployment type and the region of inference, as documented on the day. This is the question most often left out. 5. What transfer paper. If question 4 puts personal data abroad, the basis that allows it, from explicit consent in Oman to, for ordinary data, nothing beyond lawful processing in Qatar. Where question 5 has no good answer, the options are the ones questions 1 and 4 open: read fewer personal fields, remove them before the call, or choose a model that runs in the country. **An illustrative example** A distributor in Muscat wants an orders agent to read WhatsApp orders from hotels in Oman and draft them into its ERP. The order lines are not personal data; the buyer's name and mobile number are. The record and the logs are stored in Oman, and the preferred drafting model is offered only through a global route. On the conservative reading in section 6, sending the buyer's name and number to that model needs the buyer's explicit consent to the transfer; sending the order lines without them puts no personal data in front of the model. The written answer names the fields the model sees, the model, and where it runs. The example is illustrative and describes no customer. ## 8. Implications for deployment The guide comes down to five practices. - Decide storage first, country by country. Keep the record, documents and logs in a named region in the country; where no public region exists, as in Oman and Kuwait, name the facility. - Treat the model as a separate location. State for each workflow which model reads which fields and where its inference runs, and recheck when a provider's documentation changes or a region opens. - Minimise before the call. Under every regime the simplest transfer is the one that carries no personal data. - Log every read. With breach clocks of 24 to 72 hours, a company must know which records an agent read and what it sent where. An agent with credentials of its own and a log line for every read turns that answer into a query rather than an investigation. - Prepare the transfer paper before go-live. Consent wording in Oman, clauses and a risk assessment in Saudi Arabia, the right Article 23 basis in the UAE, permission for an unlisted country in Bahrain. If Saudi Arabia's draft is adopted, controllers that transfer data abroad will also have to register [3]. This is how Qantara approaches it. The operating record and its log are kept in the customer's country. For each workflow, before it goes live, we state in writing which model reads what and where that model runs. Each agent signs in with credentials of its own, scoped to one deployment and revocable, and every read and write is a line in the log. Above thresholds the customer sets, a person approves. None of this replaces the customer's counsel; it gives counsel the facts the five questions ask for. ## 9. Limitations This guide is not legal advice and is current only as of 14 October 2026. For Saudi Arabia, Bahrain, Kuwait and the free zones it relies on summaries that can lag the texts: the DLA Piper pages for the DIFC and ADGM date from January 2025 and January 2024 [20, 22], and our copy of Regulation 10 is unofficial [21]. The English texts for Oman, the UAE and Qatar are translations. Whether inference abroad without storage counts as a transfer is not settled in the texts; we took the conservative reading. Sector rules are covered selectively, and free zones other than the DIFC and ADGM not at all. Several facts here will change soon: the UAE's executive regulations, Saudi Arabia's draft, the new Saudi regions and every region's model list. Each would change a cell in Figure 2 or Tables 1 and 2, not the method. ## 10. Conclusion The six Gulf states regulate personal data in ways that agree in outline and differ in the details that decide an AI deployment: whether consent must cover a transfer, what paper a transfer needs, and how many hours a company has to report a breach. The cloud has moved closer, with public regions in four states and two more due in Saudi Arabia, but a region settles where data is stored, not where the model reads it. The practical answer is the same everywhere: write down, per workflow and before go-live, what the agent reads, which of it is personal, where it is stored, where the model runs, and what paper covers any gap. The answers will differ between Muscat, Riyadh, Dubai and Doha. The questions do not. ## References [1] Al Bulushi, S., Ooijevaar, M. and Dolphin, C. (2026). Oman personal data protection law: entering the enforcement phase. CMS legal update, 11 February 2026 (law-firm summary). https://cms.law/en/omn/legal-updates/oman-personal-data-protection-law-entering-the-enforcement-phase (accessed 14 October 2026) [2] Baig, A., Qureshy, A. A. and Khan, S. (2026). An overview of Regulation on Personal Data Transfer Outside the Kingdom. Securiti, privacy software vendor, updated 30 September 2026 (vendor summary). https://securiti.ai/regulation-on-personal-data-transfer-outside-the-kingdom (accessed 14 October 2026) [3] Bajunaid, L. and Ezzat, N. (2026). The SDAIA publishes draft amendments to the Implementing Regulations of the PDPL. Clyde & Co insights, 8 October 2026 (law-firm summary). https://www.clydeco.com/en/insights/2026/10/sdaia-publishes-draft-amendments-to-the-pdpl (accessed 14 October 2026) [4] Andreeva, K. (2026). UAE establishes Federal Authority for Artificial Intelligence and Data. Morgan Lewis, 15 June 2026 (law-firm summary). https://www.morganlewis.com/pubs/2026/06/uae-establishes-federal-authority-for-artificial-intelligence-and-data (accessed 14 October 2026) [5] Microsoft (2026). Microsoft confirms Saudi Arabia datacenter region available for customers to run cloud workloads from Q4 2026. Microsoft Source EMEA, February 2026. https://news.microsoft.com/source/emea/2026/02/microsoft-confirms-saudi-arabia-datacenter-region-available-for-customers-to-run-cloud-workloads-from-q4-2026/ (accessed 14 October 2026) [6] Amazon (2026). AWS to launch first cloud infrastructure region in the Kingdom of Saudi Arabia by December 2026. About Amazon. https://www.aboutamazon.com/news/aws/aws-cloud-region-saudi-arabia (accessed 14 October 2026) [7] State of Qatar (2016). Law No. (13) of 2016 on Protecting Personal Data Privacy. National Cyber Security Agency, unofficial English text; official text in Official Gazette No. 15 of 2016. https://ncsa.gov.qa/en/pages/personal-data-privacy-personal-data-privacy-protection-law (accessed 14 October 2026) [8] DLA Piper (2026). Data protection laws in Saudi Arabia - Data Protection Laws of the World. Data Protection Laws of the World, last modified 11 February 2026 (law-firm guide). https://www.dlapiperdataprotection.com/index.html?t=law&c=SA (accessed 14 October 2026) [9] Saleh, A., Ahmad, A., Saleh, J., et al. (2026). Data Protection & Privacy 2026: Qatar. Chambers and Partners Global Practice Guides, updated 10 March 2026 (law-firm guide). https://practiceguides.chambers.com/practice-guides/data-protection-privacy-2026/qatar (accessed 14 October 2026) [10] Clifford Chance (2025). Doing business in the Middle East: data transfers in the UAE and the KSA. Talking Tech, Clifford Chance, 10 March 2025 (law-firm summary). https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2025/03/doing-business-in-the-middle-east--data-transfers-in-the-uae-and-ksa.html (accessed 14 October 2026) [11] Amazon Web Services (2026). AWS Regions. AWS Global Infrastructure documentation. https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html (accessed 14 October 2026) [12] Amazon Web Services (2026). Regional availability by models. Amazon Bedrock User Guide. https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html (accessed 14 October 2026) [13] Sultanate of Oman (2022). Royal Decree 6/2022 Issuing the Personal Data Protection Law. Royal Decree 6/2022, Sultanate of Oman; translation published by Decree.om. https://decree.om/2022/rd20220006/ (accessed 14 October 2026) [14] Ministry of Transport, Communications and Information Technology, Oman (2024). Ministerial Decision 34/2024 issuing the Executive Regulation of the Personal Data Protection Law (title translated from the Arabic). Official Gazette 1531, 4 February 2024; text reproduced by Qanoon.om. https://qanoon.om/p/2024/mtcit20240034/ (accessed 14 October 2026) [15] United Arab Emirates (2021). Federal Decree by Law No. (45) of 2021 Concerning the Protection of Personal Data. UAE Legislation portal, Ministry of Cabinet Affairs (English translation; the Arabic text prevails). https://uaelegislation.gov.ae/en/legislations/1972 (accessed 14 October 2026) [16] National Cyber Security Agency, Qatar (2022). Personal Data Breach Notifications: Guidelines for Regulated Entities, version 2.0. National Cyber Governance and Assurance Affairs, guideline PDPPL-02050217E, September 2022. https://ncsa.gov.qa/en/pages/guidance-hub-for-regulated-entities (accessed 14 October 2026) [17] National Cybersecurity Authority, Saudi Arabia (2024). Essential Cybersecurity Controls (ECC – 2: 2024). National Cybersecurity Authority; web page last updated 19 July 2026. https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC--2024-EN.pdf (accessed 14 October 2026) [18] Wigley, T. and Teng, L. Y. (2024). Oman's data protection law – new regulations. Trowers & Hamlins insights, 13 February 2024 (law-firm summary). https://www.trowers.com/insights/2024/february/omans-data-protection-law---new-regulations (accessed 14 October 2026) [19] Ministry of Transport, Communications and Information Technology, Oman (2018). Cloud and Hosting Services Standard. Ministry of Transport, Communications and Information Technology, standards library. https://www.mtcit.gov.om/library-3/guidelines-documentation-7/standards-64/cloud-and-hosting-services-standard-263 (accessed 14 October 2026) [20] DLA Piper (2025). Data protection laws in UAE - Dubai (DIFC). Data Protection Laws of the World, last modified 27 January 2025 (law-firm guide). https://www.dlapiperdataprotection.com/countries/uae-dubai-difc/law.html (accessed 14 October 2026) [21] Emerging Technology Observatory, Georgetown University (2023). DIFC Data Protection Regulations, Regulation 10. AGORA instrument 1773 (unofficial copy of the text, enacted 1 September 2023). https://agora.eto.tech/instrument/1773 (accessed 14 October 2026) [22] DLA Piper (2024). Data protection laws in UAE - Abu Dhabi Global Market Free Zone. Data Protection Laws of the World, last modified 9 January 2024 (law-firm guide). https://www.dlapiperdataprotection.com/countries/uae-abu-dhabi-global-market-free-zone/law.html (accessed 14 October 2026) [23] DLA Piper (2026). Data protection laws in Bahrain - Data Protection Laws of the World. Data Protection Laws of the World, last modified 2 February 2026 (law-firm guide). https://www.dlapiperdataprotection.com/index.html?t=law&c=BH (accessed 14 October 2026) [24] Clyde & Co (2022). Bahrain issues new privacy guidelines supplementing the Personal Data Protection Law. Clyde & Co insights, 28 April 2022 (law-firm summary). https://www.clydeco.com/en/insights/2022/04/bahrain-issues-new-privacy-guidelines (accessed 14 October 2026) [25] Saleh, A., Ahmad, A., Al Awadhi, M. N., et al. (2026). Data Protection & Privacy 2026: Kuwait. Chambers and Partners Global Practice Guides, updated 10 March 2026 (law-firm guide). https://practiceguides.chambers.com/practice-guides/data-protection-privacy-2026/kuwait (accessed 14 October 2026) [26] Microsoft (2026). List of Azure regions. Microsoft Learn, updated 13 October 2026. https://learn.microsoft.com/en-us/azure/reliability/regions-list (accessed 14 October 2026) [27] Google Cloud (2026). Regions and zones. Compute Engine documentation, updated 13 October 2026. https://docs.cloud.google.com/compute/docs/regions-zones (accessed 14 October 2026) [28] Oracle (2026). Regions and availability domains. Oracle Cloud Infrastructure documentation. https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm (accessed 14 October 2026) [29] Oracle (2026). EPM Cloud geographic, data, and air-gapped regions. Oracle Enterprise Performance Management Cloud documentation (lists the dedicated regions). https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/tsepm/opc_gen_2_regions.html (accessed 14 October 2026) [30] Grey, D. (2025). Oracle announces second OCI region in Oman. W.Media, 14 October 2025. https://w.media/oracle-announces-second-oci-region-in-oman/ (accessed 14 October 2026) [31] Google Cloud (2026). Dammam region access. Google Cloud documentation, updated 13 October 2026. https://docs.cloud.google.com/docs/dammam-region-access (accessed 14 October 2026) [32] Basudan, H., Li, M., Dabboussi, S., et al. (2026). Introducing Amazon Bedrock global cross-Region inference for Anthropic's Claude models in the Middle East Regions (UAE and Bahrain). AWS Machine Learning Blog, 24 February 2026. https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-global-cross-region-inference-for-anthropics-claude-models-in-the-middle-east-regions (accessed 14 October 2026) [33] Microsoft (2026). Understanding deployment types in Microsoft Foundry Models. Microsoft Learn, updated 12 August 2026. https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/concepts/deployment-types (accessed 14 October 2026) [34] Google Cloud (2026). Deployments and endpoints. Google Cloud generative AI documentation, updated 14 October 2026. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/locations (accessed 14 October 2026) [35] Mann, T. (2026). AWS says drones hit two of its datacenters in UAE, urges users to move resources to different regions. The Register, 2 March 2026, updated 3 March 2026. https://www.theregister.com/2026/03/02/amazon_outages_middle_east/ (accessed 14 October 2026) ## Cite this paper ```bibtex @techreport{qantara2026gccpersonaldata, title = {AI and personal data in the GCC: a country-by-country guide}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/gcc-personal-data} } ``` ## Disclosure This guide is not legal advice; it describes the law, the cloud regions and the providers' documentation as we read them on 14 October 2026, and each may have changed since. The statements of law are cited to the texts where we could open them and otherwise to the law-firm, vendor and practice-guide summaries named in the references; English translations are unofficial and the Arabic texts prevail. The timeline, the comparison matrix, the five questions and the two tables are our own compilation from those sources, the reading of inference abroad as a transfer is ours and labelled as conservative, and the distributor example is illustrative. Canonical: https://qantara.systems/insights/gcc-personal-data --- # WhatsApp is the Gulf's operating system Research. Qantara Research, Qantara. 14 October 2026. 19 min read. > We argue that in much of Gulf trade, orders, complaints, delivery proof and payment reminders arrive as chats, voice notes and photos on one app; this paper weighs the evidence, sets out Meta's rules for businesses, and describes what an agent has to do to work there. ## Abstract In much of Gulf trade, an order arrives as a voice note, a confirmation as a one-word reply, delivery proof as a photo of a signed note, and a payment reminder as a chat message. We ask how far the evidence supports that picture and what it requires of an AI agent that works in the channel. We combine national and panel survey data on WhatsApp use in the six GCC states, Meta's documentation of the WhatsApp Business Platform as read on 14 October 2026, and research on conversational commerce, media choice and dialect speech recognition. WhatsApp is the most used platform in every Gulf survey we found: 89.0 percent of internet users in the UAE and 82.9 percent in Saudi Arabia used it in the past month, against 54.0 percent worldwide, and Saudi Arabia's regulator puts use above 96 percent among people aged 30 to 59. Meta now charges per delivered template and leaves replies inside a 24-hour window free, which favours answering over broadcasting. The hard part is the content: dialect speech, handwriting and documents that must be read, confirmed and logged before anything reaches an ERP. ## Key findings 1. WhatsApp is the most used platform in every Gulf survey we found: 89.0 percent of internet users aged 16 and over in the UAE and 82.9 percent in Saudi Arabia used it in the past month in the second quarter of 2025, against 54.0 percent worldwide. 2. In the Saudi regulator's 2025 survey, WhatsApp use runs from 96.2 to 96.7 percent in every age band from 30 to 59, so the owners, buyers and drivers a Gulf supplier deals with are almost all on it. 3. Since 1 July 2025 Meta charges per delivered template message while replies inside the 24-hour customer service window are free, and between October 2025 and October 2026 it changed rates for five of the six GCC markets, so the cost of a workflow has to be checked against the current rate card. 4. Much of what arrives is not text: in a 2024 benchmark a widely used open model transcribed Emirati speech with a word error rate of 52.88 percent, and Meta keeps a received media file available for seven days, so an agent has to store, read and confirm every voice note and photo before it acts. 5. No public source measures how much Gulf business-to-business ordering runs on WhatsApp; the case rests on usage surveys and one commissioned consumer poll, and a measured study of order flows is the missing evidence. ## 1. Introduction The working hypothesis of this paper is easy to state. In much of Gulf trade, a café owner orders by recording a voice note on the way to work, a site engineer sends a photo of a handwritten list, a buyer forwards a PDF purchase order into a group chat, and the driver who delivers it sends back a photo of the signed delivery note from the tailgate. The complaint about a short carton arrives the same way, and so does the payment reminder three weeks later. The phone number of the customer is, in practice, the account; the chat history is the file. We call this a hypothesis because the evidence for it is uneven. Section 3 shows that the evidence on use is strong and consistent: WhatsApp is the most used platform in every Gulf survey we could find. The evidence that business-to-business ordering runs through it is indirect, and we say so where it matters. Two things make the question practical now. First, Meta rebuilt the commercial rules of the channel between 2024 and 2026: it made replies inside the customer's window free, moved to charging per delivered template on 1 July 2025, opened business calling, and in January 2026 restricted general-purpose AI assistants. Second, speech and vision models can now attempt to read a voice note or a photographed list, though Gulf dialect and handwriting remain hard. An agent that takes orders where customers already send them can be built; whether it can be trusted depends on how it reads, confirms, asks and records. This paper contributes: 1. A dated compilation of the WhatsApp usage evidence for the six GCC states, with the measure and base of each figure, and the states for which we found no recent public figure. 2. A summary of Meta's rules for businesses as of 14 October 2026: the customer service window, templates, pricing, consent, escalation to a person and the restriction on AI providers, with a timeline of changes since 2023. 3. A design for an agent that turns voice notes, photos and documents into an order in an ERP, with an illustrative worked example and the single point at which a person approves. 4. An account of when a phone call is still the better channel, and how the agent hands over. ## 2. Background and related work The phrase conversational commerce was popularised by Chris Messina in January 2015, in a short post arguing that messaging apps would bring the point of sale to the customer [1]. Most of the writing that followed concerns retail and chatbots on brand channels. The pattern we examine is older and less designed: traders using a general messaging app as their order channel because their customers already use it. The closest recent study is De's interview work with fourteen small business owners in India, presented at CHI 2025, which follows what happened when WhatsApp moved from a personal tool to a professional one through WhatsApp Business [2]. The owners adapted creatively but felt sidelined by the more complex and costlier tools, a dynamic the paper calls coercive professionalization. The lesson for an agent builder is direct: the customer should not have to learn anything new. The agent meets the customer in the ordinary app, in the ordinary way they write. Economists have long studied what a shared communication channel does to trade. Jensen's study of Kerala's fisheries found that the spread of mobile phones among fishermen and wholesalers was associated with a sharp fall in price dispersion across markets and the elimination of wasted catch [3]. The Gulf case is a later stage of the same story. The channel already exists and carries the trade; what it lacks is a record. Orders, promises and proofs live in chat histories on individual phones, where the next person in the process cannot see them. Organisation science offers a frame for when a chat is the wrong channel. Daft and Lengel distinguish uncertainty, a lack of information that more data resolves, from equivocality, a lack of agreement on what the information means, and argue that equivocal situations need richer media [4]. A missing quantity is uncertainty, and a text question settles it. A dispute about whether a delivery was short is equivocal, and section 7 argues that it belongs on a call with a person. On the technical side, the hardest input is speech. Casablanca, a multi-dialect Arabic speech corpus published at EMNLP 2024, includes Emirati alongside seven other dialects and reports high error rates for every model it tested zero-shot [5]. We return to its numbers in section 5. Usage measurement, finally, comes from three kinds of source that measure different things: GWI's online surveys as published by DataReportal [6], national regulators and statistics offices, and commissioned panels. We keep their bases apart. ## 3. How much of the Gulf is on WhatsApp The most comparable figures come from GWI's survey of internet users aged 16 and over, published by Kepios in the Digital 2026 reports. In the second quarter of 2025, 89.0 percent of internet users in the UAE said they had used WhatsApp in the past month, ahead of Facebook at 82.2 percent and Instagram at 82.0 percent [7]. In Saudi Arabia the figure was 82.9 percent, narrowly ahead of TikTok at 81.8 percent and YouTube at 80.9 percent [8]. The worldwide figure across the markets GWI surveys was 54.0 percent [6]. **Figure 1. WhatsApp use in the UAE and Saudi Arabia against other markets** Each bar is the share of internet users aged 16 and over in that market who say they used WhatsApp at least once in the past month; the two Gulf markets are highlighted. | | % of internet users aged 16+ | | --- | --- | | UAE | 89 | | India | 84.6 | | Saudi Arabia | 82.9 | | United Kingdom | 82.6 | | Egypt | 71.5 | | Worldwide | 54 | | United States | 30.6 | Source: GWI, second quarter of 2025, as published in Kepios's Digital 2026 Global Overview Report (DataReportal, October 2025), slide 488, read 14 October 2026. India and Egypt are shown because many Gulf residents come from them; of the six GCC states, the report gives GWI figures only for the UAE and Saudi Arabia. The GWI figures in the Digital 2026 reports do not cover Oman, Qatar, Kuwait or Bahrain, and DataReportal's 2026 reports for those four states carry no WhatsApp figure. For them, and as a cross-check on Saudi Arabia, we turn to national and panel sources. Saudi Arabia's Communications, Space and Technology Commission, in its Saudi Internet 2025 report released in July 2026, finds WhatsApp the most used social media application at 92.7 percent, ahead of Snapchat at 83.6 percent, and breaks the figure down by age [9]. Use is above 96 percent in every band from 30 to 59. **Figure 2. In Saudi Arabia, working-age adults are almost all on WhatsApp** Each pair of bars is one age group in the regulator's survey: the share using WhatsApp and, for contrast, the share using Snapchat; the bands from 30 to 59 are highlighted. | | WhatsApp | Snapchat | | --- | --- | --- | | 10 to 19 | 79.8 | 89.3 | | 20 to 29 | 93.7 | 91 | | 30 to 39 | 96.2 | 85.2 | | 40 to 49 | 96.7 | 78.9 | | 50 to 59 | 96.6 | 71.9 | | 60 to 74 | 91.5 | 55 | Source: Communications, Space and Technology Commission, Saudi Internet 2025 (released July 2026), most used social media applications by age group, read 14 October 2026. The age pattern matters more than the headline. The platforms that lead among teenagers fall away with age; WhatsApp does not. The people who place and approve orders in a Gulf business, the owner, the purchasing officer, the site manager, are in the bands where it is close to universal. Elsewhere in the GCC the evidence is thinner. Ipsos's July 2026 panel of 506 adults in Kuwait puts WhatsApp first among platforms used, at 94 percent [10]. In Oman, a national study presented at a Ministry of Information workshop in February 2025 reported WhatsApp as the most widely used application at 99.10 percent, without a published base [11]. Ipsos's July 2025 report on Qatar says roughly 8 in 10 people there use WhatsApp, though its own usage chart does not list it [12]. For Bahrain we found no recent public figure. Table 1 sets the figures side by side with what each measures. **Table 1. WhatsApp use in the six GCC states, by source. Read 14 October 2026.** | Country | WhatsApp | What is measured | Source and date | | --- | --- | --- | --- | | UAE | 89.0% | Internet users aged 16 and over who used it in the past month; the most used platform | GWI, second quarter of 2025, in DataReportal Digital 2026 | | UAE | 65% | Residents who contacted a business about a product or service on WhatsApp in the past year (call centre 55%, email 48%) | YouGov for Zbooni, 1,000 residents, reported February 2024 | | Saudi Arabia | 92.7% | Users of each application in the regulator's survey; the most used social media application | Communications, Space and Technology Commission, Saudi Internet 2025, July 2026 | | Saudi Arabia | 82.9% | Internet users aged 16 and over who used it in the past month; the most used platform | GWI, second quarter of 2025, in DataReportal Digital 2026 | | Kuwait | 94% | Platforms used, online panel of 506 adults; the most used platform | Ipsos, Spotlight Kuwait, July 2026 | | Oman | 99.10% | Base not published; the most used application | National study presented at a Ministry of Information workshop, reported February 2025 | | Qatar | Roughly 8 in 10 | Stated in the report's text; its usage chart does not list WhatsApp | Ipsos, Spotlight Qatar, July 2025 | | Bahrain | No figure found | No recent public survey with a WhatsApp figure | Searched 14 October 2026 | Bases and methods differ: compare rows from the same source, not figures across sources. ### From use to business contact Use is not ordering. The only Gulf figure we found on contacting businesses comes from a YouGov poll of 1,000 UAE residents commissioned by Zbooni, a company that sells commerce tools built on WhatsApp: 65 percent had used WhatsApp to ask a business about a product or service in the past year, against 55 percent who had called a call centre and 48 percent who had used email [13]. The sponsor has an interest in the answer, and the poll measures consumers rather than trade buyers, so we treat it as consistent with the hypothesis rather than proof of it. The same poll found that 87 percent wanted to deal with a real person rather than a chatbot, a number section 7 takes seriously. ## 4. The rules of the channel A business that wants software to send and receive WhatsApp messages does so through the WhatsApp Business Platform, under Meta's terms, policy and pricing. These rules shape what an agent can do more than any model choice, and they can change every quarter. Everything in this section was read from Meta's own documentation on 14 October 2026. ### The window and the template When a customer messages a business, a customer service window (The 24 hours after a customer's last message, during which the business may reply with any kind of message. Outside it, only pre-approved templates can be sent.) opens. It closes once 24 hours have passed since the customer last wrote [14]. Inside it, the business may reply with text, images, documents or audio. Outside it, the only messages a business can send are template messages (Message formats registered with Meta in advance and approved before use, with placeholders for names, numbers and dates. Each is categorised as marketing, utility or authentication.), and a template must have the status approved before it can be sent [15]. Meta does not translate templates; the business supplies the strings in each language it uses [15]. For a Gulf business that means every template exists twice, in Arabic and in English, and both are reviewed before anything is sent. ### What is charged Meta's pricing has changed shape three times since 2023. From 1 June 2023 it priced 24-hour conversations in four categories, marketing, utility, authentication and service [16]. From 1 November 2024 service conversations, the ones a customer opens, became free and unlimited [16]. On 1 July 2025 conversation-based pricing was replaced by per-message pricing: Meta now charges only when a template message is delivered, at a rate set by the template's category and the recipient's country, with volume tiers (Lower rates for utility and authentication templates once a business passes set monthly volumes; the count resets each month.) for utility and authentication [14]. Non-template messages inside an open window are free, utility templates delivered inside an open window are free, and every message is free for 72 hours after a customer writes in from a click-to-WhatsApp advert or a Facebook Page button [14]. Gulf rates have moved repeatedly. On 1 October 2025 the marketing rate for the UAE rose and the utility and authentication rates for Saudi Arabia fell; on 1 April 2026 the Saudi marketing rate rose and billing in Saudi riyals and UAE dirhams became available; on 1 July 2026 Qatar moved from a regional rate to its own, higher, utility and authentication rates; and on 1 October 2026 Kuwait and Oman followed [14]. Bahrain is still priced as part of Meta's Rest of Middle East group. Meta may change rates on the first day of any quarter, so a cost estimate for a workflow carries a date or it is wrong [14]. **Figure 3. What changed on the WhatsApp Business Platform, 2023 to 2026** Read top to bottom: each row is a change Meta made to the rules, the pricing or the interface, with its effective date; rate changes are shown for GCC markets only. - 1 Jun 2023: Four priced conversation categories. Marketing, utility, authentication and service, each with its own rate. - 1 Nov 2024: Service conversations free. Conversations a customer opens cost nothing, without a monthly cap. - 1 Jul 2025: Per-message pricing. Only delivered templates are charged; volume tiers for utility and authentication. - 15 Jul 2025: Calling API available. Businesses can take and make WhatsApp calls through the business interface. - 1 Oct 2025: UAE and Saudi rates change. Higher marketing rate for the UAE; lower utility and authentication rates for Saudi Arabia. - 9 Oct 2025: Received media kept for 7 days. Media from incoming messages can be fetched for seven days instead of 30. - 15 Jan 2026: Terms restrict AI providers. General-purpose AI assistants barred where they are the primary function, except where Meta is legally required to allow them. - 1 Apr 2026: Saudi marketing rate rises. Billing in Saudi riyals and UAE dirhams becomes available. - 1 Jul 2026: Qatar gets its own rates. Moved out of the regional rate, with higher utility and authentication rates. - 1 Oct 2026: Kuwait and Oman get their own rates. Higher utility and authentication rates and a new authentication-international rate. Source: Meta, Pricing on the WhatsApp Business Platform; Conversation-based pricing (deprecated); WhatsApp changelog; Meta Terms for WhatsApp Business Platform; New pricing policy for AI Providers. All read 14 October 2026. The economics favour a particular shape of workflow. Answering is free; initiating costs money. An orders agent that replies to customers who wrote in, inside their window, sends nothing billable. A collections agent that sends a reminder to a customer who has not written in for a month sends a template, and pays for it. Each template carries a category, and the category sets the price [15], so reminder and confirmation templates are written and categorised with the same care as the agent itself. ### Consent, opting out and a person to talk to Meta's Business Messaging Policy, last updated on 23 September 2026, allows a business to contact a person only if the person has given it their phone number or username and has opted in to receive messages or calls from it, and requires the business to respect any request to stop, made on or off WhatsApp [17]. Automation is allowed when replying inside the 24-hour window, but the business must offer prompt, clear and direct ways to reach a person, such as a transfer to a human agent in the chat or a phone number [17]. The policy also forbids asking people to share full payment card numbers, financial account numbers or personal identity card numbers in the chat [17]. A collections agent therefore never asks for a card number; it sends a payment link or the bank details the customer already uses. ### What the terms say about AI providers Section 4.7 of the Meta Terms for WhatsApp Business Platform prohibits providers of large language models and general-purpose AI assistants from using the platform to offer those technologies when they are the primary, rather than incidental or ancillary, functionality on offer, as determined by Meta [18]. The restriction took effect on 15 January 2026, and from 16 February 2026 Meta charges AI providers for non-template messages in the countries where it is legally required to let them operate; it states that this does not change how it charges other businesses [19]. On our reading, an agent that takes orders for a distributor is ancillary to that distributor's business, which is selling goods, and so falls outside the restriction. Meta keeps the final word on that judgement, which is one more reason to keep each agent narrow: one process, for one company's own customers. ## 5. What arrives, and how an agent reads it The interface delivers each incoming message to the business's server as a webhook (A notification the platform sends to the business's server the moment something happens, such as a customer message arriving.) event with a type: text, image, audio, document, location and others. Each type poses a different reading problem. - Text. Arabic, English, or both in one sentence, often in Arabizi (Arabic written in Latin letters, with digits standing in for sounds Latin lacks, such as 3 for the letter ain and 7 for the pharyngeal h, ح.). Short replies carry the decisions: a single word can confirm an order. - Voice notes. Typically Ogg Opus audio, with a flag that marks a recording made with the app's voice feature [20]. Gulf dialect, road and shop noise, and product names said in English inside Arabic speech. - Photos. Handwritten lists, stamped delivery notes, a label with a part number. The interface supports images as JPEG or PNG files of up to 5 MB [21]. - Documents. Purchase orders, statements and invoices, most often as PDFs, which the interface supports up to 100 MB [21]. - Locations. A pin dropped for a delivery, which may or may not match an address on file. ### Voice notes WhatsApp said in March 2022 that its users send 7 billion voice messages a day on average [22]. That figure is global and four years old; we found no published measure of the share of voice notes in Gulf business messages. What is measured is how hard Gulf speech is for current models. In the Casablanca benchmark, Whisper large-v3 transcribed Emirati speech from television series with a word error rate (The share of words a speech recogniser gets wrong, counting substitutions, deletions and insertions against a human transcript. It can exceed 100 percent when a system inserts many extra words.) of 62.31 percent, or 52.88 percent after the authors' text normalisation, and the authors report high error rates for every model on every dialect when tested without dialect training [5]. Models have improved since 2024, and a voice note about cartons of cream is a narrower task than television dialogue, but the number sets the right expectation: a transcript of a Gulf voice note is evidence to be confirmed, not a fact to act on. The design follows. The agent transcribes the note, extracts the items, quantities, dates and names, and sends back a written summary for the customer to confirm. In our design, quantities and prices are not acted on from speech alone. The original audio, the transcript and the summary the customer confirmed are kept together in the record, so anyone who checks the order later hears what the customer said. ### Photos and documents A photo of a handwritten list combines the hardest parts of document reading: handwriting, Arabic and Western digits on one page, crossings-out, brand names in two scripts and units written by habit. We know of no public benchmark built from photographed Gulf order lists, so we make no claim about how well any model reads them. The rule is the same as for speech: the agent reads what it can, matches each line to the customer's catalogue and past orders, and marks any line it cannot read with confidence as unread. It asks about that line; it does not guess. A PDF purchase order generated by a buyer's system is usually easier to read than a scan, and either way the agent checks the buyer's order number against the record first. ### Keep it on arrival Media does not wait. The address Meta gives for downloading a received file expires after five minutes, and since 9 October 2025 the identifier for a file received by webhook expires after seven days, down from thirty [21, 23]. An agent that means to log every message to the record downloads and stores each voice note, photo and document the moment it arrives, in the record kept in the customer's country, and never treats the chat app as the archive. ### An illustrative order Table 2 is an illustrative example written by us, not a real exchange: a café in Muscat orders from a food distributor before opening. The original messages would be in Gulf Arabic; the content column gives them in English. **Table 2. An illustrative order arriving as a voice note, a photo and a location pin, and what the agent does with each message. Written by us; not a real customer's exchange.** | Time | Message | Content | What the agent does | | --- | --- | --- | --- | | 07:42 | Voice note from the owner, 41 seconds | Same as last Thursday, but double the cooking cream and add two cartons of mozzarella. The driver has to come before ten, we open at ten. | Stores the audio, transcribes it, reads last Thursday's order from the record, notes the deadline. | | 07:43 | Photo of a handwritten list | Five lines on a notepad, quantities in Arabic digits; the fourth line crossed out and rewritten. | Matches four lines to the catalogue; marks the rewritten line as unread. | | 07:43 | Location pin | A pin that matches no delivery address on file. | Holds the address as unconfirmed. | | 07:44 | Agent reply, in Arabic | A numbered summary of the draft, one question on line four, one on the address. | Inside the window: no template, no charge. | | 07:52 | Text, Arabic in Latin letters | Line four is labneh, 2 kg. Yes, the new branch in Al Khuwair. | Updates the draft and the account; checks stock and credit in the ERP. | | 07:53 | Request to the sales manager | The order would take the account over its credit limit. | Sends the case, what it read and the rule that stopped it; waits. | | 08:04 | Approval on the manager's phone | Approved. | Writes the sales order to the ERP; logs who approved and when. | | 08:05 | Agent confirmation, in Arabic | Order number, items, quantities, delivery before 10:00 at the new branch. | Logs every message, the voice note and the photo against the order. | | 09:41 | Photo from the driver | The signed delivery note at the branch. | Marks the order delivered; sends the PDF invoice in the same thread, inside the window. | Illustrative. The approval step is the one in Figure 4. ## 6. From message to order Figure 4 generalises the example. Every step but one is the agent's work, and every step writes a line to the record. The one step that is not the agent's is the decision above a threshold the customer set. **Figure 4. From a WhatsApp message to an order in the ERP and a confirmation back** Follow the arrows from the customer's message at the top to the confirmation at the bottom; the dashed arrow is the question the agent asks back when it cannot read something, and the accented node is the one place a person decides. - Customer message: Voice, photo, PDF, pin - Store and read: Keep file, transcribe - Match to the record: Customer, items, address - Ask the customer: The reply comes back in - Draft the order: Stock and credit checked - A person approves: Above the thresholds - Write to the ERP: The sales order - Confirm on WhatsApp: In their language - Log to the record: Every message and file - Customer message → Store and read - Store and read → Match to the record - Match to the record → Ask the customer (unclear) - Match to the record → Draft the order - Draft the order → Write to the ERP (within) - Draft the order → A person approves (above) - A person approves → Write to the ERP (approved) - Write to the ERP → Confirm on WhatsApp - Confirm on WhatsApp → Log to the record Qantara's design, illustrative. Within the customer's thresholds the agent writes the order itself; above them it waits for a person. Every node writes to the record and its log. Three details decide whether the flow can be trusted. First, identity. Policy now speaks of a phone number or a username [17], and in practice one customer account has several people writing for it: the owner, a buyer, a driver. The agent maps each sender to an account and a role, and a new number is asked who it is before anything is ordered on an account's credit. Second, the confirmation. The agent replies in the language the customer wrote in, and the confirmation repeats what will be delivered, how much of it, where and when. If the customer's last message is more than 24 hours old, the reply has to be an approved template, so the agent's templates for confirmations, delivery notices and invoices exist in Arabic and English before the agent goes live. Third, the record. A chat history on a salesperson's phone leaves when the salesperson leaves, and the collections team cannot read it. Each message, file, transcript, draft, approval and confirmation is written to the record against the order, with who or what wrote it. When the collections agent later sends a reminder, it starts from what the orders agent wrote, and the customer's voice note is one click from the invoice it led to. ## 7. When a call is still better A chat is lean in the sense of media richness (A theory from organisation science that ranks channels by how much they carry at once: tone of voice, immediate feedback and several cues together. A conversation in person is the richest; a written form is the leanest.) theory: it carries words and pictures, slowly, one turn at a time. That is enough for uncertainty, and not enough for equivocality [4]. Our working list of situations in which an agent should hand the conversation to a person, who will often call, is short: - A dispute about what was delivered, or about a price already agreed. - A complaint where the customer is upset, whatever its size. - A second misunderstanding on the same order: two rounds of questions is the limit. - A request outside the agent's process, such as a new credit line or an exception to terms. - Anything about safety, a spoiled cold chain or an injured driver. Customers say the same. In the UAE poll cited in section 3, 87 percent wanted a real person rather than a chatbot or AI [13], and Meta's policy requires a clear path to a person whenever automation answers [17]. Since July 2025 a business can take and make WhatsApp calls through the same interface [23], so the handover can stay in the thread the customer already uses. The agent hands over everything it read: the messages, the files, its transcript and what it was unsure of, so nobody asks the customer to repeat anything. What is agreed on the call is then written to the record, because a decision made on a call that leaves no record is the gap this design exists to close. ## 8. Implications for deployment For a Gulf company putting agents into its operations, the evidence points to five practical rules. This is also how Qantara approaches the work. 1. Start where the customer writes first. Orders and inquiries arrive inside the customer's window, where replies are free and the customer is waiting. Outbound work needs templates written, categorised and approved in Arabic and English first. 2. Write down how orders really arrive. Which numbers, which groups, which salespeople's phones, who sends voice notes and who sends PDFs. Qantara's engineers do this on site, inside the customer's operation, and record a baseline before anything is built. 3. Test on the customer's own messages. Each agent is run on the company's past cases before it goes live, voice notes and photographed lists included, with the company's team marking what good looks like. 4. Put the threshold where the risk is. Credit limits, new delivery addresses, prices outside the list: the customer sets the thresholds, and above them a person approves on their phone. 5. Log everything, and keep it in the country. Every message, file and approval is written to one record of how the company runs, kept in the customer's country, and each agent signs in with credentials of its own that can be revoked. For each workflow we state in writing which model reads the voice notes and photos, and where it runs. Two cautions. WhatsApp is Meta's service, and its terms, prices and interfaces change on Meta's schedule, as Figure 3 shows; a deployment needs someone whose job includes reading the changelog. And the channel's convenience is also its risk: an agent that can write an order into an ERP from a voice note has to be held to the same controls as the salesperson who used to type it in. ## 9. Limitations The central gap is that no public source we found measures how much Gulf business-to-business ordering runs on WhatsApp, by sector or by size of firm. Our usage evidence is strong for consumers and adults in general and indirect for trade. A survey of Gulf distributors, contractors and manufacturers on how orders, confirmations and proofs of delivery reach them would test the hypothesis directly, and could weaken it for sectors where electronic data interchange or buyer portals dominate. The figures in Table 1 differ in base and method. GWI surveys internet users aged 16 and over online; the Saudi regulator's base is its own survey of users; the Ipsos figures come from online panels of about 500 adults; the Omani figure has no published base; the UAE business-contact figure comes from a poll commissioned by a vendor with an interest in the result. The GWI figures published by DataReportal cover only two of the six GCC states, and we found no recent figure for Bahrain. Meta's rules and rates change quarterly, and everything in section 4 is as read on 14 October 2026. Our reading of the AI providers clause is ours, not Meta's. The speech recognition numbers come from a 2024 benchmark of television dialogue rather than voice notes recorded in a van, and newer models may do better or, on noisy audio, worse. We cite no benchmark for photographed handwritten order lists because we know of none. The order in Table 2 and the flow in Figure 4 are illustrative, and this paper reports no Qantara deployment or result. ## 10. Conclusion WhatsApp is close to universal among the working-age adults of the Gulf, and Meta's rules now make it cheap to answer a customer and costly to interrupt one. That combination makes the chat thread the natural place for an agent to take orders, answer questions and collect proof of delivery, and it means the agent must read what people actually send: voice notes in dialect, photographed lists, PDFs and pins. The models for reading them are good enough to try and not good enough to trust unchecked. The design that follows is plain. Store every message on arrival, read it, confirm what matters in writing in the customer's language, ask when unsure, stop at the customer's thresholds for a person, write the order to the ERP, and log all of it to one record. The channel already carries the trade. The work is to give it a memory and a limit. ## References [1] Messina, C. (2015). Conversational commerce: Messaging apps bring the point of sale to you. Medium. https://medium.com/chris-messina/conversational-commerce-92e0bccfc3ff (accessed 14 October 2026) [2] De, A. (2025). "Business on WhatsApp is tough now -- but am I really a businesswoman?" Exploring Challenges with Adapting to Changes in WhatsApp Business. Proceedings of CHI 2025, ACM; arXiv:2502.10913. https://arxiv.org/abs/2502.10913 [3] Jensen, R. (2007). The Digital Provide: Information (Technology), Market Performance, and Welfare in the South Indian Fisheries Sector. Quarterly Journal of Economics 122(3), 879-924. https://doi.org/10.1162/qjec.122.3.879 [4] Daft, R. L. and Lengel, R. H. (1986). Organizational Information Requirements, Media Richness and Structural Design. Management Science 32(5), 554-571. https://doi.org/10.1287/mnsc.32.5.554 [5] Talafha, B., Kadaoui, K., Magdy, S. M., et al. (2024). Casablanca: Data and Models for Multidialectal Arabic Speech Recognition. Proceedings of EMNLP 2024; arXiv:2410.04527. https://arxiv.org/abs/2410.04527 [6] Kemp, S. (2025). Digital 2026: Global Overview Report. DataReportal (Kepios, We Are Social and Meltwater), with data from GWI, second quarter of 2025. https://datareportal.com/reports/digital-2026-global-overview-report (accessed 14 October 2026) [7] Kemp, S. (2025). Digital 2026: The United Arab Emirates. DataReportal (Kepios, We Are Social and Meltwater), with data from GWI, second quarter of 2025. https://datareportal.com/reports/digital-2026-united-arab-emirates (accessed 14 October 2026) [8] Kemp, S. (2025). Digital 2026: Saudi Arabia. DataReportal (Kepios, We Are Social and Meltwater), with data from GWI, second quarter of 2025. https://datareportal.com/reports/digital-2026-saudi-arabia (accessed 14 October 2026) [9] Communications, Space and Technology Commission (2026). Saudi Internet 2025. Communications, Space and Technology Commission, Kingdom of Saudi Arabia. https://www.cst.gov.sa/en/knowledge-center/reports/saudi-internet-25 (accessed 14 October 2026) [10] Ipsos (2026). Spotlight*Kuwait: Views on Tech & Digital Trends. Ipsos in Kuwait & Bahrain. https://www.ipsos.com/sites/default/files/ct/news/documents/2026-07/Spotlight%20Kuwait%20-%20Views%20on%20Tech%20%26amp%3B%20Digital%20Trends%20.pdf (accessed 14 October 2026) [11] Observer Web Team (2025). Oman plans national framework for social media management. Oman Observer. https://www.omanobserver.om/article/1166373/oman/community/oman-plans-national-framework-for-social-media-management (accessed 14 October 2026) [12] Ipsos (2025). Spotlight*Qatar: Views on Tech & Digital Trends. Ipsos in Qatar. https://www.ipsos.com/sites/default/files/ct/news/documents/2025-07/Spotlight%20Qatar%20-%20Views%20on%20Tech%20%26amp%3B%20Digital%20Trends.pdf (accessed 14 October 2026) [13] Communicate Online (2024). 85 Percent of UAE Residents Want Businesses to Use WhatsApp. Communicate Online, reporting a YouGov poll commissioned by Zbooni. https://communicateonline.me/news/85-percent-of-uae-residents-want-businesses-to-use-whatsapp/ (accessed 14 October 2026) [14] Meta (2026). Pricing on the WhatsApp Business Platform. Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/docs/whatsapp/pricing (accessed 14 October 2026) [15] Meta (2026). Template fundamentals. Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/overview/ (accessed 14 October 2026) [16] Meta (2026). Conversation-based pricing (Deprecated). Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing/conversation-based-pricing/ (accessed 14 October 2026) [17] WhatsApp (2026). WhatsApp Business Messaging Policy. WhatsApp for Business, last updated 23 September 2026. https://whatsappbusiness.com/policy/ (accessed 14 October 2026) [18] Meta (2026). Meta Terms for WhatsApp Business Platform. Meta, last modified 23 September 2026. https://www.facebook.com/legal/Meta-Terms-for-WhatsApp-Business-Platform (accessed 14 October 2026) [19] Meta (2026). New pricing policy for AI Providers leveraging the WhatsApp Business Platform. Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing/ai-providers/ (accessed 14 October 2026) [20] Meta (2026). Audio messages webhook reference. Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/documentation/business-messaging/whatsapp/webhooks/reference/messages/audio/ (accessed 14 October 2026) [21] Meta (2026). Media. Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/media/ (accessed 14 October 2026) [22] WhatsApp (2022). We're Making Voice Messages Even Better. WhatsApp blog, 30 March 2022. https://blog.whatsapp.com/making-voice-messages-better [23] Meta (2026). WhatsApp changelog. Meta for Developers, WhatsApp Business Platform documentation. https://developers.facebook.com/documentation/business-messaging/whatsapp/changelog/ (accessed 14 October 2026) ## Cite this paper ```bibtex @techreport{qantara2026whatsappoperatingsystem, title = {WhatsApp is the Gulf's operating system}, author = {Qantara Research}, institution = {Qantara}, year = {2026}, month = {oct}, url = {https://qantara.systems/insights/whatsapp-operating-system} } ``` ## Disclosure Usage figures, Meta's rules and prices, and research findings are cited from the sources listed, each read on the date shown; the chart values are transcribed from those sources. The order in Table 2, the flow in Figure 4 and the deployment rules in section 8 are ours: they are illustrative and describe Qantara's approach, not a deployment or a result. Canonical: https://qantara.systems/insights/whatsapp-operating-system --- # The Gulf will skip the software era *The Qantara team. October 2026. 3 min read.* Most of the world's new AI is being sold to companies that already run on software. In the United States and Europe, decades of investment put operations into systems of record. The new generation of AI companies automates what those systems left behind. HappyRobot runs the calls, emails and scheduling behind supply chains and was valued at $1.2 billion in August 2026.[^1] Distyl pairs forward-deployed engineers with its own software and was valued at $1.8 billion in 2025.[^2] Wonderful, founded in 2025, sends deployment teams to its customers and raised at a $5 billion valuation in September 2026.[^3] The thesis is proven. The open question is where it moves the most. Much of the Gulf's operating economy never went through the software era. A delivery note is printed, signed on a tailgate and stamped. A shortage is written in Arabic in the margin. A branch manager photographs it and sends it on WhatsApp. Someone types it into a spreadsheet that the next branch never sees. Decisions that move trucks, parts and money are made on calls that leave no record. In the West, AI is an upgrade to a system that already exists. Here, it can be the first system. There is nothing to migrate and nothing to rip out. The distance between how the work is done today and how it could be done is longer, and every deployment covers more of it. The economy is also organized differently. Across the Gulf, much of the private sector sits inside family groups that run car distribution, heavy equipment, construction, trading and services under one roof. A decision at the top of a group reaches many companies at once. And because groups across the region own the same kinds of businesses, a workflow that works in one distributor's after-sales operation can work in the next. Silicon Valley has built the products. They rarely cross. The obstacles are not technical. Arabic and English share the same form. Data must stay in the country. Procurement runs on references and pilots.[^4] And someone has to be there, on site, at the start of the working day. The missing piece is not invention. It is deployment. That is what we build. Qantara puts forward-deployed engineers inside Gulf companies, brings in the right AI from Silicon Valley for each workflow, and makes it work in Arabic and English, on the company's own data, inside its borders. For the Silicon Valley companies whose products we deploy, we are the way into a market they could not reach alone. Every deployment writes to one operating record: what moved, where, when, for whom, at what cost, and why. We build the record; the customer owns it. It is what turns a series of projects into a system. The first workflow is the hardest. Every one after it starts from what the record already knows. We think of it as an arch. Each deployment is a stone. Our engineers are the frame that holds the stones while they are set. The record is the keystone. Once it is in place, the frame comes away and the arch carries itself. The region has been explicit about where it is going. Oman's sovereign wealth fund runs a $5.2 billion Future Fund to diversify the economy.[^5] Governments in Saudi Arabia and the United Arab Emirates are setting AI adoption targets from the top.[^4] What is missing is the layer between that ambition and a delivery note on a tailgate. The Gulf will not adopt AI the way the West did, one system at a time over decades. It will skip the software era and go straight to operations that run on AI. Someone has to build the bridge. We named the company after it. ## Sources [^1]: Fortune, HappyRobot is worth $1.2 billion, August 2026. https://fortune.com/2026/08/04/happyrobot-worth-1-2-billion-founder-says-just-getting-started/ [^2]: Shopifreaks, Distyl AI raises $175M at a $1.8B valuation, September 2025. https://www.shopifreaks.com/distyl-ai-raises-175m-at-1-8b-valuation-to-expand-ai-consulting-services/ [^3]: The SaaS News, Wonderful raises $550M Series C, September 2026. https://thesaasnews.com/news/wonderful-raises-550m-series-c [^4]: Grey Radius, Gulf enterprise AI deployment: procurement, residency and government adoption. https://greyradius.com/industries/technology/gulf-enterprise-ai-deployment.html [^5]: AAP, Oman's US$5.2 billion Future Fund unveils US$1.744 billion in projects, July 2026. https://www.aap.com.au/aapreleases/cision20260715ae04184/ [Request an introduction](https://qantara.systems/original/contact) / [Apply to deploy](https://qantara.systems/original/engineers) --- This is the Markdown twin of the page at https://qantara.systems/original/thesis --- # Privacy notice Effective 15 October 2026. Version 2.1. Applies to: this website and messages sent to us. How Qantara handles personal data when you visit qantara.systems or write to us. It does not cover the data we process for customers under a written agreement; that agreement governs it. ## At a glance - We collect what you send us through a form or by email, and the technical data every website receives when you visit it. - We use it to reply to you, to run and secure the site, and to count visits in aggregate. - This site sets no cookies, stores nothing in your browser and shows no advertising. - We do not sell, rent or share your details for anyone else's use. Two providers process them on our instructions: our host and our email delivery service. - You can ask to see, correct or delete what you have sent us at any time, at hello@qantara.systems. ## 1. Who we are *In short: Qantara decides how the personal data described here is used, and answers for it.* This notice is issued by Qantara ("we", "us"). We decide why and how the personal data described here is processed, so we are responsible for it. We are based in Muscat, Oman, and work across the Gulf. For anything about your personal data, write to hello@qantara.systems. ## 2. What this notice covers *In short: This website and the messages you send us. Not the data we handle for customers.* It covers personal data we collect when you visit qantara.systems, read its pages or their Markdown copies, or write to us through a form or by email. When a company engages us, we work on data in its own systems on its instructions, under a written agreement. That agreement, and the customer's own privacy notice, govern that data. How we handle it is described on our [Data security](https://qantara.systems/company/trust) page. ## 3. What we collect *In short: What you choose to send us, and the technical data a visit leaves at our host.* **Personal data we collect, and where it comes from** | Category | What it includes | Where it comes from | | --- | --- | --- | | Your message | Your name; your company (optional); your email address, or a phone or WhatsApp number if you ask us to reply that way; who introduced you (optional); what you write; and, for an application, the role you are applying for. | You, through the contact form, the careers form or an email. | | Technical data | Your IP address, browser and device type, the page requested, the page you came from, and the time of the request. | Your browser, automatically, recorded in our host's server logs. | | Visit counts | Pages viewed, the site you came from, your country, browser and device type, counted in aggregate without cookies. Visits are told apart by a daily code that is discarded after 24 hours and does not identify you. | Your browser, automatically, through our host's web analytics. | We do not ask for sensitive personal data, such as health, religious belief or financial account details. Please do not send it through the forms. ## 4. Why we use it *In short: To answer you, to keep the site running and secure, and to know which pages are read.* **Each purpose, the data it uses, and the ground it rests on** | Purpose | Data used | Ground | | --- | --- | --- | | Reply to your message and follow up on what you asked | Your message | Your explicit consent, which you give when you send it and can withdraw at any time; once we agree to work together, our contract with you | | Consider your application | Your application and the role you chose | Your explicit consent, which you give when you send it | | Deliver, secure and fix the site | Technical data | Delivering the pages you request, and our legal duty to protect personal data | | Learn which pages are read | Visit counts | Aggregated statistics that do not identify you | | Meet a legal obligation or answer a lawful request from an authority | Any of the above, only as required | A legal obligation | We do not use what you send us for advertising, we do not sell it, and we make no decision about you by automated means alone. We send no marketing material unless you separately ask for it, and you can stop it at any time. ## 5. Cookies and similar technologies *In short: None. The site sets no cookies and stores nothing in your browser.* This site sets no cookies and writes nothing to your browser's storage. Its fonts, photographs and video are served from our own domain, so reading it sends no request to a third-party font or media service. Our analytics count visits without cookies and without identifying you, and nothing on this site tracks you across other sites. Because no cookies are set, there is no cookie banner to accept. If you choose to open a page in an AI assistant from our agent view, the assistant's own terms and privacy notice apply to what you do there. ## 6. Who processes it for us *In short: Our host and our email delivery service, on our instructions. Nobody buys it.* **Service providers that process personal data for this site** | Provider | What it does for us | Where it processes data | | --- | --- | --- | | Vercel Inc. | Hosts the site, keeps its server logs and counts visits without cookies | United States, and the servers of its network in other countries | | Resend (Plus Five Five, Inc.) | Delivers the messages you send through our forms to our mailbox | United States | | Our email provider | Holds our mailbox, where your message arrives and our reply is sent from | As set out in its terms | Each provider processes the data only to provide its service to us, under its terms with us. We do not sell, rent or share your details for anyone else's marketing. If you ask us to reply on WhatsApp, the conversation also passes through WhatsApp, which Meta operates under its own terms and privacy policy. We may disclose personal data where the law requires it, to answer a lawful request from a court or an authority, or to protect our rights, our users or the public. If Qantara is reorganised or acquired, personal data may pass to the successor, which would remain bound by this notice. ## 7. Transfers outside your country *In short: Our providers process data in the United States, so your data may leave Oman and the GCC.* Because our host and our email delivery service process data in the United States and on servers in other countries, personal data you send us may be processed outside the country you are in, including outside Oman and the other GCC states. We transfer personal data abroad only as the applicable law allows, with the safeguards it requires, such as contractual commitments from the provider. Oman's law asks for your explicit consent to a transfer abroad; each of our forms asks for it, next to its send button. You can ask us what safeguards apply to a transfer. ## 8. How long we keep it *In short: Only as long as we need it, then we delete it.* **How long each kind of data is kept** | Data | How long | | --- | --- | | Your message and our correspondence | As long as we need it to deal with your request and any relationship that follows from it, and as long as the law requires us to keep records; then deleted. | | An application | As long as needed to consider it and, with your agreement, for future roles; then deleted. | | Server logs | A short period set by our host for running and securing the site. | | Visit counts | Kept in aggregate, which does not identify you. | You can ask us to delete your message sooner, at hello@qantara.systems. ## 9. How we protect it *In short: Encrypted in transit, seen only by the people who need it.* The site is served only over an encrypted connection, enforced by the browser. Access to messages you send is limited to the people at Qantara who need it to reply. Our providers protect the data under their own security commitments. If a breach of personal data occurs that the law requires us to report, we will notify the regulator and, where required, the people affected, within the time the law sets: 72 hours under Oman's law. How we protect our customers' data in a deployment is set out on our [Data security](https://qantara.systems/company/trust) page. ## 10. Your rights *In short: You can see, correct and delete your data, withdraw consent, and complain to the regulator.* Depending on the law that applies to you, you have the right to: - know what personal data we hold about you and receive a copy of it; - have inaccurate or incomplete data corrected; - have your data deleted when it is no longer needed, or when you withdraw consent; - receive your data in a form you can pass to another organisation; - withdraw your consent at any time, without affecting what we did before you withdrew it; - object to, or ask us to limit, how we use your data; - be told about a transfer of your data abroad and the safeguards that apply to it; - be told of a breach of your data that puts you at risk; - object to a decision made about you by automated processing, and have a person review it; - complain to the data protection regulator where you live. To use any of these rights, write to hello@qantara.systems. We may ask you to confirm your identity first. We answer within the time the law that applies to you sets (45 days under Oman's law), and we do not charge for it. If you live in another GCC state, you keep any further rights its law gives you. **Data protection laws and regulators in the GCC** | Country | Law | Regulator | | --- | --- | --- | | Oman | Personal Data Protection Law, Royal Decree 6/2022, as amended by Royal Decree 68/2026, and its Executive Regulation, Ministerial Decision 34/2024 | Ministry of Transport, Communications and Information Technology | | Saudi Arabia | Personal Data Protection Law, Royal Decree M/19 of 2021 | Saudi Data and AI Authority (SDAIA) | | United Arab Emirates | Federal Decree-Law 45 of 2021 on the Protection of Personal Data; the DIFC and ADGM have their own laws | UAE Data Office; DIFC Commissioner of Data Protection; ADGM Office of Data Protection | | Qatar | Law 13 of 2016 on Personal Data Privacy Protection | National Cyber Security Agency | | Bahrain | Personal Data Protection Law, Law 30 of 2018 | Personal Data Protection Authority | ## 11. Children *In short: This site is for businesses and is not meant for children.* We do not knowingly collect personal data from anyone under 18. If you believe a child has sent us personal data, write to hello@qantara.systems and we will delete it. ## 12. Changes to this notice *In short: Any change is posted here, with a new version and date.* When we change this notice, we post the new version here, with its effective date and a line in the version history below. Earlier versions are available on request. ## 13. Version history | Version | Effective | What changed | | --- | --- | --- | | 2.1 | 15 October 2026 | Grounds for each use aligned with Oman's law as amended by Royal Decree 68/2026 (explicit consent, contract, legal obligation); consent to transfers abroad asked for on the forms; 45-day answers and 72-hour breach notices; the rights to portability, to be told of a breach and to object to automated decisions; marketing only on request; WhatsApp replies; how visits are counted. | | 2.0 | 15 October 2026 | Rewritten in full: who we are, scope, a table of what we collect and why, the providers that process data and where they are based, transfers abroad, retention, security, rights under the GCC laws, children, and this history. | | 1.0 | 8 October 2026 | First notice: forms, aggregated analytics, no cookies, rights and changes. | ## 14. Contact us about privacy Write to us about this notice, your personal data or a request under your rights. hello@qantara.systems Canonical: https://qantara.systems/privacy --- # Website terms Effective 15 October 2026. Version 2.1. Applies to: everyone who visits or reads this website. The terms on which qantara.systems is offered. Any work with Qantara is agreed separately, in writing, and that agreement prevails over these terms. ## At a glance - This site is information about Qantara, not an offer. Any engagement is agreed separately, in writing. - You may read, link to and quote this site, including our research, with credit and a link to the page. - AI agents are welcome to read the site, within robots.txt and at a reasonable pace. - Examples, documents and figures marked illustrative describe no real company. - Other companies' names and logos belong to them, and showing them does not mean they endorse us. ## 1. About these terms *In short: Using the site means you accept these terms.* These terms apply to qantara.systems, including its pages, their Markdown copies, its feeds and its forms ("the site"), which Qantara ("we", "us") offers. By using the site, you accept them. If you do not accept them, please do not use the site. How we handle personal data is set out in our [privacy notice](https://qantara.systems/privacy), which forms part of these terms. ## 2. What this site is *In short: Information about how Qantara works, and a way to reach us. Not an offer.* The site describes Qantara, its approach and its research, and lets you get in touch. Nothing on it is an offer, a quotation or a commitment to provide a service. Sending a form is a request to talk. It creates no obligation on either side. Any engagement is agreed in a separate written agreement, which governs that work and prevails over anything on the site. ## 3. Using the site *In short: Use it lawfully, and do not interfere with it or with other people's use of it.* You may use the site for any lawful purpose. You agree not to: - attack, overload, probe or try to break the site or the systems behind it, or get around its security; - send unlawful, misleading or harmful content through the forms, or use them to send unsolicited messages; - use the site to collect other people's personal data; - present yourself as Qantara, or suggest an association with us that does not exist. We may restrict access from any source that breaks these terms. ## 4. Reading by AI agents *In short: Agents may read, index and summarise the site. Cite the page you used.* Software that reads on someone's behalf, including AI assistants, search engines and crawlers, may read, index and summarise the site, within the rules in [robots.txt](https://qantara.systems/robots.txt) and at a rate that does not disrupt it. A Markdown copy of every page, an index and the whole site in one file are provided for this; see [For AI agents](https://qantara.systems/agents). Where a summary or an answer draws on the site, it should cite the page used, keep the label of anything marked illustrative and keep the date of any figure, price or law it quotes. Where an AI summary differs from the page, the page prevails, and our legal pages and any signed agreement prevail over the rest of the site. ## 5. Our content and how you may use it *In short: The content is ours. Quote and share it with credit and a link.* The text, research, figures, photographs, design and code of the site belong to Qantara or to those who licensed them to us, and are protected by copyright and other laws. The Qantara name and mark are ours. You may read the site, link to any page and share links to it. You may quote and cite our research and other content, with credit to Qantara and a link to the page. You may not republish whole pages or papers, present our content as your own, or use our name or mark in a way that suggests we endorse you. Sources quoted in our research belong to their authors and are cited so that you can read them where they were published. ## 6. What you send us *In short: Do not send confidential material through the forms.* Send only what you are entitled to share, and do not send other people's personal data without their agreement. Our [privacy notice](https://qantara.systems/privacy) protects the personal data you send. Beyond that, what you send through the forms is not treated as confidential business information unless we have agreed otherwise in writing, so please keep confidential material until an agreement is in place. ## 7. Other companies' names and logos *In short: They belong to their owners. Showing them does not mean they endorse us.* The site names and shows other companies' products and systems, such as the business systems our agents work with. Those names and logos are trademarks of their owners. We show them to say which systems we work with or which sources we cite; this does not mean their owners endorse Qantara or have a partnership with us, unless we say so. ## 8. Accuracy, illustrations and advice *In short: We keep the site true and current. It is not professional advice.* We keep every statement on the site true and current to the best of our knowledge, and we leave out claims we cannot yet stand behind. If you find something wrong, tell us and we will correct it. Documents, records, messages and figures marked illustrative are written by us to explain a point and describe no real company. Prices, scores, laws and figures in our research carry the date they were read and may since have changed. Nothing on the site is legal, financial, tax or other professional advice. Our guides to the law describe it in general terms; take advice on your own situation before you rely on them. ## 9. Links to other sites *In short: We do not control other sites and are not responsible for them.* The site links to other sites, including the sources our research cites and the AI assistants our agent view can open. We do not control those sites and are not responsible for their content, their availability or how they handle your data; their own terms apply. ## 10. Availability and changes to the site *In short: We may change or pause the site at any time.* We may change, suspend or withdraw any part of the site at any time, without notice. We do not promise that the site will always be available or free of errors. ## 11. No warranties *In short: The site is provided as it is.* To the extent the law allows, the site and its content are provided as they are and as available, without any warranty or representation, express or implied, including as to accuracy, completeness, fitness for a particular purpose or non-infringement. ## 12. Limitation of liability *In short: We are not liable for losses from using the site, as far as the law allows.* To the extent the law allows, Qantara is not liable for any loss or damage arising from your use of, or reliance on, the site or its content, including indirect or consequential loss, loss of profit, revenue, data or goodwill. Nothing in these terms limits or excludes any liability that cannot be limited or excluded under the law that applies, or any right you have as a consumer that cannot be waived. ## 13. Changes to these terms *In short: Any change is posted here, with a new version and date.* We may change these terms. The version posted here, with its effective date and a line in the version history below, applies from that date. If you keep using the site after a change, you accept the new terms. ## 14. Version history | Version | Effective | What changed | | --- | --- | --- | | 2.1 | 15 October 2026 | Added what you send us; the page, our legal pages and signed agreements prevail over AI summaries of the site. | | 2.0 | 15 October 2026 | Rewritten in full: acceptance, use of the site, reading by AI agents, use of our content, other companies' names and logos, accuracy and advice, links, availability, warranties, liability and this history. | | 1.0 | 8 October 2026 | First terms: what the site is, forms, accuracy, illustrations and links. | ## 15. Contact us about these terms Write to us about these terms, about using our content, or to tell us something on the site is wrong. hello@qantara.systems Canonical: https://qantara.systems/terms --- # This site is written for people and for the software that reads for them. Every page has a Markdown copy at its own address, one index lists them all, and one file holds the whole site. Use them to read Qantara accurately, and cite the page you read. ## What an agent can read Plain text, no scripts, no login. The same words as the pages, with figures written out as tables. - [/llms.txt](https://qantara.systems/llms.txt) (The index): Every page, grouped by section, with one line on what it says. Start here. - [/llms-full.txt](https://qantara.systems/llms-full.txt) (The whole site): Every page's Markdown in one file, each with its address, for a single read. - [.md](https://qantara.systems/company/trust.md) (Any page as Markdown): Add .md to a page's address: /company/trust becomes /company/trust.md. - [/insights/feed.xml](https://qantara.systems/insights/feed.xml) (The research feed): Every paper and essay, newest first, with its abstract (RSS 2.0). - [/sitemap.xml](https://qantara.systems/sitemap.xml) (Every page): The canonical address of every page, for crawlers. - [/robots.txt](https://qantara.systems/robots.txt) (What may be crawled): Every public page may be read; the form endpoint under /api/ may not. ## Ask an assistant about Qantara Each button opens the assistant with the site's index already in the question. Nothing is sent until you press enter there. Prompt: Read https://qantara.systems/llms.txt and use it to answer my questions about Qantara. Cite the page you used. ## How to read and cite us - **Cite the page.** Link the page you read, not the index. Each Markdown copy ends with the page's canonical address. - **Keep the labels.** Examples, documents and messages marked illustrative are written by us to explain a point. They describe no real customer. - **Keep the dates.** Prices, scores and laws carry the date they were read. Quote the date with the figure. - **Approach, not results.** What we say about Qantara describes how we work. We publish no customer results on this site. - **Two languages.** Arabic on this site is quoted as written. Do not translate a quoted example and present it as ours. - **Tell us what is wrong.** If something here is out of date or wrong, write to hello@qantara.systems and we will correct it. Canonical: https://qantara.systems/agents