Why agriculture AI gets stuck at pilot

There is a phrase that has been repeated at every agritech conference I have attended in the past two years: “the pilot graveyard.” Most agricultural AI pilots that were funded and run between 2022 and 2024 did not graduate to production. The startups behind them either pivoted or quietly wound down. The agribusinesses that hosted them moved on to the next vendor. The cycle is now repeating, with a fresh class of GenAI-flavoured pilots in 2024 lining up to make the same exit.

We have been close enough to enough of these to see the pattern, and it is not a model-quality problem: the models of 2024 are good enough for production use cases. The reasons pilots get stuck are structural, and better models are not fixing them.

Domain depth cannot be rushed

Many pilots fail because the team running them does not understand the domain well enough to know when their product is wrong.

A general-purpose vendor builds an agricultural chatbot in six weeks. The chatbot is fluent. It answers questions confidently. The pilot is hosted by an agribusiness that does not have the technical capacity to evaluate the chatbot’s answers in detail, so the evaluation falls to surveys and aggregate satisfaction scores. The chatbot passes those. The pilot is declared a success. The agribusiness asks the vendor for an extension to a thousand-farmer deployment.

Six months in, the agribusiness’s compliance team starts noticing that the chatbot is recommending products at rates outside label. Or recommending products that are banned in the state the farmer is in. Or generating advisory in technically correct but agronomically wrong directions (“yes you can plant this variety in this district” when in fact the variety is not adapted to the agro-climatic zone). Each of these is a quiet legal risk for the agribusiness. The pilot’s relationship dies on contact with this risk, not on the model’s headline accuracy.

What closes this gap is not a better model but enough domain coverage in the training data, the retrieval layer, and the validation step that the model cannot make these classes of mistake, and that coverage is years of work. A vendor that has not put the years in cannot fake it; the missing coverage surfaces in production as compliance risk, which is why the vendors who did put the years in are the ones who reach production.

The last mile eats everything

Then there is distribution. Getting the product into the hands of the actual farmer eats far more engineering, design, and operations effort than most teams budget for.

A working ag-AI model gets you to the starting line. Getting it to the farmer is the harder problem. The phone has 3G coverage that drops to 2G in the field. The audio capture is from a five-year-old budget Android. The farmer’s voice is in a regional dialect the model needs to handle. The farmer cannot read, so the response has to be spoken back, in the same dialect, in under three seconds, otherwise the farmer’s attention has moved on. The interaction has to handle the farmer hanging up halfway through and coming back tomorrow with a follow-up question. The retention of the conversation has to persist across these breaks.

Each one of these is its own engineering investment, and each one is the kind of work that does not show up in a sprint plan because it is not a feature. It is plumbing. Most pilot teams allocate 70% of their engineering time to model quality and 30% to the last mile, when the ratio that actually gets a deployment over the line is closer to the reverse. The teams that ship are the ones that treat the voice pipeline, the conversation-state handling, the multilingual layer, and the low-bandwidth audio chain as first-class engineering objects with their own sprint allocations.

Enterprise procurement is not built for this

The last obstacle is purely about the business shape of the customer.

An agribusiness procurement cycle is 18-24 months. AI products move much faster than that. By the time a procurement team has evaluated a vendor, completed legal review, run a pilot, evaluated the pilot results, and negotiated a multi-year contract, the model the vendor pitched 18 months ago has been replaced twice. The procurement decision is being made against an outdated technical reality.

Worse, agribusinesses are not buying AI as a standalone product. They are buying it as part of an existing operations stack (a CRM, a field operations platform, a distributor management system), and the AI vendor has to integrate into that stack. Integration is its own contract negotiation, its own technical scope, its own timeline. Many pilots get stuck not because the AI does not work but because the integration timeline collides with the existing stack vendor’s roadmap and one party blinks.

This is the problem the developer platform we shipped in October is aimed at. When the unit an agribusiness buys is a platform it can integrate against now, rather than a multi-year custom build, the procurement team gets to make its decision against a current technical reality instead of an 18-month-old one, and a procurement team that would never finish a custom-build pilot will finish a platform deployment.

The pilots that make it through

Pilots that graduate have a vendor that has spent the years on domain depth, an engineering organisation that has spent them on the last mile, and a product shape that fits the buyer’s procurement reality. None of these are luxuries; they are the entrance requirements for production deployment in agriculture.

The reason ag-AI has felt slower than other vertical AI is that all of this is hard, and the field is collectively learning that the model-centric playbook from consumer and general-enterprise AI does not transfer here: the bottleneck has been in places the model is not.

My guess is that the conference version of this talk changes once enough deployments have survived three seasons. The interesting speakers will be the teams that can explain what broke in production, how they fixed the coverage and plumbing, and how procurement finally got out of the way. Until then, “pilot graveyard” remains an accurate, if tired, name for the problem.