Blog

This is the second in a two-part series on rethinking artificial intelligence (AI) delivery for agriculture, based on MSC’s experience as we built digital farmer services (DFS). 

The first blog in this series, Why digital farmer services so often fail, argued that most AI platforms for farmers assume a decent phone, a stable connection, and cheap data. Farmers rarely have all three. Device memory runs out before the app does, a single advisory photo eats through a day’s data plan, and a dropped connection forces the network to resend the same data two or three times over.  

Platforms should depend less on the network where coverage is the main constraint. This benefits farmers who use the technology and agents who assist them. Bihar Krishi shows how this approach works. MSC helped design this government-owned digital platform targeting farmers in Bihar for the state’s Department of Agriculture. When the platform launched in 2023, farmer information and services, such as programs, market prices, and weather information, sat across separate systems. Bihar Krishi brought these services together.  

Bihar Krishi was built as a mobile app from the start. While a web version is also available, it serves a different purpose. Village-level assistants use it to help farmers who are not yet using the app themselves. 

The conversational AI feature came later to help farmers get the information they need without having to work out which menu or service to use. The AI interprets the question and directs the farmer to the relevant answer. Maharashtra’s MahaVISTAAR and the central government’s Bharat-VISTAAR platform use a similar approach. For example, “tell me more about maize” could refer to crop, seed availability, pest control, or a government program. 

Because Bihar Krishi added conversational AI to an existing platform, system questions are processed on a server, and the answer is sent back to the farmer. This approach made sense when Bihar Krishi was built. However, for AgriVOX, we asked what if more of the intelligence could sit on the device, so the platform depends less on the network?  

AgriVOX is the first version of X-VOX, MSC’s device-first product architecture for agriculture, finance, health, and other sectors. It is currently in testing. AgriVOX resolves a query in the following sequence, which stops when it finds an answer: 

• A local intent classifier checks a compact FAQ database shipped directly inside the app. If the answer is already there, it returns instantly without a network call; 

• If the answer is not in the app’s database, a server-hosted large language model answers anything the local database cannot, exactly as most current platforms do today; 

• If the LLM does not have the answer because the question requires live data, it uses the Beckn protocol. The basis for Beckn is the same open, decentralized-network standard behind India’s Open Network for Digital Commerce (ONDC) and OpenAgriNet. It connects to external service providers for information no app can hold locally in advance, such as a live government program registry, current weather, or soil-testing results. 

The sequence works for farmers or people who assist them. A seed or fertilizer retailer at the counter or a village-level entrepreneur gets the same instant local answer. The system can escalate queries to a server or retrieve live program or price information. A smart intent-selection system helps route each question to the right service. 

Consider a real AgriVOX query: “I want to grow maize in the coming season. How should I prepare for it?” The platform divides the request into questions that different services can answer. The standard maize-growing procedure for the season comes from the local FAQ database. The system reads the current date to infer the season and respond without a network call. The local database can also handle field preparation, such as irrigation and ploughing. Yet, how, where, and through what mechanisms the government can help require checking live program eligibility against the farmer’s own demographic details, plus current seed and fertilizer vendor availability and nearby storage or logistics options. The server’s large language model (LLM) can reason through this, while the rest needs the Beckn-protocol lane to a live network source. 

Photo-based queries, such as a crop-disease diagnosis, follow a different path. Image-based identification needs a Vision AI model too large to run on a farmer’s phone, so this step goes to the server, which limits a single combined request. If the connection drops mid-transfer, only the failed lane is retried, with compression applied to that retry, not the entire upload resent from scratch. This is the problem Part 1 described with ordinary retry behavior. 

A second component, the FAQ-feeder, keeps the local database growing. It periodically reviews questions that had to be escalated to the server, converts the recurring ones into new FAQ entries, and, after a human review step, pushes them back down to the device. The app still needs to connect periodically to pull these updates, but it depends much less on the network. 

The first blog argued that most farmers’ phones lack memory to spare. Common app sizes put that constraint in context. WhatsApp’s Android app runs roughly 87 MB, and Facebook Messenger installs at about 97MB. Among agricultural apps, Plantix installs at roughly 21.48 MB, and DeHaat Kisan at 34MB. 

AgriVOX’s local FAQ corpus, more than 2,000 entries deep, takes up just 4MB. The full app, corpus, source-classifier, interface, and runtime libraries together total about 15 MB. This is still smaller than every app above—essential on a 2 or 3 GB device that already carries several of them. The same holds whether the device belongs to a farmer or to the retailer and village-level entrepreneur who often advises one. The device-memory constraint we mentioned in the earlier blog is real, but it applies to heavy, general-purpose apps rather than intelligence designed from the outset to fit. 

