Bilingual AI Agents: English and Portuguese in One Company

A bilingual AI agent serves English and Portuguese well when it shares one set of rules, one glossary and one memory, while tone and document conventions are written separately for each language. Treat language as a property of each conversation or document, not as a reason to build a second agent. Then test and review both languages against the same standards, so neither one quietly becomes the weaker one.

Key takeaways

• Write a language policy first: which language the agent replies in, which language records are kept in, and what happens when a message mixes both.
• Write the tone guide for each language from real company messages. Do not translate one guide into the other.
• Keep one approved glossary that names the correct term for each language and each Portuguese variant, and load it when the agent needs it.
• Preserve documents in their original language, label any translation as a draft, and treat the original as authoritative.
• Test and review each language separately, with reviewers who can actually judge the output, and escalate to a person when no one can.

Why does a bilingual agent need a language policy, not just translation?

Most bilingual failures are not translation errors. The agent replies in the correct language but uses the wrong register, the wrong word for a business document, or a date format the reader misreads. A model that can produce fluent Portuguese will still guess when your company has not told it what you mean by a given term or how you address a given client.

A language policy removes the guessing. It is a short document, owned by a named person, that answers the questions below. It sits alongside the agent's other operating rules, and if you keep those rules in a maintainable structure (see how to keep AI agent instructions maintainable), the language policy becomes one clearly labeled part of it.

Use this decision guide to draft it:

• Reply language: reply in the language of the most recent message from the person, unless their contact record sets a preference.
• Mixed messages: if a message contains both languages, reply in the language of the main request and keep quoted phrases as written.
• Internal records: choose one working language for notes, summaries and task titles, and keep the original message attached so nothing is lost.
• Unknown language: if the agent cannot tell the language with confidence, it asks a short two-language question rather than assuming.
• Outbound drafts: anything sent to a person in the other language than the requester's is a draft for approval until your team trusts it.
• Source of truth: for contracts, policies and official notices, the original language version governs, and the agent says so.

None of this requires a second agent. It requires that the agent can look up the language of the contact, the document or the thread, and behave accordingly. If you are still deciding how many agents your company needs, one company agent or one per team covers how roles should be divided, and language is rarely the right dividing line.

How should tone differ between English and Portuguese?

Tone is where bilingual agents most often sound slightly off. A direct English request can read as curt when carried over literally into Portuguese, and a warm Portuguese opening can read as padded when carried over into English. Rather than rely on general assumptions about each culture, collect evidence from your own company: ten or so real messages in each language that your team considers well written, covering a first reply, a follow-up, a delay, a refusal and a payment reminder.

From those, write a short tone sheet per language. Each sheet should cover:

• Greeting and closing patterns the company actually uses.
• Level of formality and how it changes by client type.
• How to make a request, decline one, and apologize.
• Phrases to avoid, such as expressions that sound like a template.
• How long a typical reply should be.

The Portuguese sheet needs one more decision: which Portuguese. European and Brazilian Portuguese differ in vocabulary, in pronouns and forms of address, and in how formal a business message sounds. Pick a default variant for the company, and store the variant on each contact record when it differs. A client in Brazil who receives a message written in the European variant will understand it, but may feel it was not written for them. If your clients span both markets, the agent should select the variant from the contact record, not from the model's habits.

Also decide how the agent addresses a person it does not know yet. In Portuguese this choice is more visible than in English, and a wrong guess is harder to undo once it is in a client's inbox. A safe default, plus a rule to follow the form the person uses first, works for most teams.

How do you keep terminology consistent across both languages?

Terminology is the second source of drift, and it is the most practical one to fix. Business words do not map cleanly between English and Portuguese, and they map differently between the two Portuguese variants. A few examples show why a glossary matters:

• Invoice: in Portugal the usual term is fatura, while in Brazil the nota fiscal is a specific fiscal document and not simply the same thing under another name. An agent that treats them as interchangeable can mislead a finance team.
• Quote: orçamento and proposta are both used, but they are not always the same stage of a sales process in your company.
• Appointment: marcação and agendamento are common in different markets, and your own team may use a third word.
• Mobile phone: telemóvel in Portugal, celular in Brazil.
• Payment slip: the boleto is a Brazilian instrument with no direct English equivalent, so the agent should keep the Portuguese word and explain it when needed.

Build the glossary as one shared list. Each entry records the English term, the approved Portuguese term for each variant you serve, a one-line definition in your company's sense of the word, and a note on whether the term should ever be translated. Product names, plan names, legal entity names and internal project names usually go on a do-not-translate list.

Where should the glossary live? Preferably outside the agent's main instructions, as a reference it retrieves when a conversation touches those terms. Your glossary changes more often than the agent's core behavior, and a retrieved reference is easier to update than behavior baked into the model. AWS describes this trade-off between retrieval and fine-tuning in its guidance on comparing the two, and Anthropic's writing on context engineering makes a related point: give the agent the information it needs for the task at hand, not everything at once. A short glossary excerpt that matches the conversation is more reliable than a long one the agent has to search through every time.

How should the agent handle documents in both languages?

Documents carry the highest risk because they are kept, forwarded and sometimes relied on legally. Set a few firm rules.

