AI in Agriculture

Agriculture’s constraints are physical and they arrive in an unusual order: how fast the machine is moving decides the compute budget, whether there is signal decides the architecture, and how many growing seasons you have decides how fast anything can get better.

The budget is set by ground speed

Targeted spraying — deciding per nozzle whether the patch below is crop or weed — is the flagship vision application, and its latency budget is arithmetic rather than preference. A sprayer at 15 km/h is travelling 4.17 m/s. If the camera sees a patch of ground and the nozzle passes over it after, say, 30 cm of travel, the whole loop — capture, inference, valve actuation — has about 72 ms. Widen the gap between camera and boom and you buy time; run faster and you lose it in direct proportion.

That budget rules out every remote inference design before anything else is considered. It is a small vision model on a device bolted to the implement, in a metal cabinet, in the sun, vibrating, and — a detail that catches software teams — the model has to hold up under lighting that changes from flat overcast to hard low sun within one pass of a field, and under dust. What holds up is a narrow model trained on data from these conditions, not a general one. Edge inference covers the deployment side.

The metric matters as much as the model. Two errors cost differently: spraying a crop plant damages yield, and missing a weed costs almost nothing on a single pass because there will be another. So the operating point is chosen for very high precision on the “spray” decision and whatever recall that leaves, which is the opposite of the default a general benchmark would tune to.

One season per year

This is the constraint with no equivalent anywhere else in this cluster, and it dominates project planning. A disease appears at a particular growth stage, in particular weather, on a particular cultivar. If your data collection was misconfigured that fortnight, or the disease pressure was low, the next opportunity is twelve months away. There is no iterating weekly and no rerunning the experiment with a fix.

Three consequences follow, and they are the difference between a project that compounds and one that restarts every spring:

• Over-collect deliberately. Capture far more imagery than the current model needs, with location, date, growth stage, cultivar and weather recorded alongside. The metadata is worth as much as the images and it cannot be reconstructed later.
• Assume transfer will disappoint. A model trained in one region on one cultivar under one soil type frequently degrades elsewhere, and the degradation is not visible without local validation data. Plan for a validation set per region rather than treating geography as a deployment detail.
• Label as you go. The agronomist who can tell you what that lesion is has to look at it in the field or at least the same week. A photograph labelled from an archive nine months later is labelled by guesswork.

For advisory applications — a grower photographing a leaf and asking what it is — the honest output shape is a short ranked list with confidence and an explicit route to a human agronomist, not a single answer. A wrong identification leads to a wrong product, which costs a spray pass, a pre-harvest interval, and in the case of a fungicide applied to the wrong target, contributes to resistance that outlives the season. Abstention is the general treatment, and here the thing being abstained from is a purchase.

There is no signal in the field

Fields are the canonical bad-connectivity environment: partial coverage at the headland, none in the middle, and a machine that may be out for fourteen hours. Any design that assumes a request-response to a hosted service is a design that works in the yard and fails at work.

The workable pattern is the same as field logistics: everything the machine or the phone does works offline and queues, syncing when the operator is back within coverage. Anything that must be immediate runs locally, which for a phone in a grower’s hand means a small on-device model — running models locally and small language models set out what fits. Anything that can wait — the seasonal report, the record-keeping summary — happens at the shed on a real connection, and batching it there is cheaper as well as more reliable.

The document task worth doing

The language application in agriculture that is genuinely valuable and rarely mentioned is reading agrochemical product labels. A label is a long, structured, legally binding document specifying application rates per crop, maximum applications per season, pre-harvest intervals, buffer zones to watercourses, tank-mix compatibility, personal protective equipment, and resistance-management group. Applying a product contrary to its label is an offence in most jurisdictions and can render a crop unsaleable if a residue limit is breached.

The documents are PDFs, they differ per product and per country, they are revised, and a grower planning a tank mix has to cross-reference several of them against a crop at a particular growth stage. That is exactly the shape retrieval and extraction handle well — and it is also a case where the correctness bar is absolute and the design must reflect it: extract to a structured record with citations to the label page, show the source text beside every figure, refuse rather than infer when a crop is not listed, and treat the extracted record as an aid to reading the label rather than a replacement for it. Pre-harvest intervals and rate limits are the fields to test hardest, because they are the ones with a consequence measured in a rejected load.

The same applies to the growing pile of traceability and assurance paperwork — field records, spray diaries, audit evidence for farm-assurance schemes. It is genuine drudgery, the source data already exists in the farm management system, and the failure mode is a rework rather than a loss. This is not agronomic or legal advice, and label requirements are jurisdiction-specific.