After the FAQ feeder has learned common questions in a district for one or two seasons, the local layer may answer half of farmers’ text and voice queries. Photo-based diagnosis always needs the server. However, for ordinary advisory questions, every locally answered query returns instantly, spends no data, and carries none of the retry-multiplication risk described in the previous blog. 

The financial impact scales with where the farmer lives. At roughly USD 0.16 per GB in India, the savings from a handful of daily queries are small, since Indian data is already inexpensive. At the Sub-Saharan African average of USD 3.31 per GB, the same reduction, halved, amounts to roughly a dollar or more per month on AI-related traffic alone. This saving matters more to households that carefully ration data spending. 

Local processing also makes the service more reliable. Half of conversations no longer require a nearby tower, a strong signal, or a successful first transfer. Agents who answer several questions each day can provide consistent advice even without a live connection. 

Everything so far in this blog assumes that the farmer has a phone, even an old one, on a slow network. That assumption does not hold in much of Sub-Saharan Africa, where network costs are high and mobile penetration is low and few farmers own a device. No AI architecture, edge, or server changes who owns a phone. 

However, someone in that same village usually does. Banking agents, mobile-money agents, and input and output retailers need phones to run their businesses. Agricultural extension has an obvious channel through the same agent who advises farmers directly, using a tool most farmers could never own themselves. 

A device-first architecture can therefore influence whether agents adopt the tool. A server-dependent AI advisory tool charges the agent a network cost on every query, for every farmer, all day. People who run a business on thin margins may find the recurring cost harder to justify. A device-first tool, such as AgriVOX, answers most of that same volume from the local FAQ layer, at close to no marginal network cost per query. It does not ask the agent to absorb a growing data bill in exchange for giving better advice. 

In these markets, agents offer a more realistic route than direct use by farmers. Established, trusted agents can use a low-cost tool to provide better advice. AgriVOX can make the agent’s advice better without making their business harder to run. 

Voice interfaces are also moving from servers to devices. Lightweight text-to-speech models fine-tuned on AI4Bharat’s open Hindi voice data now run entirely offline, on-device, in real time, using compact exports instead of a cloud call for every sentence spoken back to a farmer. Quantized models with roughly a billion parameters can now run on ordinary phone hardware without an external API call. Every layer of the interface a farmer touches, text or voice, is becoming something a modest device can hold on its own, extending local processing one layer higher, to the interface. 

AgriVOX does not solve the three constraints this series has described. Fixing rural bandwidth, closing the smartphone affordability gap, and rewriting the economics of mobile data are larger interventions for other actors and other debates. AgriVOX designs around those constraints as they stand today, so that adoption and inclusion do not have to wait for the larger interventions to arrive first. 

The distinction is the whole point. A technologist’s instinct is to build toward the best available benchmark, the fastest model, the newest capability, and assume the infrastructure will eventually catch up. MSC’s instinct, shaped by work closer to the ground, is to start from the stakeholder, whether a farmer or a retailer, and village-level entrepreneur advising them. We look at the phone they use, the signal they can get, and the data plan they can afford this season. The intelligence belongs on the device because a farmer can use it today. After sufficient field testing, the next post in this series will report how AgriVOX performs in practice. 

This is the first of a two-part series on rethinking AI delivery for agriculture, based on our experience building digital farmer services (DFS). 

What happens when an AI tool designed to help a farmer cannot reach them when they need it most? The answer reveals a problem that goes far beyond the technology itself. Many artificial intelligence (AI) platforms built for farmers still begin with a simple picture: a farmer with a decent smartphone, a stable connection, and cheap data. 

For smallholder farmers, these three conditions rarely reflect reality. The gap between these conditions and farmers’ realities matters more than AI quality. It helps explain why many farmer-facing tools work in a pilot but fail once they reach real users.  

A farmer in a village three hours from the nearest town points their phone camera at a wilting maize leaf. They need an answer before the disease spreads further. The app opens, but the upload stops. Their two-year-old phone cannot handle the camera and upload simultaneously. The nearest tower is congested, so the connection times out.  

They buy a data top-up that they can barely afford. However, the problem continues. They cannot get a usable connection before the evening. The next morning, they walk to town for advice from an agri-dealer instead. They are not an exception. Their experience is common among smallholder farmers across India, Sub-Saharan Africa, and South Asia. They represent the user that server-led AI designs often overlook. 

Design for the phones farmers use  

 

A modern AI app expects more from a smartphone than many farmers can provide. It requires processing power and available memory to run smoothly. Most farmers do not have that luxury. In India, the sub-USD 200 entry tier still dominates smartphone sales by volume. Low-cost devices typically have just 2 GB to 4 GB of random access memory (RAM), which is the phone’s short-term working memory. It affects how many apps can run smoothly at once.  

