Pidgin was not a feature request

Nobody filed a ticket asking for Pidgin. There was no user interview where someone said I would use this more if it understood me in Yoruba. People don't ask for the thing they've never been offered — they just quietly do less with your product and you never find out why.

We built multilingual support because of something much simpler: open any app store in Jakarta, Manila or Hanoi and the banking apps speak the local language. Open ours and everything on the continent speaks English, or French, or Portuguese. Somebody else's language, in every case.

The framing we threw out

The obvious pitch writes itself, and it's wrong. It goes: voice banking helps people who struggle to read, so your grandmother can finally send money. Investors nod. It sounds like impact.

We killed that framing early. It's condescending, it's a small market, and — more importantly — it isn't true. The people using voice most heavily are not people who can't type. They're people who can type perfectly well and have worked out that talking is faster.

Speaking is not the accessible interface. It is the fast one.The line that ended the debate internally

Once you accept that, the language question stops being about inclusion and starts being about latency. A person composes a transfer in their head in whatever language they think in. Every step of translation between that thought and the app is friction you're charging them.

One instruction, five ways

Here is the same transfer, the way five different users actually phrase it. None of these are translations of each other — they're what people genuinely say.

Notice the Pidgin row. It is shorter than the English one. That's not a curiosity — that's the entire thesis in one line. The most efficient way for millions of Nigerians to express a transaction was the one no banking app would accept.

What this actually costs you

It would be dishonest to pretend this is free. Supporting five languages means five sets of edge cases, and the hard part is never the words — it's the numbers.

• "10k", "ten thousand", "dubu goma" and "ẹgbẹ̀rún mẹ́wàá" all have to resolve to the same integer
• Names get transliterated inconsistently, so beneficiary matching has to be fuzzy without being reckless
• Code-switching mid-sentence is normal, not an edge case — people start in English and finish in Pidgin
• Confirmation has to come back in the language the request arrived in, or trust evaporates

That last one matters more than the rest combined. If someone speaks to you in Hausa and you confirm in English, you have just told them the machine wasn't really listening. Every parsed instruction normalises to the same shape internally, and the language tag rides along with it:

{
  "intent": "transfer",
  "amount": 10000,
  "currency": "NGN",
  "beneficiary": { "match": "saved", "label": "broda" },
  "locale": "pcm",        // reply in the language they used
  "confidence": 0.94
}

One schema, five front doors. The banking logic never learns a word of any of them, which is the only way this stays maintainable.

We're still wrong about plenty of this. Tonal marks in Yoruba are unforgiving, our Hausa numerals break in ways we haven't fully mapped, and every week someone says something we've never heard. But the direction holds: the app should meet the sentence where it already exists, not ask for it to be rewritten.

If you've hit a phrasing Agentpesa didn't understand, we want it. Send it to hello@agentpesa.ai — badly parsed sentences are the most useful thing anyone can give us right now.