The intelligence belongs on the device

• by Debarshi Chakraborty
• Oct 21, 2026
• 7 min

AgriVOX shows how device-first AI can deliver agricultural advice despite weak networks, limited phone memory, and costly data. Its local database answers questions offline, while server models and open networks handle complex live information, which improves access for farmers and agents.

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.