In Sub-Saharan Africa, the baseline is lower still. The GSM Association and African mobile operators have jointly proposed 2 GB of RAM as the minimum specification for an affordable 4G smartphone. The proposed specification sets a target below the current baseline. 

A 2 GB phone already runs a messaging app, a camera, and background sync, which leaves little room to hold a large upload in memory while a slow network catches up.  

Platforms designed and tested on newer devices can exclude the very farmers they seek to serve. The problem goes beyond what AI can do. The phone must also keep up long enough to deliver it. 

Data costs shape whether farmers use the service 

 

Data plans in South Asia look generous until you see what has to be shared with the allowance. For instance, Reliance Jio’s INR 349 (USD 3.66) plan, a standard package on India’s largest network, gives a subscriber 2 GB of data per day for 28 days. That 2 GB covers uploads and downloads, every app on the phone, and all other data use. A farmer must share the allowance across all digital needs, including crop-related questions.  

A geotagged, full-resolution photo from a modern camera uses roughly 3 MB to 6 MB per shot once GPS coordinates and device metadata are attached. A crop diagnosis requires the farmer to upload the photo and download the result. A single question can use a noticeable share of the farmer’s daily allowance.  

The numbers look very different across markets. Among the five cheapest mobile data markets in the world, two are in South Asia and the Pacific: Fiji and Cambodia. They have roughly USD 0.09 and USD 0.12 per GB, respectively, as per a study. India also has low mobile data costs, at USD 0.16 per GB.  

Sub-Saharan Africa is a different market. The same tracking study puts the regional average at USD 3.31 per GB, roughly 20 times the Indian rate. Zimbabwe alone reaches USD 43.75 per GB.  

So, the same advisory photo that costs a fraction of a rupee in India can cost real money in Harare, Zimbabwe. For a farmer working with a tight budget, that difference matters before AI even gets a chance to answer. 

Coverage does not guarantee a usable connection 

 

Coverage maps can make connectivity seem widely available. Yet, field data shows a different story. In India, 4G signal reaches 89% of villages. By early 2025, 5G had reached roughly 78% of villages as well.  Yet rural tele density, or the number of active mobile connections per 100 people, is only 59%, compared with 125% in urban areas. In plain terms, a village can have a strong signal on paper, while roughly four in 10 residents still have no working mobile connection to use it with. 

Even when a farmer has 4G, the connection may not perform well. Independent field tests of public 4G networks in rural agricultural settings rarely recorded speeds above 20 Mbps, and latency almost never fell below 100 milliseconds. Latency measures the delay between sending a request and getting a reply. Higher latency means longer upload times and a greater risk of failure.  

Sub-Saharan Africa shows the same gap on a larger scale. Roughly 85% of the population lives within reach of 3G or 4G broadband, but 63% remain offline inside that same coverage area. 

A weak or congested connection also worsens the cost problem. Mobile networks do not resume a broken upload at the point where it stopped. They restart it from the beginning. On a lossy connection, one retry can become five, and five can become 50 before a transfer succeeds. Each failed attempt uses more of the same data allowance. A photo that should cost a single debit against the day’s allowance. Network failures can make it use two or three times as much. The farmer pays for the network’s failure to deliver a reliable service. 

A platform that already confirms this 

 

Maharashtra’s own farmer advisory platform makes this point unintentionally. MahaVISTAAR-AI launched in May 2025 as a smartphone app. It delivers weather updates, market prices, and pest advisories to registered farmers across the state. Within a year, the state government added a voice-telephony layer to the same platform.  Farmers could reach it by phone without downloading an app, a smartphone, or an internet connection. This addition is more than a new feature. It shows that the original app-based design could not reach every farmer it was built to serve. The voice layer brings the service closer to the farmers described by the data above. 

What this means for AI in agriculture 

 

Device memory, data cost, and connection reliability are not separate problems. They compound each other and define the baseline condition of the market that these platforms seek to serve. These conditions are not an edge case that better infrastructure will eventually solve. A weak connection can delay an answer and increase the data cost of getting it. For farmers with a tight data budget, that cost can determine whether they use a tool or give up on it. AI in agriculture must account for how and where farmers can access the intelligence.  

A model that depends on a round trip to a well-provisioned server moves the constraint from the AI’s capability to the farmer’s access. Declaring a problem solved does not make that constraint disappear.  

For the farmer with the wilting maize leaf, access matters as much as AI capability. They need an answer on the phone they have, with the connection and data they can afford. 

MahaVISTAAR-AI has already found a partial answer through the phone network. The next blog in this series explores the next step. It examines what changes when the AI model itself runs on the device. This model can match the hardware farmers actually own and use, which has little or no network access. 

Blog part 2: “The intelligence belongs on the device”