How We Built a Multilingual AI Assistant Using n8n and a Southeast Asia-Trained LLM

Most AI assistant tutorials point you at a general-purpose model and call it done. That's fine until the people you're actually building for speak and write in a way those models weren't trained to handle well, mixing English with Malay, Mandarin, or Singlish in the same sentence, using local shorthand for places and services that a Western-trained model has never seen. We wanted to test what it takes to build something that starts from the opposite assumption: a model trained with Southeast Asian language and context in mind, wired into a chat interface people already use.

The problem: most AI assistants aren't built for how Singapore actually talks

The default AI stack most teams reach for assumes an English-first, Western-context model, accessed through a paid API, with a custom backend written to hold everything together. That's a lot of engineering overhead for a small team, real ongoing API costs per message, and it still misses the mark on regional context, code-switching between languages, and the tone local customers actually use. Answers can come back grammatically correct and still feel slightly foreign, missing the register a local business would actually use with its own customers.

We wanted a version of this that a small team could realistically stand up and maintain without a dedicated backend engineer on staff, and without committing to per-message API costs before knowing whether the thing was even useful.

What we built

We used Telegram as the interface, since it's something most people already have installed rather than a separate app to download, and its bot API is built specifically for exactly this kind of integration, no app store approval process, no custom mobile app to maintain. The reasoning ran on SEA-LION, an open language model built by AI Singapore specifically with Southeast Asian languages and context in mind, and made available through a generous free-tier API, which mattered for a project that started as a test, not a funded product. Connecting the two was n8n, a no-code automation platform, so the whole thing didn't need a custom backend written from scratch.

The choice of n8n over a hand-written backend wasn't just about saving time upfront. A visual workflow is something a non-engineer on a small team can actually open, read, and modify later, change which model handles a message, adjust a prompt, add a new step, without needing to touch code or redeploy anything. For a small business, that maintainability matters more in month six than the initial build speed does in week one.

The interesting technical wrinkle was that n8n had no built-in support for this particular model. Rather than building a custom connector from scratch, we used the fact that the model exposes an OpenAI-compatible API, meaning it accepts requests in the same shape OpenAI's own API expects. That let us plug it straight into n8n's existing OpenAI integration node, just pointed at a different address with different credentials, instead of writing and maintaining custom integration code.

Two smaller problems took more effort than the core integration. First, Telegram delivers messages to a public HTTPS webhook, but a workflow running locally during development has no public address, so we tunneled the local endpoint out to a temporary public URL to receive messages while building and testing. Second, the shape of a Telegram message and the shape of input the AI workflow expected weren't identical, so a chunk of the actual build work was just careful field mapping, making sure the right text landed in the right place before it ever reached the model.

What we'd change for a production deployment

A temporary tunnel is fine for testing and wrong for anything meant to run continuously, since it depends on a session that isn't guaranteed to stay up. For a real deployment, that webhook endpoint belongs on a small, properly secured VPS with a stable address, not a laptop with a tunnel open. We'd also add proper logging so a failed message doesn't just silently vanish, and basic rate limiting so a burst of messages, accidental or malicious, can't run up the model API bill or overwhelm the workflow.

Checking the answers were actually good, not just fast

A working pipeline that returns a response quickly isn't the same as one giving a customer a correct or appropriately toned answer, and it's worth being explicit that these are two separate things to verify. Before treating anything like this as usable, we ran a batch of realistic questions through it, the kind of mixed-language, locally phrased queries a real customer would actually send, and checked the responses by hand for accuracy and tone, not just whether the pipeline technically completed without erroring out.

That distinction matters more than it sounds. A response can be fluent, confident, and completely wrong, or technically correct but delivered in a tone that would read as strange coming from a real local business. Catching that requires someone actually reading the outputs, not just confirming the workflow ran end to end.

What it can't do yet

It's worth being honest about scope. This build handles text conversation, in the languages and tone it was set up for, and nothing more. It doesn't process voice messages, it doesn't have access to a knowledge base of the business's actual policies or inventory, and it can't take actions beyond replying, it can't check a booking system or update a record. Every one of those is a realistic next step, and none of them are free: each one is its own integration, its own testing pass, and its own new way for something to go wrong if it's rushed.

Why this matters beyond the demo

This is the same shape as the FAQ bots, lead-intake assistants, and internal ops tools we build for clients, just pointed at whichever model and messaging channel actually fits the business, rather than defaulting to whatever's most talked about. The specific pieces, Telegram, SEA-LION, n8n, aren't the point. The pattern underneath them is: a messaging channel customers already use, a model chosen for fit rather than fame, and an automation layer a small team can actually maintain.

• Handling repetitive customer questions in the language and tone your customers actually use, instead of a technically correct but slightly foreign-sounding reply.
• Triaging enquiries before a human ever needs to look at them, so your team's time goes to the conversations that actually need a person.
• Giving a small team an always-on first response without hiring anyone, across whatever hours your customers are actually messaging you.
• Sitting on top of tools you already use instead of requiring a platform migration or a rebuild of your existing workflow.

The result

A working, 24/7 assistant answering through Telegram, with the underlying pieces, the model, the channel, and the automation layer, all swappable depending on what a given business actually needs. That flexibility, not any single tool, is the part worth taking away: the right assistant for a Singapore F&B business messaging customers in Singlish looks different from the right assistant for a B2B firm handling enquiries in formal English, and the same underlying pattern can be pointed at either.