There's a version of the AI-in-Africa story that goes like this: the continent will leapfrog traditional digital infrastructure the way it leapfrogged landlines for mobile phones. AI will compress decades of institutional development. The gap will close faster than anyone expects.
This story is not entirely wrong, but it is missing something important about where the friction actually sits.
The infrastructure is fine
The infrastructure layer in Kenya is more capable than most Western developers assume. M-Pesa processes more transactions by volume than PayPal does in the country. Africa's Talking reaches developers building on 20+ African telecom networks from a single SDK — SMS, USSD, voice, airtime, payments — with well-designed APIs and reasonable documentation. Safaricom's Daraja API handles hundreds of millions of payment requests monthly. The uptime is good. The latency is manageable.
When I build payment flows for Kenyan users, I am not working around a broken system. I am working with a mature, heavily used, battle-tested system that most of the world doesn't know exists.
The tooling layer is where the gap is
The problem is one layer up. The AI tooling ecosystem — the MCP servers, the SDK wrappers, the API documentation in AI-consumable formats, the developer libraries — was built for a different set of markets.
When an AI agent needs to process a payment, it has Stripe. When it needs to send a message, it has Twilio. When it needs to understand a merchant flow, it has Square. These are reasonable choices for an agent operating in the US or Europe. They are useless for an agent operating in Kenya, Uganda, Ghana, Rwanda, or anywhere else in sub-Saharan Africa where M-Pesa and Africa's Talking are the actual payment and messaging infrastructure.
The effect is that AI applications built on the standard tooling stack are structurally incapable of serving the majority of people in East Africa. Not because those people are underserved by technology — they're not — but because the AI tooling layer doesn't know the infrastructure exists.
The context-hub gap
This showed up concretely when I contributed to context-hub, Andrew Ng's project for sharing API documentation as AI-consumable context. The repository had strong coverage of Western payment APIs, communication platforms, and developer tools.
M-Pesa wasn't there. Africa's Talking wasn't there. MTN MoMo wasn't there. Paystack — which processes billions of dollars annually across Nigeria, Ghana, Kenya, and South Africa — wasn't there.
I contributed eight documentation sets covering these APIs: STK Push patterns, USSD session handling, bulk SMS with bilingual templates, airtime disbursement across eight countries, Paystack's mobile money flow, MTN MoMo's 17-country collection API. The documentation exists in the PR waiting to merge.
The gap isn't that these APIs are undocumented. Safaricom has extensive documentation. Africa's Talking has thorough guides. The gap is that the documentation has never been translated into the formats that AI tooling consumes — structured context optimised for retrieval, with patterns and common failure modes called out explicitly.
What this means for builders
If you are building AI applications for African markets, you are not waiting for the infrastructure to mature. You are waiting for the tooling layer to catch up with infrastructure that is already mature.
The practical implication: the first builders who contribute to this tooling layer — MCP servers, context-hub documentation, standardised SDK wrappers — are not building niche tools for an edge case. They are building the foundation that every AI application serving East African users will eventually depend on.
That's a different framing than the leapfrog story. It's not about African markets catching up. It's about a tooling gap that is actively constraining what AI can do in markets where the underlying infrastructure is already in place.
Related: mpesa-mcp · context-hub PR #52
Responses