When organisations deploy AI agents for customer-facing services, a common assumption is that a large language model (LLM) will handle the language challenge. Point it at the right languages, provide it with documentation, and it will manage. In many high-resource language contexts, that assumption holds reasonably well. For the low-resource languages spoken across much of Africa, South-East Asia, and other emerging markets, it does not.
Proto’s approach is built around a dual-layer architecture that combines a purpose-built NLP model for intent classification with an LLM layer for knowledge retrieval. Understanding what each layer does, why the separation matters, and where the genuine constraints lie is essential for anyone deploying conversational AI in these contexts.
Key takeaways
- NLP intent classification, not LLMs, is the reliable foundation for low-resource language AI. LLMs trained predominantly on high-resource languages do not generalise reliably to languages like Oshiwambo or Kinyarwanda.
- Proto’s dual-layer architecture uses NLP as the first layer for speed, accuracy, and output control, with an LLM layer for knowledge retrieval where it is appropriate and validated for the target language.
- The three common approaches to low-resource language support differ substantially in reliability. Translation layers and untested LLM deployment consistently underperform on intent accuracy. Dedicated NLP intent classification is the current benchmark.
- Voice deployment carries its own requirements: sufficient domain-specific recordings, an appropriate multilingual base model, and native-speaker evaluation. Generic training data produces generic – and often inadequate – results.
- Code-switching remains an open challenge across the industry. Mixed-language input is common in practice and not yet reliably handled by current language detection models.
- The work being done now is the foundation for what comes next. Intent libraries, workflow mappings, and use case data accumulated through NLP deployment are the building blocks for small language models – the next stage in building genuine conversational AI for languages that general-purpose LLMs have not reached.
How Proto’s NLP model is trained
Proto’s NLP layer is a traditional natural language processing model purpose-built for intent classification – not for open-ended generation. The distinction is fundamental. Where an LLM tries to produce the most likely next token in a sequence, the NLP model is trained to answer a specific question: what does this user want?
Training the model works as follows. For each supported language, an operator defines a set of intents – the discrete actions or enquiries a user might express, such as checking a balance, reporting a transaction error, or asking for operating hours. For every intent, a library of training phrases is provided: varied examples of how a real user might express that intent. The recommended minimum is ten distinct examples per intent, covering different phrasings, sentence structures, and vocabulary. The greater the variety, the more robust the model.
When a user message arrives, the NLP engine processes it in several steps: punctuation is removed, the text is tokenised (broken into individual words or subwords), and those tokens are converted into a numerical vector representation. That vector is then compared against the model’s learned intent space to find the closest match. If the confidence score exceeds a defined threshold, the matched intent is returned and a predefined bot response is delivered.
Because responses are predefined rather than generated, the system offers complete control over output – no hallucination, no off-topic responses, no unexpected generation. This matters significantly in regulated environments such as financial services, healthcare, or government services, where response accuracy and auditability are non-negotiable.
Critically, all of this must be done per language. Training phrases and predefined responses are not automatically translated or transferred across languages – each language requires its own intent library. This is labour-intensive, but it is also what makes the outputs trustworthy.
Deploying NLP for low-resource languages
Low-resource languages – those with limited digital text corpora, few labelled datasets, and minimal presence in mainstream AI training data – require a more manual and deliberate deployment approach. Languages like Oshiwambo (spoken primarily in Namibia and Angola) sit at this end of the spectrum. A useful benchmark: if a language is not supported by Google Translate or Microsoft Translate, it is operating in genuinely low-resource territory.
For these languages, the NLP framework remains the foundation, but the effort required to deploy it well is considerably higher. In practice, this means:
- Manually defining all intents and training phrases in the target language, without the ability to rely on translation tools or pre-existing labelled data.
- Providing preset answers for every supported response – LLM-generated responses are not a reliable fallback where the LLM has not been trained on that language.
- Mapping the specific use case in depth before building the intent library. A bot deployed for a financial complaints process needs a very different intent structure than one handling patient triage or a government youth advisory service. Getting this mapping right is the precondition for building an accurate model.
- Collecting domain-specific data over time. Generic text sources – books, religious texts, publicly available web content – are insufficient for domain-specific intent recognition. The data must reflect the actual vocabulary and phrasing of the deployment context. Proto’s experience with Oshiwambo illustrates this directly: initial training data drawn from general sources left the model unable to correctly handle terminology used in financial or government services.
The NLP approach for low-resource languages is effective within these constraints. It is not a path to open-ended conversational AI. The model will recognise what it has been trained to recognise, and respond only within what has been predefined. That scope can be expanded incrementally as the intent library grows, but it requires sustained investment in training data and domain knowledge.
The practical limitations of LLMs with low-resource languages
LLMs are pre-trained on large volumes of text, predominantly sourced from the internet. Languages extensively represented in that data – English, French, Spanish, Mandarin – benefit from strong model performance. Languages that are rarely written, or written in specialised registers not well captured online, are substantially underrepresented. The consequences are predictable.
For low-resource languages, LLMs typically exhibit three categories of failure:
- Generation failures – the model may understand an input sentence but cannot produce a coherent full-sentence response in that language. In testing with Oshiwambo, LLM outputs were effectively gibberish: structurally plausible but semantically incoherent. This is not an edge case; it is the expected behaviour for languages that did not feature meaningfully in training data.
- Intent misclassification – even where the LLM produces a response, it may fundamentally misunderstand what the user was asking. Unlike the NLP model, which is constrained to a defined intent space, an LLM generating a response may produce something fluent but entirely wrong. In a complaints or payments context, a convincingly wrong answer is worse than no answer. This is what Proto observed in market comparisons in Namibia, where competitors applying general-purpose LLMs to Oshiwambo appeared to understand the language but consistently misread intent.
- Inconsistent language detection – LLMs and the language detectors that feed them struggle with mixed-language input (code-switching), which is common in African languages where technical or financial terms are often expressed in English within an otherwise local-language sentence. Current language detectors use probability-based classification: a sentence with seven English words and three Kinyarwanda words is likely to be classified as English, and the model responds accordingly. This is an industry-wide limitation, not specific to any one platform.
Proto’s experience with these failure modes led to a specific design decision: the LLM layer is disabled by default and must be explicitly enabled. A practical problem that emerged in multi-language deployments is that enabling the LLM for one language – say, English – inadvertently activated it for all languages, including those where it produces degraded outputs. Proto is now implementing language-level LLM controls so that operators can specify exactly which languages activate the LLM, preventing gibberish outputs in low-resource contexts while preserving LLM functionality where it performs well.
LLMs are not a substitute for purpose-built NLP in low-resource language deployments. Deploying a general-purpose LLM and expecting it to handle Oshiwambo, Kinyarwanda, or Cebuano with the same reliability as English is not a realistic expectation. Solutions that claim otherwise are most likely routing inputs through a translation layer – which introduces compounding errors at both translation steps and consistently underperforms on intent accuracy – or producing outputs that have not been rigorously tested with native speakers.
The dual-layer architecture: what it enables and what it does not
Proto’s AI agent operates both the NLP layer and, where enabled, the LLM layer. The NLP layer is always the first point of contact. If it identifies a matching intent with sufficient confidence, it responds immediately – typically in under two seconds, with a predefined and auditable output. If no match is found, the query is passed to the LLM, which searches the knowledge base using retrieval-augmented generation (RAG). If the knowledge base yields no relevant content, the system falls back to a function call that passes training phrases to the LLM to locate a relevant workflow.
The LLM layer, when enabled in a high-resource language context, adds genuine value: it can answer questions that fall outside the predefined intent library, draw on uploaded documentation, and produce structured responses to varied queries. The NLP layer processes queries in under two seconds; the LLM layer typically takes five to six seconds, which is a further reason to use NLP as the first filter.
What the dual-layer architecture does not do is solve the low-resource language problem through the LLM. In deployments where the LLM is disabled for a given language, the system operates on NLP alone – meaning it will only respond to intents it has been trained to recognise. That is a real constraint. The capability is genuine and performs well within its scope; what it is not is a general-purpose conversational AI for those languages.
Looking ahead, Proto is introducing LLM actions that can be selectively enabled within workflows. This would allow the LLM to guide users through complex multi-step flows – for example, returning a user to a question they skipped – without requiring manual intervention from a customer experience team. This expands what the architecture can do without altering the foundational logic of NLP-first classification.
How approaches to low-resource language support compare
Three broad approaches exist in the market for low-resource language AI deployment:
- Translation layers – inputs are machine-translated into a high-resource language (usually English), processed by an LLM or NLP model, and the response is translated back. This approach is fast to deploy but introduces compounding errors at both translation steps, frequently misses intent, and produces responses that feel unnatural or are factually wrong when retranslated. It is particularly unreliable for languages not well supported by commercial translation APIs.
- Straight LLM deployment – a general-purpose LLM is applied directly to the target language. This produces acceptable results in high-resource languages and unreliable results in low-resource ones. Vendors offering this approach for languages like Oshiwambo or Kinyarwanda have typically not conducted native-speaker evaluation of intent accuracy.
- Dedicated NLP intent classification – building and training classification models specifically for each language and deployment context. This is the most accurate approach for low-resource languages. The relevant metrics are word error rate and intent classification accuracy – not model size or generality.
Proto competes on the third approach. The competitive differentiation is not simply language coverage but the combination of intent classification accuracy with deep workflow capability – the ability to map real institutional use cases into structured, reliable AI agent interactions.
Voice, accents, and the limits of generic training data
Intent classification is one part of the picture. For voice-enabled deployments, reliable performance also requires training automatic speech recognition (ASR) and custom text-to-speech (TTS) models with domain-specific voice data. The requirements are significant: at least 25-50 hours of recorded audio from native speakers, ideally covering the specific vocabulary of the deployment context, is needed to achieve accurate pronunciation and a local accent.
The choice of base model matters as much as the volume of data. Using an English-based model as the foundation will introduce an English accent regardless of how much local data is added – the vowel and consonant patterns of the base model persist. Switching to a multilingual base model has already delivered measurable accent improvement for Tagalog and Cebuano. For Kinyarwanda, which uses a Kinyarwanda-based open-source foundation model, native speakers report the accent compares well against alternatives, though work continues on punctuation handling – a detail that matters because tone changes word meaning in Kinyarwanda.
Languages such as Oshiwambo illustrate the compounding challenge of low-resource voice deployment. Initial training data drawn from general sources – books, websites, religious texts – improved the accent but left the model unable to correctly pronounce domain-specific terminology. Building an effective voice model for a low-resource language requires not just sufficient data volume, but data that is genuinely representative of the context in which the model will be used.
Code-switching: an open challenge
One of the more complex challenges in multilingual deployment is code-switching – the practice of mixing two languages within a single sentence. This is especially prevalent in African and South-East Asian languages, where technical or financial terminology is frequently expressed in English even within a sentence otherwise spoken in a local language.
Current language detection models use probability to determine which language a sentence belongs to. A sentence with mostly English words and a few Kinyarwanda words will typically be classified as English, and the model will respond in English regardless of the user’s intent. While NLP can be configured in advance to handle specific mixed-language patterns, the LLM layer is not currently reliable for mixed-language generation, and setting LLM prompts for mixed-language output is not recommended.
What comes next: towards small language models
The NLP-first architecture is an effective and principled approach to the current state of low-resource language AI. It is also the foundation for something more capable.
The intent libraries, workflow structures, and use case mappings built through NLP deployment are not just operational assets – they are training data. Each correctly classified interaction, each mapped complaint flow, each structured patient enquiry adds to a growing body of domain-specific, language-specific knowledge that general-purpose LLMs do not have access to.
As that data accumulates across languages like Kinyarwanda, Tagalog, Oshiwambo, and others, the path opens towards small language models (SLMs): models trained on focused, high-quality, domain-specific data for particular languages and institutional contexts. An SLM for Kinyarwanda financial services, trained on real interactions from real institutions, would offer something qualitatively different from either a general-purpose LLM attempting Kinyarwanda or a rule-based NLP system – genuine conversational capability grounded in the actual language and use cases of the people it serves.
The deployments happening now are not just solving today’s problems; they are building the infrastructure for a more capable next generation of language AI for underserved languages.