Adaptation, not adoption, is king

Editor’s note: This is the first in a planned series on AI and development topics. The ideas represented here are starting points for further discussion rather than a final blueprint. The views and ideas expressed here do not necessarily represent those of our employers.

The increasingly general-purpose nature of AI brings capabilities to bear on a widening set of tasks, and new benchmarks are being released at a rapid pace to capture this generalisability. They increasingly focus on real-world applications: OSWorld measures an AI agent's ability to complete tasks like filling a spreadsheet with information from photos of receipts, while OfficeQA tests grounded business-related reasoning over collections of firm documents. Yet despite generalising abilities and broadening benchmarks, Figure 1 below shows us that the capabilities recorded in labs (blue) are often not transferring directly into real-world adoption (red), let alone impact or economic returns – which is particularly true  in low-income countries.

Figure 1: Theoretical capability and observed usage

Share of job tasks that LLMs could theoretically perform (blue) against Anthropic's observed-exposure measure, derived from Claude usage data mapped to US occupations (red). The distance between blue and red is the capability-deployment gap; the red area is likely far thinner in LMICs, where adoption remains minimal. Source: Massenkoff and McCrory, Anthropic (2026)

The mismatch arises in the intermediary stages between lab and deployment, which introduce constraints that do not generalise across contexts. Overcoming them requires bottom-up experimentation to work out the context-specific adaptations each setting demands. So we need to build an 'adaptation layer': the shared infrastructure of evaluations, data pipelines, compute and talent that would let local developers adapt AI models rapidly to their own constraints. Philanthropic funders, for reasons set out below, are better placed than governments, businesses or NGOs to pay for it.

Ensuring capabilities extend to deployment requires adaptation

Broadly put (see Figure 2 below), adaptation can take place at the model training stage (upstream) where post-training can refine AI behaviour, such as LearnLM’s post-training that can solve benchmarks like CORE-Bench, or at the product application stage (downstream), where system integration and deployment happen.

Figure 2: The production function of AI

The production function of general-purpose AI, split between upstream model training and downstream product (Fraiberger and Kazemi, forthcoming).

This latter stage is increasingly accessible due to cheap compute and coding agents. For task-specific uses, it’s only getting easier to build wrappers, software products built on top of an existing foundation model. These wrappers are currently how much of the capability observed in frontier labs reaches the real world. But scaffolding cannot always overcome deficiencies embedded upstream in the models themselves. Which adaptations are needed depends on local constraints, and finding out requires rapid iteration between downstream and upstream. We need to identify the barriers that stop capabilities proven in ideal conditions from being deployed in context, and then remove them. So far, that iteration has been far too slow.

Integration into local context runs along three pathways, the three I's: specialisation with information, orientation to institutions, and rightsizing into infrastructure. A fourth dimension, user experience, emerges only at deployment and is discussed separately below – the 3I+X framework.

The three model-level adaptation pathways of general-purpose AI (Fraiberger and Kazemi, forthcoming). 

As attention and money pour into scattered pilots of potential ‘AI for good’ wins, the low-hanging fruit, meaning the use-cases where constraints are weakest and returns can be demonstrated most quickly, will be picked first. 

These will cluster in higher- and middle-income settings with existing data pipelines that can support task-specific training, leaving most low- and middle-income countries (LMICs) with a far lower rate of effective AI adoption. The incentives of the main actors all point the same way: governments need to demonstrate gains for citizens, businesses must show returns to shareholders, and non-profits must prove their cost-effectiveness to donors within grant cycles.

The experience of Tabiya, a non-profit that builds open-source software for labour markets in low- and middle-income countries, illustrates this. Tabiya's conversational AI tool, Compass, draws out the skills in a person's experience, from paid jobs to informal and unpaid care work, and turns them into a profile matched to specific opportunities. Everything Tabiya builds is developed by an engineering team based in East Africa, released open source, and designed to be integrated, owned, and operated by partners rather than run centrally. For instance, in South Africa, Compass reaches jobseekers through SAYouth.mobi and the national youth employment platform is run by the non-profit Harambee, in Kenya and Argentina this is done through youth organisations, while Zambia has a government-owned platform. Tabiya builds once and then adapts across contexts. This is why an organisation like Tabiya constantly meets the adaptation problem – each time they take their product to a new setting, they encounter new constraints.

