Answer every customer in their own language.

What the AI will do

• Finds the languages your customers use, then researches the latest useful models for each before choosing an approach.
• Searches customer correspondence and company policies, builds the response workflow, and tests its replies language by language.

What you can provide

• Access to the customer records and tools you already use; a few rough or anonymized examples can get it started.

Where you'll take part

• Choose the first languages and uses to support. Review test results and help arrange qualified language review where needed.
• Decide whether to activate the tested routes. Languages with weak evidence keep human review; some may remain unsupported for now.

What you'll get

A tested way to respond in the supported languages, with examples and a clear human review route. If integration is unavailable, you receive a working prototype and the precise remaining connection steps.

Activity context

A customer should be able to explain a problem in the language they know best—and receive a useful answer in it. AI is opening that possibility to more languages, quickly, but it has learned far more from some languages than others. French, Spanish and Portuguese deserve their own tests; a language with much less digital training material, such as Tibetan, may require a person who can check every reply. Start by finding what works now for your actual customers.

For the user

Start with the support tools or customer conversations you already have. The AI will discover the languages, investigate current models, recover the service knowledge and build a practical first version. You will choose its scope and assess the examples; a qualified speaker may need to check the language. Sending begins only for the routes you authorize after testing.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Build a way to answer customers in their own language

Help me build and test a multilingual customer-response workflow suited to my organization. Do the research, recover company context, construct the workflow and test it. The goal is useful replies that preserve both the customer's meaning and our actual commitments. Establish language support one language at a time; a polished sentence or a model's broad “multilingual” claim does not establish that it can handle our customers' needs.

Find the languages, then research what works now

Inspect the relevant connections and supplied material. Search recent support tickets, incoming customer emails, accessible chat or WhatsApp conversations, CRM language preferences and existing translation arrangements to identify the languages people actually use. Distinguish a stated preference from a language you inferred. Include regional varieties, scripts and mixed-language messages where they matter. Identify the channels and product areas involved; ask one focused question if the records leave the intended scope unclear.

Before choosing a model, search for the latest useful models and translation systems for each identified language. Search using the language's name and native name where helpful, together with terms for evaluation, instruction following, translation, customer support and relevant regional varieties. Examine current provider documentation, model cards, research papers and evaluations with identifiable methods. Compare available general models with relevant multilingual or language-specialist alternatives. “Best” means promising for this language and job, available in our setup, and supported by appropriate evidence—not simply highest on an overall leaderboard.

Explain the data gap briefly. A model's experience depends partly on the text available to train it, and language coverage varies dramatically. Widely spoken languages can receive very different amounts of training material. Do not present English and Chinese as equal, or automatically put French, Spanish and Portuguese in the same category as Tibetan. Use documented model-specific evidence; say when the training mix is undisclosed. These sources offer starting points, not a current ranking:

• The BigScience ROOTS paper documents one historical multilingual corpus in which English and Simplified Chinese had larger shares than French, Spanish and Portuguese. Those proportions describe that corpus, not today's models.
• Cohere's Tiny Aya documentation is an example of current language coverage and regional variants to investigate. Check its actual language list and compare its claims against relevant tests; inclusion alone is insufficient.
• The 2025 TLUE Tibetan evaluation found substantial limitations in the tested models. Treat this as dated evidence of the need for testing and knowledgeable human oversight, not a permanent verdict on every future model.

This technology is developing quickly. Date the research and record exact model versions. Keep documented capability, independent evidence, vendor claims and our own test results separate. If web research is unavailable, use accessible current documentation or request specific links; label the model selection provisional.

Recover the service knowledge that replies must preserve

Search support email and chat threads, agent notes, escalation conversations, account histories, service policies, product documentation, approved templates, localization glossaries and relevant meeting transcripts. Find what customers ask, how successful answers resolve those needs, what wording customers found confusing, and who can authorize refunds, dates or exceptions. Use actual correspondence to understand terminology, preferred forms of address and expressed customer concerns; avoid cultural stereotypes.

Inspect dates and policy versions. Build a compact source-linked reference of approved facts, commitments and terminology. Keep unresolved contradictions visible. Find existing bilingual staff, localization owners or translation services through project records and directories. Identify the specific review expertise needed; do not assume a colleague's native language or availability from their name.

