Localising Your Microsoft 365 Copilot Agent - Making It Work in More Than One Language

Australia likes to think of itself as an English-speaking country, and in the boardroom it mostly is. Walk onto a warehouse floor in Western Sydney, a construction site in Melbourne, or a food processing plant on the Darling Downs, and the picture is different. A large share of the people doing the actual work speak English as a second language, and some of them would much rather read an instruction, a policy, or a safety notice in Mandarin, Vietnamese, Arabic, or Punjabi. When you build a Microsoft 365 Copilot agent and ship it in English only, you've quietly decided that those people get a worse experience than everyone else.

That's the part of agent localisation people miss. It isn't a nice-to-have for organisations with overseas offices. It's a fairness and adoption issue inside a single Australian business. We've watched genuinely useful Copilot agents get poor uptake for no reason other than the first thing a night-shift worker saw was a wall of English they had to slowly decode. Microsoft's guidance on localising agents lays out the mechanics well, but the mechanics are the easy bit. The judgement about what to localise, and how deep to go, is where the work actually is.

What localisation covers, and what it doesn't

Let's be precise about what you're actually localising, because there are two very different layers and people conflate them constantly.

The first layer is the agent's own presentation and its author-written strings. This is the agent's name, its description in the Copilot store, the conversation starters you write, and any static instructional text you've hardcoded. These are things you, the builder, wrote in a manifest. Localising them means supplying translated versions keyed by locale, so a user whose Microsoft 365 language is set to Vietnamese sees a Vietnamese name and Vietnamese conversation starters when they open the agent. This is the part the documentation is really about, and it's the part you have direct control over.

The second layer is the actual conversation. When a user types a question in Thai and your agent answers, that answer's language is largely a function of the underlying model and how you've instructed it, not the localisation manifest. Declarative agents lean on Copilot's own model, which is genuinely good at responding in the language it was addressed in. Custom engine agents answer in whatever your orchestration and prompts produce. So "localising the agent" and "the agent holds a conversation in another language" are two separate problems, and you need both handled or the experience feels broken. A Vietnamese name attached to an agent that only ever replies in English is arguably worse than not bothering, because it promises something it doesn't deliver.

I labour this point because it's the single most common misunderstanding we untangle. A client says "we localised the agent" and means they translated the store listing. The staff experience of actually asking it a question in their own language never got tested.

How the manifest side works in practice

On the declarative agent side, localisation is a structured, boring, and reliable process, which is exactly what you want. You provide localisation files that map each translatable string to its value per locale. Set your default locale, add the languages you support, and populate the translations. When a user opens Copilot with their language set to one you support, the matching strings surface. When they're set to a language you haven't provided, it falls back to your default. No drama.

The honest advice here is to design for this from the start rather than retrofit it. Building the agent with hardcoded English strings scattered through the manifest and then trying to pull them all out into localisation files later is tedious and error-prone. If there's any chance you'll support a second language, and in an Australian workforce there usually is, structure your strings for it on day one. It costs almost nothing up front and saves a genuinely annoying refactor. This is the kind of thing our Copilot Studio consultants build in as a default now, because we've done the painful retrofit enough times to know better.

One thing worth flagging: the set of languages Copilot itself supports as a user interface language is finite, and it's not every language on earth. Before you promise a business unit that their Dari-speaking staff will get a fully localised agent, check that the language is actually supported end to end. There's nothing worse than a rollout plan built on an assumption that doesn't survive contact with the platform's supported-languages list.

The custom engine side is a different animal

If you've built a custom engine agent, where you own the model and the orchestration, localisation stops being a manifest exercise and becomes a design decision that runs through your whole system.

Your prompts need to handle language. Your system instructions should tell the model to respond in the user's language, and you need to actually pass that language through. If your agent retrieves knowledge from a document store, you have to decide what happens when the user asks in Arabic but every document is in English. Do you retrieve in English and have the model translate the answer? Do you keep translated copies of key documents? Do you translate the query, search, then translate back? Each has trade-offs, and the right answer depends on how much accuracy matters. For a general FAQ, model translation on the fly is fine. For anything where a mistranslation has consequences, a safety procedure, a financial term, a legal obligation, you want human-reviewed translated source content, not a model improvising.

This is where I get cautious. Machine translation inside an AI agent is good enough to be dangerous. It'll produce fluent, confident Vietnamese that's subtly wrong in exactly the situation where wrong matters. We ran into this on a build where an agent was cheerfully translating compliance terminology into something that sounded right and meant something legally different. The fix wasn't better prompting, it was accepting that certain content needs a human translator and the model's job is only to route the user to the correct pre-translated material. If you're building agents where the stakes are real, our AI agent development work always includes this conversation early, because it changes the architecture.

What actually to localise, and in what order

Here's the pragmatic sequencing I'd push a client towards, because trying to localise everything at once is how projects stall.

Start with the front door. The agent's name, description, and conversation starters are what a user meets first, and getting these into the top few languages your workforce speaks buys you most of the adoption benefit for a fraction of the effort. A worker who opens Copilot and sees the agent introduce itself in their language immediately understands it's for them. That first impression does a lot of heavy lifting.

Then handle the conversation language. Make sure the agent genuinely responds in the language it's addressed in, and test that with real speakers, not a Google Translate spot check. Native speakers catch tone and terminology problems that look fine to a monolingual builder.

Only then, and only if the content warrants it, invest in localised knowledge sources. This is the expensive part, and for a lot of agents it's overkill. Be honest about whether your users actually need the source documents in their language or whether a good conversational answer in their language, drawn from English source material, is enough. Often it is.

The mistake I see is treating all three as one big deliverable and blowing the timeline. They're not equal in value or cost. The name and conversation starters are cheap and high-impact. Localised, human-reviewed knowledge bases are expensive and situational. Sequence accordingly.

Testing is where good intentions go to die

You cannot verify a localisation by reading it yourself if you don't speak the language. Obvious, and yet.

Get actual speakers of each language in front of the agent before you call it done. Not a translator reviewing a spreadsheet of strings out of context, but a person using the thing, opening it, reading the conversation starters, asking real questions the way they'd actually phrase them. Context changes everything. A string that's a perfectly good translation in isolation can read as stilted, overly formal, or just odd once it's sitting in the interface next to everything else. And the way someone naturally asks a question in their first language is often not how a translated English question would come out, which exposes gaps in how your agent understands intent.

For any organisation rolling out multilingual agents at scale, this testing loop needs to be part of the plan, not an afterthought squeezed in the week before launch. It's one of the things we build into engagements through our AI managed services, because localisation isn't a one-off, it drifts as you add features and needs ongoing care in each language you support.

Is it worth it?

For plenty of internal agents used by a head-office team that all works in English, honestly, no. Don't localise for the sake of it. The effort is real and the payoff is zero if everyone using it reads English comfortably.

But the moment your agent touches a workforce where English is a second language for a meaningful slice of people, and in Australian manufacturing, logistics, construction, healthcare, and retail that's common, localisation stops being optional. It's the difference between a tool everyone can use and a tool that quietly works better for some staff than others. That gap has a way of tracking existing lines of seniority and pay, which is not a look any organisation wants from its shiny new AI.

Start small, localise the front door first, test with real speakers, and be ruthlessly honest about whether you need translated source content or just a conversation in the right language. If you're weighing up a Copilot rollout across a multilingual workforce and want a clear-eyed view on what to localise and what to leave, get in touch and we'll help you scope it properly.