For example, adaptation requires a high degree of trust and effortful data collection from local partners. To speed the turnaround, Tabiya developed a reproducible pipeline that fuses high-quality data structures from high-resource contexts with unstructured local information, removing the need to start from scratch each time. By taking the ESCO occupational taxonomy as a foundation and using an AI-driven semi-automatic pipeline to revise it systematically against messy local labour-market data, Compass becomes context-aware with minimal manual effort. Scaling similar data pipelines across other sectors could form a vital backbone for interoperability and context-awareness in AI products to boost replicability and development impact. 

X marks the last mile: Where model adaptation runs out

Further downstream at deployment, distinct dimensions of adaptation emerge which can only be worked out in the field. 

Two hurdles that consistently show up are: designing for digital paradigms different to web-first environments in which most engineers are trained, and earning the institutional trust that unlocks data and deployment.

Tabiya’s Compass is a mobile-first web application, and because it handles personal employment data it follows modern best practice for secure software. This means accounts tied to an email address and password, with email-based verification. Those conventions are the industry default, and the tooling that makes secure authentication cheap to build depends on them. But they presume a specific form of digital literacy. Many jobseekers Tabiya's partners serve are thoroughly digital, fluent on smartphones, messaging apps, and mobile money, but have rarely needed an email address with a complex password. This mismatch arises at the first screen, before any question of model capability arises. Fixing it requires authentication built on the phone-and-PIN conventions which users already trust, but there is no standard, secure, and reusable way to build it. SMS gateways and telecom integrations must be negotiated country by country, so every organisation deploying in these markets solves the same problem from scratch. A shared, open toolkit reconciling rigorous data protection with phone-based identity is exactly the kind of piece an adaptation layer could supply.

Another recurring bottleneck is a more mundane one. Data-residency rules and government preferences often dictate deployment architecture. In Ethiopia, where Tabiya works with the Ministry of Labor and Skills to digitalise the country's public employment services, meeting local requirements meant swapping an API-based commercial embedding model for a locally hosted Qwen model. Because such constraints settle an application's architecture first, organisations like Tabiya must remain model-agnostic, and at present that takes significant software engineering: decoupling an application from a specific provider's ecosystem so that it can run on local infrastructure. An adaptation layer that made frontier and locally hosted models interchangeable, with minimal changes elsewhere in the application, would make these transitions considerably cheaper and mitigates against lock-in risks.

Gaps of this kind, small, local and decisive, are where AI's promise for development is currently being won and lost.

What does building the adaptation layer actually look like?

This is the opening for philanthropy. Funders able to take a longer view can back the adaptation layer, where investment generates a multiplier effect through much tighter feedback loops. A layer that enables experimentation and continuous improvement would give local entrepreneurs and developers the agency to adapt AI models and overcome their own constraints.

Across the three pathways highlighted above, we have outlined four fundable categories for philanthropy to consider, and what success would look like in each.

A few guiding notes on these proposals:

• Valuable work is already being done upstream at the pre-training layer to improve base model capabilities on languages, with novel data gathering methods pioneered by UNDP, the World Bank Group’s Development Data Partnership, CurrentAI’s Public Interest AI, and others. 
• Our focus here is on adapting those capabilities to meet the task-specific requirements of each context: the next frontier in diffusing capabilities.
• The list is not exhaustive; it indicates a set with potential for high impact where we believe funding can be effective.
• We imagine each as a proof of concept which, if borne out, would build towards the adaptation layer: digital public goods that smooth diffusion across contexts.
• The proposals represent a viewpoint broadly supported by the authors, though not every author endorses every item.
• In the final section of this blog, we discuss how this holds up in different timelines.

Human-AI experiment mechanisms (Information and Institutions) – with incentives strong enough to bring in experts and hard-to-reach people in rural communities: the end-beneficiaries of AI products who often have limited digital connection. These mechanisms would enable tighter evaluation of downstream impact, while generating post-training data for specialisation and valuable behavioural evidence to guide orientation to institutions.

