The three-layer model reshaping how governments deliver farm services
India built UPI on a simple idea: don’t make every bank build its own payment network – build one open, interoperable rail that any bank, any app, and any merchant can plug into. Aadhaar did the same for identity. Agriculture is now going through the same shift, and the umbrella term for it is Digital Public Infrastructure, or DPI.
For a sector that still runs on paper crop registers, disconnected insurance databases, and a different app for every government scheme, that’s a bigger change than it sounds – and it’s reshaping how Indian states think about building agriculture technology at all.
Digital Public Infrastructure isn’t one product – it’s a design philosophy for public-sector technology, built on three commitments:
Contrast that with how most government technology has historically been procured: a single vendor builds a closed system for a single department, and the data lives and dies inside that one system. Digital Public Infrastructure inverts that – the infrastructure is shared, and services are built on top of it by whoever is authorised to build.
Indian farmers routinely exist as several different, disconnected digital records at once – one in the land revenue system, one in the crop insurance database, one in a state advisory app, one in a subsidy disbursal system. None of these necessarily agree with each other, and none of them were built to talk to the others.
That fragmentation isn’t just an IT inconvenience. It shows up as farmers wrongly excluded from a scheme because their land records don’t match their crop registration, insurance claims that take months to settle because yield data has to be manually reconciled across departments, and multiple agencies each running their own version of a “farmer database” that nobody fully trusts.
An agriculture DPI is the attempt to fix that at the architecture level, rather than patching it scheme by scheme, department by department.
Most state and national agriculture DPI efforts – including India’s Digital Agriculture Mission – are built around a version of this stack:
The foundation: a verified farmer registry, digitised land records, and a crop registry that captures what’s actually growing on a given plot. This is the “single source of truth” every other layer depends on, and it’s usually the hardest and slowest layer to get right, since it means reconciling decades of paper-based land records first.
The connective tissue: open APIs and consent-based data-sharing standards that let an insurance company, a bank, or an advisory service query verified data without needing a separate, custom integration project for every new partner that comes along.
What farmers actually see: advisory apps, insurance claim processing, credit scoring, market linkage tools – built by the state, by private companies, or by both, all drawing on the same underlying verified data instead of collecting it fresh each time.
Once identity and data exchange are solved once, at the state level, adding a new service – a new insurance product, a new advisory feature, a new credit scheme – becomes a matter of building on top of existing infrastructure, not commissioning an entirely new system from scratch.
It’s easy to conflate an agriculture DPI with just another government app for farmers. The distinction matters for anyone evaluating, funding, or procuring one:
| Traditional government farmer app | Agriculture DPI |
|---|---|
|
One department, one closed system |
Shared registry any authorised department or partner can use |
|
Data re-collected for every new scheme |
Farmer, land, and crop data verified once, reused everywhere |
|
Vendor owns the data model and the roadmap |
Open standards mean the state can bring in new services or vendors |
|
Farmer downloads a new app for every service |
Multiple services discoverable through one open network |
|
Success measured by app downloads |
Success measured by services actually delivered end-to-end |
Not quite. Several agriculture DPIs – including state platforms – are built and operated by private technology partners. What makes something DPI isn’t who builds it, but whether it’s built on open, interoperable standards the state actually controls, rather than a closed system only the vendor can modify.
The opposite is usually true. DPI is designed so multiple apps and services can exist on top of the same shared data layer – a state advisory app, a private insurance app, and a bank’s credit app can all draw on the same verified farmer and crop registry without needing to be the same product.
An agriculture DPI is closer to a utility than a one-time software delivery. Registries need continuous updating as land changes hands and crops rotate season to season, and governance rules for who can access what data need active management – this is covered in more depth in our piece on agri-DPI governance architecture.
Vendor scale and architectural openness are two separate questions. A large, well-known technology provider can still deliver a closed, proprietary system, while a smaller specialist partner can deliver something built entirely on open standards. The only reliable way to tell the difference is to look directly at the data model and the contract terms – not the vendor’s size or brand recognition.
India’s national Agristack is building the registry layer at population scale, while individual states are building their own service layers on top of it. Andhra Pradesh’s APAIMS and Kerala’s KATHIR are both examples of state-level platforms built on DPI principles – open architecture, verified registries, and services designed to interoperate rather than sit in isolation. Both are covered in more depth in our dedicated case study posts.
The technology stack is only part of the story. States that get real value from an agriculture DPI typically have three things in place alongside the software itself:
For a state government evaluating an agriculture technology partner, the DPI framing changes the questions worth asking. It’s less “does this app work well” and more: is the data model open? Can another vendor build on top of this without starting over? Does the state actually own its registry, or is it locked inside one company’s proprietary system? Those questions are the subject of our companion piece on writing an RFP for a state agriculture DPI.
In practice, this shows up most clearly at contract renewal time. A state that procured a closed system typically finds itself negotiating from a position of weakness – switching vendors means rebuilding the registry from scratch. A state that procured genuine DPI can credibly evaluate alternative vendors for new services, because the underlying data and standards were never proprietary to begin with.
Not exactly. E-governance is a broad term for digitising government services generally. Digital Public Infrastructure is a more specific architectural approach – open, interoperable, population-scale – that can underpin e-governance efforts, but a digitised government service doesn’t automatically qualify as DPI unless it’s built to that standard.
This depends on the specific governance model, but the design intent behind DPI is that the government – usually the state agriculture department – retains ownership and control of the core registry, even when a private company builds and operates the technology on the government’s behalf.
Not necessarily. Many states already have land records, crop insurance data, and farmer databases in some form. Building an agriculture DPI is often more about re-architecting how existing data connects and interoperates than about collecting entirely new data from zero.
The national Agristack focuses on building foundational registries – farmer identity, land, and crop data – at the country level. A state agriculture DPI typically builds its own service delivery layer on top of that foundation, tailored to the state’s specific schemes, crops, and departments.
Government of India, Cabinet approval of the Digital Agriculture Mission – Press Information Bureau: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2050966
Related on this blog: Case Study: How Andhra Pradesh Built APAIMS