If access is missing, try feasible permitted connections or exports before asking me to assemble anything. Explain precisely what is needed and why: for example, recent Portuguese tickets with their final resolutions and the applicable returns policy. A small anonymized sample is a usable beginning, but it cannot establish all customers' languages or organization-wide coverage. Make that boundary explicit and keep doing the work supported by the available material.

Design and construct the response workflow

Propose a manageable initial set of languages and case types from what you found. Show me the intended operation, any meaningful costs or setup decisions, and which languages need a qualified human reviewer. Ask for the consequential choice that remains and wait before implementing dependent work. Reuse existing tools where they fit.

Build the actual available workflow: read the customer's message, identify its meaning and language, retrieve relevant account and policy facts, produce the substantive answer, render it naturally in the customer's language, check it and route it appropriately. Compare direct in-language answering with translation around a grounded answer when the evidence makes both worth trying. Do not presume that translation through English preserves everything. Separate factual decisions from their wording so a translation cannot silently enlarge a promise.

Preserve names, product terms, amounts, dates, negation, conditions and uncertainties. When meaning is ambiguous, prepare a focused clarification rather than inventing the customer's intent. Include a review or escalation route for uncertain language identification, unsupported facts, weak language performance and cases requiring human authority. Unsupported languages must remain visible in a queue with an owner or next action; they must not disappear because automatic handling failed.

Use bounded subagents when helpful: language-specific researchers receive the target variety, task and source requirements; response builders receive the approved factual material; independent reviewers receive the actual messages and replies plus the applicable evidence, without the builders' defense. Collect citations, tested cases and unresolved issues from each. Work in successive waves if needed. Without subagents, make separate passes and state that independence was limited. An AI language reviewer is not a substitute for a competent human reviewer where the model's language ability is unproven.

Test each language on the work it will really do

Construct a small but varied test set from real resolved cases, keeping some cases out of development for the final check. Include ordinary questions and consequential details: a refund condition, a missed deadline, an upset customer, regional terminology, mixed languages and an ambiguous request, where these occur in our business. Synthetic edge cases can supplement the records; identify them as synthetic.

Run the candidate routes on the same cases where comparison is feasible. If another model cannot actually be invoked, distinguish research-based selection from a model comparison you ran. Record the original message, source-grounded intended answer, actual output, model and settings, reviewer judgment and required corrections.

Check two things separately: whether the reply solves the right problem using our real policies, and whether it says that accurately and naturally in the target language. Give a qualified fluent reviewer a concise packet of difficult cases, originals, intended meanings and specific uncertainties; have them assess accuracy, omissions, tone and dialect fit. Back-translation and another model's judgment can find problems, but cannot certify accuracy on their own. For low-resource languages with inadequate evidence, require human review of every proposed customer reply. If qualified review is unavailable, mark customer-facing use of that language blocked and preserve the prepared work.

Correct the route, glossary or prompts in response to findings, then rerun failed cases and the held-out set. Agree acceptance criteria appropriate to each language and case type. A handful of successes supports a bounded pilot, not a claim of universal reliability.

Deliver the usable system and its language boundaries

Present a clear per-language result: ready for the agreed limited use; usable with qualified human review; or blocked pending a named capability or reviewer. Show examples and the actual reasons. Where integration is available, verify the complete path in a test channel, including uncertain cases reaching the review queue. Customer sending requires my explicit authorization for the particular route and scope; do not infer blanket permission from this build request. If I authorize activation, activate the agreed routes and verify their operation.

When integration is unavailable, deliver the working file-based or app-based prototype, reviewed replies and a precise connection handoff; identify this as a prototype rather than a live system. Give me the prompts or configuration, source and glossary references, test record, review routing and an easy way to repeat the comparison after a model update. End with what customers we can now serve in their own language, what still needs a person, and what has actually been demonstrated.

Done when

You have a tested response workflow for a defined set of customer languages and needs, with real examples, a recorded model choice and clear routes for human review or unsupported cases. Its live, supervised or prototype status is explicit; passing one language never counts as passing them all.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.