E.g. Holding constant the AI model and task, replicate an evaluation across diverse geographies to measure performance in different contexts and languages. This would surface the varying limitations of existing AI capabilities due to bottlenecks at deployment – gaps can present across axes such as skill-levels or unfamiliar contexts (like lower-resource languages). By using the results from these human-AI experiments, you can inform the feedback loop and then re-evaluate the model on the same end-users and tasks. A measurable improvement would motivate applying this mechanism onto other gaps between capabilities and real world use, building towards a new set of benchmarks relevant for developing contexts - such as a GDPval, but for LMICs. 

Localised data pipelines (Information) – post-training AI models to suit unfamiliar contexts, with sophisticated synthetic data manufacturers which can work from limited samples to improve performance against specific tasks without triggering model collapse. Licensing models such as Esethu can then return proceeds from usage of the datasets to local communities who then reinvest the funds. This category is the key enabling stack for information-based adaptation, and works hand-in-hand with model- and product-level evaluations (levels 1-2 of the Generative AI Playbook) that would draw from the human-AI experiment mechanisms outlined above. 

E.g. Gather post-training datasets for performance gaps at deployment. For instance, gaps occurring due to language, which do not occur for the same task in other languages, can be closed by gathering realistic task-specific instruction datasets in that language - such as ideal question-answer pairs generated by the end-users. Performance gains on the task-level outcomes of interest would motivate replicating the data pipeline for similar task-specific training in other contexts. A proof of concept showing that homework grading samples can be generated from just a few dozen examples to align a model to a local curriculum would motivate building similar pipelines in other contexts and curricula.

‘Small AI’ foundries (Infrastructure) - pooling the GPUs and engineering talent needed to conduct post-training from localised datasets, as well as distilling models to suit different device capacities and monitoring performance stability on downstream task benchmarks before more rigorous evaluations are re-conducted. This is the compute backbone underpinning adaptation.

E.g. A successful foundry run would show that (i) the computing and engineering costs came in below what the LMIC team would have paid for existing on-demand (typically cloud) resources, (ii) benchmark-level performance improved on the base model, and, as an optional goal, (iii) the inference-time costs of the model fell and/or its size shrank enough to operate on more edge devices.

Talent programmes (Information, Infrastructure, and Institutions) - equipping entrepreneurs and motivated members of the general public with the skills necessary to build the products they can see their communities need. An initiative that put coding agents in everyone's hands could kick off innovation cycles buoyed by bottom-up adaptation; philanthropies such as Google.org have funded works in this spirit, including Apolitical’s Government AI Campus. Talent underpins all three adaptation pathways.

Empower end-users through a structured program which combines engineering skills such as ‘Learn Enough Claude Code to be Dangerous’ alongside best practices in impact evaluations. A successful programme would allow end-users to identify and measure performance gaps in their own workflows before setting up data pipelines and making use of foundries to assess improvements. 

Learning from Tabiya’s deployment experience, and drawing from the concrete proposals above, a few suggestions emerge for the final experience (X) layer:

• Shared product-development standards, and working open-source components to go with them, that reconcile stringent data protection with the digital conventions users already hold: phone numbers, PINs, and messaging apps rather than email addresses and passwords. A secure, reusable phone-based login flow would be a natural first artifact; a common repository of such components relevant for different deployment contexts would spare local teams from reinventing the wheel or compromising on security.
• The experience layer has a second user: the institution that runs the system after handoff. Admin tooling, monitoring, and documentation that a ministry's own staff can operate and maintain determine whether a deployment outlives its pilot, and they deserve the same design attention as the end-user interface.
• Talent programmes should not only reach end-users but upskill the local developers who have already earned the trust of the community and key actors, equipping them with the design-research tools needed to understand marginalised users. No engineer flown in from Silicon Valley for three months will build the trust that a long-standing local associate has nurtured over years.
• Modularity in model choice eases integration, since security and sovereignty considerations often favour locally hosted models over API access, and preferences shift quickly.
• Global agent certifications, so that organisations deploying AI agents on sensitive infrastructure have a recognised standard of assurance to rely on.

If we’re building god, is this really necessary? 

A fair challenge to the case made so far is that the adaptation layer only matters if today's constraints persist. Should frontier AI deliver overwhelming, general-purpose capability in the near future, then investment in adapting models to local conditions might look like careful engineering for a world about to be swept away.