First, never replace the original. When the agent summarizes or translates a Portuguese contract for an English-speaking manager, the output is labeled as a working translation, links to the original, and states that the original governs. The same applies in reverse.

Second, retrieval across languages needs care. Modern models can often match an English question to a Portuguese passage, but exact terms, clause numbers and names are where mistakes hide. When the agent answers from a document, it should quote the relevant passage in its original language and then explain it, so that a reader can check the source.

Third, fix the formats that differ. Dates, decimal separators, thousands separators, address order, phone formats and tax identifiers all vary. Decide how the agent writes each one in each language, and make it copy identifiers exactly as they appear in the source rather than reformatting them. Check that names and addresses with accents and cedillas pass through every tool intact, since a broken character in a client's name is a visible error.

Fourth, consider where the data lives and which rules apply. Contacts in Brazil may fall under Brazilian data protection law, whose authority is the ANPD, and contacts in Portugal under European rules. The details depend on your situation, so confirm them with your legal adviser. For the infrastructure side, AI data residency for business explains the questions to ask about where company data is stored and processed.

What is a practical plan for setting this up?

Here is a sequence that a small team can follow without special tooling.

• Map your languages: list the channels, document types and client groups that use English, Portuguese or both, and note which Portuguese variant each group expects.
• Write the language policy: reply language, record language, mixed-language handling and source of truth, as described above.
• Collect examples: gather real messages and documents your team considers good, in both languages, and remove anything confidential.
• Write two tone sheets: one per language, each built from its own examples.
• Build the glossary: start with the terms your team corrects most often, and add the do-not-translate list.
• Add language to the contact record: preferred language and Portuguese variant, so the agent reads them instead of inferring them.
• Assign owners: one person who can judge English output and one who can judge Portuguese output, even if one person does both.
• Run a draft-only period: the agent prepares replies and a person approves each one, while you record every correction and its reason.
• Convert corrections into rules: each repeated correction becomes a glossary entry, a tone note or a policy line.
• Widen autonomy gradually: allow the agent to send on its own only for message types with a clean review record in both languages.

Illustrative scenario: a small company based in Lisbon sells services to clients in Portugal, Brazil and the United Kingdom. Its agent drafts replies to customer questions about billing. In the draft-only period, reviewers keep correcting the same thing: the agent writes fatura for Brazilian clients who are actually asking about a nota fiscal. The fix is not a better prompt. It is a glossary entry that separates the two documents, a contact field for the client's market, and a rule that the agent asks a person when the document type is unclear. After that, the correction stops recurring and the team moves on to the next most frequent one.

If you are planning the wider rollout, an AI agent rollout plan for small companies, in phases shows how to sequence this work alongside the rest.

How do you review and maintain quality in both languages?

Quality in two languages does not maintain itself. A single combined quality score can hide a weak language, so measure each language separately from the start.

Build a small test set of realistic tasks in each language, written by native speakers rather than translated from the other set. Include awkward cases: a message that mixes languages, a client who writes informally, a term with two meanings, a document with unusual formatting. Run the set whenever you change the instructions, the glossary or the underlying model, and compare results by language. Anthropic's guidance on evaluating agents and OpenAI's guide to evals both stress the same discipline: define what a good outcome looks like before you measure it. For a business-oriented version, see how to evaluate AI agents on real business tasks.

Review needs people who can actually judge the output. If your manager reads only English, they cannot approve Portuguese replies in good conscience. Either name a Portuguese-reading reviewer or restrict the agent to drafting Portuguese text that someone else approves. When the agent is unsure about language, term or register, it should pass a clear question to a person with the original text and its proposed reply attached, which is the pattern described in human escalation for AI agents.

Maintenance has a few recurring tasks:

• Review the glossary when products, plans or regulations change.
• Re-run the test set after any model or instruction change.
• Read a sample of real conversations in each language on a regular schedule.
• Track corrections by language and by cause, so you can see whether the fix belongs in the glossary, the tone sheet or the policy.

How Be Human handles this: language rules are part of the agent's defined role, alongside its memory, tools and approval boundaries. Be Human sets up the language policy, tone sheets and glossary with your team, keeps them as separate maintainable components, and runs recurring evaluations in each language as part of managed operations. Changes to the glossary or instructions are reviewed before they go live, and approval boundaries stay under your control.

Frequently asked questions

Do we need a separate agent for each language? Usually not. One agent with a language policy, per-language tone sheets and a shared glossary keeps memory, permissions and tools in one place, which is easier to govern. A separate agent only makes sense if the two languages serve entirely different teams, tools or approval rules.

Can the agent simply translate everything for us? It can draft translations, but a translation is not the same as a correct business document. Label translated output as a draft, keep the original as authoritative, and have a reader of the target language approve anything that leaves the company, particularly contracts, tax documents and official notices.

Which Portuguese should we choose, European or Brazilian? Choose by audience, not by preference. Set a company default, record the expected variant on each contact, and let the agent read it from there. If your clients are in both markets, write the glossary so that each variant has its own approved term.

What if nobody on the team reads Portuguese well? Then the agent should not send Portuguese messages on its own. Start by finding a qualified reviewer, whether an employee, a trusted client contact or an outside proofreader, and keep Portuguese output in draft-and-approve mode until reviews show reliable quality.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.