The Inference Race Is Building Infrastructure for a Grid You Don't Have

On September 4, MIT Technology Review published a piece describing what it calls the inference era: a world where advanced infrastructure runs as, in the piece's words, "the engine of continuous intelligence," powering real-time services and an increasingly intelligent edge of devices. The article's frame is that every delay, bottleneck, or wasted watt now translates directly into human outcomes and operating cost. That is a fair description of what the hyperscalers are building. It is also, quietly, a description of a set of assumptions that do not hold for most enterprise in East Africa.

The infrastructure being architected in that piece assumes a customer with stable power, high and consistent bandwidth, and the cash to pay for shaving milliseconds off a response. That customer exists. It runs hospitals doing real-time diagnostics and call centres resolving thousands of requests at once. It is not the profile of a hotel group in Entebbe deciding whether to put a booking agent on WhatsApp, or a hospital in Jinja weighing whether to let an AI system triage intake requests overnight. The gap between those two customers is not a matter of ambition. It is a matter of what the underlying system was built to tolerate.

What gets optimised away is exactly what you need

Here is the argument: the global race to reduce latency and increase memory bandwidth is, by construction, a race to make continuous connectivity cheaper and faster for the people who already have it. It is not a race to make intermittent connectivity survivable. Nobody architecting storage for real-time inference at hyperscale is spending engineering time on graceful degradation for a system that loses its connection for two minutes during a Kampala afternoon storm, or that needs to run a batch of pending requests the moment power comes back after load-shedding. That is not a criticism of the infrastructure builders. It is simply not their problem to solve, and their pricing and default behaviour reflect that.

An executive evaluating an agentic system for a business here typically hears the pitch in terms of what the model can do: resolve a booking, answer a claims question, draft a report. Rarely does the pitch mention what the system does when the network under it behaves the way networks in this region actually behave, which is unevenly. That omission is not dishonesty. It is that the vendor's own infrastructure, built to the standard the MIT Technology Review piece describes, was never tested against that condition, because their reference customer does not have it.

The failure mode this produces

The way this shows up on the ground is specific. A team deploys a customer-facing agent that assumes a request-response cycle completing in under a second, because that is the default the underlying model provider ships. The connection drops mid-request. The system times out silently, or worse, retries and duplicates an action, like confirming a booking twice or sending a payment reminder to a customer who already paid. Front desk staff, who were already watching the system with suspicion because it changes what their job is, now have direct evidence that it is unreliable. They do not distinguish between a model failure and a network failure. Neither does the customer. The system gets blamed, and the blame is permanent in a way that is hard to undo, because trust in these deployments is built slowly and lost in a single bad interaction.

This is a governance failure disguised as a technical one. Nobody asked, before deployment, what the system's behaviour should be under degraded connectivity, because the question sounds like an edge case to a team reading vendor documentation written for a market where it is an edge case. Here it is not an edge case. It is Tuesday.

The obvious objection

The counterargument is that this doesn't matter because most East African businesses aren't building infrastructure, they're calling an API. The memory architecture and storage bandwidth described in the MIT Technology Review piece live inside a hyperscaler's data centre. A hotel group's booking agent never touches that layer directly. It sends a request over the internet and gets a response. Whatever happens inside the model provider's stack is abstracted away.

That is true as far as it goes, and it is exactly why the argument matters rather than why it doesn't. The abstraction hides the infrastructure, but it does not hide the assumptions baked into it. Retry counts, timeout windows, rate limits, and pricing tiers are all set by a provider whose reference deployment has stable connectivity. When your connection is not stable, you inherit those defaults without inheriting the conditions they were designed for. The API call doesn't fail because your code is wrong. It fails because the contract between your system and theirs assumes a network you don't have, and nobody wrote that assumption down anywhere you would have read it before signing.

Uganda's own tourism sector is reportedly experimenting with AI tools to drive growth, according to a recent Monitor report, and Kenya has an AI accelerator programme underway according to fundsforNGOs. Both are evidence that the appetite for these systems is real and growing here. Neither changes the underlying infrastructure economics. The systems being built in Nairobi and Kampala will still run on top of a global stack optimised for a different grid.

The decision this leaves an executive with is not whether to adopt AI. It is which failure mode to design for before deployment, not after the first bad week. Ask a vendor what their system does in the ninety seconds after a connection drops, not how many tokens per second their model processes. If the answer is a shrug, you already know what your front desk staff will discover for you, and you will not get a second chance to earn back the trust that costs.

Sources

Architecting memory and storage in the AI era (MIT Technology Review, 2026-09-04)