Arabic across the complete task
Arabic-Native AI Agents
Design Arabic agent journeys across retrieval, tool arguments, dates, terminology, bidirectional display and domain review, with a worked test contract.
An Arabic-native AI agent should complete the intended work naturally and accurately in Arabic, including the evidence, tool arguments, clarification and handoff. Translating the final answer is only one part of that job. A system can sound fluent while choosing the wrong date, changing an identifier or losing an exception when it calls an English-labelled tool.
The term “Arabic-native” can describe a model's development or a product's user experience; buyers should ask which meaning is intended. This guide uses it as a design goal for the complete service. It is written for Saudi product teams and organisations serving Arabic-speaking users, without assuming that one dialect, model or hosting arrangement fits every customer.
Define the language journey, not a language checkbox
Map the actual combinations: Arabic requests over Arabic sources, Arabic requests over English sources, English requests requiring Arabic outputs and messages that mix both languages. Add document formats, voice only if it is in scope, and the language used by the receiving business team.
A service team may use Arabic conversation while its product catalogue, ticket fields and technical identifiers remain in English. The agent needs to preserve meaning across those boundaries. Translating every token can be as damaging as translating nothing, especially for official names, part numbers and system identifiers.
Choose a response register appropriate to the task. Professional Modern Standard Arabic is often a practical written baseline, while the system may need to understand natural colloquial input. Do not imitate a user's dialect mechanically or infer personal characteristics from it. The required coverage should come from the intended audience and observed permitted examples.
Evaluate tool use separately from linguistic fluency
The research paper Arabic Prompts with English Tools studies Arabic tool-calling behaviour. Its results concern the evaluated setup; they do not predict the accuracy of your deployed agent. The useful engineering lesson is to test the actual language-to-tool boundary.
A model may correctly explain a request in Arabic yet place the wrong value in a structured argument. Inspect the selected tool, field mapping, preserved identifiers and final destination state. A fluent summary of an incorrect booking is still an incorrect booking.
General language benchmarks answer different questions. ArabicMMLU evaluates broad Arabic language understanding through multiple-choice tasks. Such evidence can inform model investigation, but it does not replace evaluation of your permissions, retrieval sources or business actions.
Worked language contract: a maintenance appointment
Consider this illustrative request: “أبغى موعد للصيانة يوم 12/11، بعد الظهر، ولا تغيّر العنوان المحفوظ.” The user wants a maintenance appointment, gives an ambiguous numeric date, prefers the afternoon and explicitly forbids changing the stored address. A useful agent preserves all of those facts.
The system should clarify the date and calendar when the context does not establish them. It should ask what time range “afternoon” means if the booking system requires a precise slot and no approved convention resolves it. It must not treat checking availability as permission to confirm a booking or alter the address.
Once clarified, the application should pass canonical date and slot values to the booking tool while keeping the user's original wording available for review where appropriate. The address remains unchanged unless a separate authorised request changes that boundary. This is a proposed design, not a claim of a tested service.
| Input detail | Required interpretation | Failure to catch |
|---|---|---|
| “12/11” without a clear calendar or date convention | Clarify the intended date | Silently assume a month, day or calendar |
| “لا تغيّر العنوان المحفوظ” | Preserve the prohibition on address changes | Update the address while completing another task |
| “رقم الوحدة 04، وليس 40” | Preserve the identifier 04 and the correction | Convert the identifier into 40 or remove meaningful formatting |
| Building reference “B-17” inside Arabic text | Keep the exact reference through retrieval and tool use | Translate, reorder or partially drop the reference |
| A later message changes only the time preference | Retain the other confirmed constraints | Reset the address restriction or date clarification |
Build retrieval around the source's meaning
Arabic search needs to be assessed on the actual corpus. Test spelling variants, abbreviations, mixed-language terms and alternative expressions that users employ. Do not assume that translating the query into English always improves retrieval; it can lose a distinction present in the Arabic source or introduce an unsupported term.
Keep original source text and metadata available. Normalisation can help matching, but destructive transformation of names or identifiers can damage evidence. Apply normalisation selectively and retain a path back to the original record. Exact identifiers need exact handling even when surrounding prose benefits from flexible search.
For bilingual policies, decide which version is authoritative and how inconsistencies are resolved. Do not silently merge conflicting versions into a single answer. If both are approved but disagree materially, the agent should surface the conflict to the source owner. The requirements checklist provides a way to make this behaviour testable.
Create a terminology record with business owners
Maintain important terms with their approved meaning, preferred Arabic rendering, common user expressions and identifiers that must remain unchanged. Include examples where a term is ambiguous. A word may mean an appointment, a deadline or a commitment depending on the workflow.
The record should distinguish ordinary explanation from controlled wording. An assistant may simplify a technical concept for a customer, but it should not soften a mandatory condition into a suggestion or convert an exception into a general entitlement. Review negation, conditions and scope carefully.
Give terminology changes an owner and version. If a correction affects a policy explanation or tool mapping, add representative regression cases. A glossary is useful only when it stays connected to retrieval, output generation and evaluation rather than remaining an unused translation spreadsheet.
Design mixed-direction presentation as part of correctness
Arabic interfaces often contain Latin identifiers, dates, URLs and numbers. W3C's internationalisation guidance explains how bidirectional text needs appropriate direction handling in HTML. See the W3C guidance on inline bidirectional text.
Test the actual rendered interface, including copied values, form fields, error messages and exported documents. An identifier can be stored correctly but displayed confusingly next to punctuation. Users must be able to see which date, reference or amount they are approving.
Keep presentation decisions separate from data transformation. Reordering characters in the underlying identifier to make one screen look right can corrupt the value sent to a tool. The application should preserve canonical data and use appropriate display handling. This distinction matters in both web interfaces and generated review artifacts.
Construct an evaluation set that reflects Saudi users
Gather permitted examples from the intended workflow, with appropriate removal of unnecessary personal information. Include formal Arabic, relevant colloquial phrasing, mixed-language messages, typographical errors and concise requests. Avoid claiming coverage of all Arabic dialects from a narrow set of examples.
Pair equivalent tasks across languages where comparison is useful, but allow natural wording. A literal translation may be grammatically correct yet unlike the way people ask for help. Reviewers should judge both whether the intended meaning was understood and whether the resulting operation was correct.
Separate scores for understanding, retrieval, argument accuracy, evidence support, clarification, tone and completion. Report critical failures independently. A strong average for polished Arabic answers must not hide incorrect dates or ignored prohibitions. The evaluation guide provides the broader test architecture.
Review with language and domain expertise together
A language reviewer can detect awkward phrasing; a domain reviewer can detect a misleading business conclusion. Some cases need both perspectives. Ask reviewers to identify the exact meaning change and its consequence rather than merely rating whether the text “sounds natural”.
Calibrate reviewers on examples with clear acceptance criteria. Distinguish a harmless style preference from a material change in eligibility, quantity or authority. Keep disagreements visible and resolve them through the source owner when they concern policy rather than language.
When using automated graders, check their agreement with qualified human review on the relevant cases. An automated judge may share the same language weakness as the system it evaluates. Treat it as a measurement tool requiring validation, not as an unquestionable Arabic authority.
Operate language support as a maintained capability
Track failures by language journey and task type after release, subject to the agreed data handling rules. A change to an English tool description can affect Arabic use even when the Arabic prompt remains unchanged. Reassess the complete path after material model, source or integration changes.
Keep language support separate from regulatory or hosting claims. Arabic output does not establish a data residency arrangement or compliance with a particular obligation. Assess those requirements for the actual organisation and processing flow; see data residency for Saudi agent projects.
For service journeys, the customer support guide addresses handoffs, while agent architecture explains the tool and identity boundaries. Open for AI can scope Arabic and English agent development around those requirements. To discuss an Arabic-first agent workflow, bring redacted natural requests, approved terminology and the exact fields the system must preserve.