How persistent the constraints will prove is genuinely uncertain. Two scenarios, drawn on different axes, illustrate the stakes:

1. Rapid capability take-off. If frontier capabilities develop along a rapid trajectory, the gap between frontier models and laggards could become insurmountable. Frontier models might then bridge deployment constraints autonomously, in the manner of a software intelligence explosion. In that world, avoiding being cut off from superior frontier AI becomes more important than adapting laggard AI. 
2. Compute scarcity. If access to compute becomes limited, adaptation and efficiency gains become increasingly critical. We have lived through an era of cheap tokens, which spurred adoption with little attention to the cost of deployment. A compute crunch would force the supply of tokens to be matched carefully to the demand for machine intelligence, which is precisely the work of adaptation. 

These scenarios are not mutually exclusive, and capability trajectories and compute supply could combine in various ways, but they usefully bracket the argument. Scenario (2) supports the case for the adaptation layer directly and needs no further defence. Scenario (1) is the pessimistic outlook for the adaptation layer, and it deserves reflection. 

The International AI Safety Report sets out capability scenarios ranging from stagnation, as happened with flight speeds, to rapid take-off. Several commentators argue that in the latter case, exponential or super-exponential progress paired with recursive self-improvement would yield insurmountable advantages for frontier developers. As open-source AI is deployed for health and education across LMICs, the concern is that any advantage gained by adapting models to overcome constraints would be muted by the automatic advantages of frontier AI. 

There are three responses to this.

First, capability gains may not translate into deployed value. We feel that model capabilities will continue to demonstrate jaggedness: whereby performance on economically valuable tasks is not directly following from standard scaling approaches, and progress may continue to suffer from a Goodhart's Law dynamic, in which models improve against benchmarks faster than against the real-world tasks the benchmarks stand in for. This would blunt, even if it does not eliminate, the practical advantage of self-improving frontier AI.

Second, and more fundamentally, the adaptation layer is engine-agnostic. Its function is to translate whatever technological capabilities exist into deployment within particular institutions, languages, infrastructures, and regulatory settings. If frontier AI does deliver large capability differentials, that translation work becomes all the more valuable, since the returns to closing the gap between abstract capability and realised productivity grow with the capability itself. One should be able to change the engine without rebuilding the vehicle.

Third, open models retain structural advantages that are independent of raw capability: adaptability to local context, control over weights and data flows, and integration into institutions. Human institutions move more slowly than capabilities develop, and sovereignty and security concerns accentuate that slowness. Being able to swap a frontier model for one over which sovereignty is retained, much as one might switch from grid electricity to a backup generator, may prove the expedient geopolitical strategy even at a substantial cost in capability.

The answer to whether this is necessary, then, is yes. Even if we are building a god, its works arrive in the world only through broad, agential access, and that is what diffusion infrastructure secures, even as the underlying models are continually replaced by more capable successors. Frontier access will still be required in particular domains, security among them, but that is a complement to the adaptation layer rather than a substitute for it.

Where the money should go

So, we should fund the connective tissue rather than another pilot: experiment mechanisms that measure where capabilities fail in context, data pipelines that close the gaps, foundries that make the compute and engineering affordable, and talent programmes that put adaptation in local hands. None of these seem like moonshots, rather each contributes to infrastructure that makes many small moonshots possible. And Tabiya, AdalatAI, Viamo, and others show that the supply of AI tools is already expanding to meet government and consumer demand in LMICs, so there is no need to reinvent the wheel entirely. An adaptation layer can boost these existing initiatives and spark many more which, launched from the ground up, will ensure that AI's capabilities will be converted into development impact.

Acknowledgements: The first schematics of the adaptation layer framework were developed by Sharif Kazemi and Samuel Fraiberger during the proceedings of the World Development Report 2026. The case study from Tabiya was elaborated clearly by Jasmin Baier, Christian Meyer-Wratil, Jonathan Stoterau, and Minaz Ranjita Singh. A few ideas were developed in discussion with attendees at the Rethink Priorities AIxGHD Strategy Forum on June 1, 2026, which followed Chatham House Rules. Further helpful comments were provided by Stephen Clare, Lucas Irwin, Niall Maher, Joseph Levine, and Philipp Zimmer.