AI in agriculture: what you need before buying a single sensor

AI in agriculture is almost always sold backwards: the device first, the question later. A sales rep turns up with a probe, a drone or a platform with a pretty satellite map, and the farm buys hardware before deciding which decision it wants to make better. Two seasons on there are buried sensors nobody reads and an annual subscription renewing out of inertia.

This article runs the other way round. First the decision — how much water, which treatment, how many tonnes am I expecting — then the data that decision demands, and only at the end what needs installing. The focus is mid-sized operations: 50 to 500 hectares, one field technician, no data team, and a farm ERP or, in plenty of cases, a well-kept spreadsheet.

What does AI in agriculture actually solve?

Three things get mixed together in the same brochure, and it helps to separate them:

• Data capture. Soil moisture probes, weather stations, flow meters, satellite or drone imagery, machinery sensors. This isn't AI: it's instrumentation. But without it there is nothing to model.
• Rule-based automation. "If soil tension drops below X, open sector 3." That's an automatism. It solves a great deal and needs no models. Most farms that think they need AI need this.
• Predictive models. Estimating evapotranspiration for the next five days, the risk of a specific pest, or the kilos coming off each plot. This is where learning from history genuinely applies.

The expensive mistake is jumping to the third point without doing the first. A yield forecasting model needs several seasons of clean per-plot data; if you've been measuring for a year, no model will save you. The same holds in other sectors: we cover it in data before AI, and it applies just as well to farming.

If you can't say what was done in plot 14 on 3 May last year, you don't have an AI problem: you have a field-record problem.

When does AI pay off in irrigation?

Irrigation is where the investment comes back fastest, for a simple reason: water has a price, so does pumping energy, and over-irrigating costs twice (extra water plus fertiliser leaching).

What a data-driven irrigation system decides:

• When to irrigate. Based on actual soil moisture at several depths, not on the calendar.
• How much. Water depth matched to the crop's estimated demand over those days.
• Which sector first. When available flow won't cover everything at once.

What it takes to set up:

| Element | Useful minimum | Why | |---|---|---| | Moisture probes | 1 point per homogeneous irrigation sector, 2-3 depths | A single point for the whole farm represents nothing | | Weather station | 1 on site, or a public one within 10 km | Needed to compute reference evapotranspiration | | Flow meter | 1 per sector, or at least at the head unit | Without measuring applied water you can't know your error | | History | 1 season to calibrate rules, 3 for a model | Before that you work with agronomic rules | | Remote valve control | Desirable, not essential | Without it the system recommends and a person irrigates |

Start with rules and assisted weekly scheduling. Once you have a season of moisture data, applied water and crop response, a model can fine-tune the depth. The step change doesn't come from the algorithm: it comes from no longer irrigating out of habit.

One practical note: install the flow meter on day one even if you automate nothing. It's the only figure that later lets you say whether the change worked. No baseline, no way to measure return — and that holds for any project, as we explain in measuring AI ROI.

Can pests and treatments be decided from data?

Yes, with important caveats. Pest and disease risk models have worked in agronomy for decades: many are degree-day and leaf-wetness models, not machine learning. They're reliable, cheap to deploy and published for the main crops and pathogens.

Where modern AI does come in:

• Image analysis. Photos of sticky traps or leaves to count insects or classify symptoms. It saves walking rounds and standardises counts across technicians. It's the same class of solution we describe in computer vision for business, applied to the field.
• Vigour maps. Satellite vegetation indices to spot zones diverging from the rest of the plot and send inspection where it matters.
• Variable rate application. More or less product by zone, where the machinery allows it.

Where it doesn't come in, and this is worth saying plainly: AI does not replace the technician who diagnoses. A vigour map flags an anomaly; it doesn't tell you whether it's a fungus, a nitrogen deficiency or a blocked dripper. The healthy sequence is data → alert → inspection → technician's decision, and the saving lies in inspection being targeted instead of criss-crossing 200 hectares.

Two warnings about free satellite imagery:

• Cloud cover leaves gaps of weeks at the most interesting point in the cycle. If your decision needs imagery every 5 days, you need a drone or a contracted flight.
• Standard resolution (10 metres per pixel) is for zoning large plots, not for looking at a single plant.

What does real yield forecasting require?

Yield forecasting is the most requested case and the one that disappoints most when tackled without method. It gets requested because it's the number that genuinely moves money: processor contracts, harvest logistics, crews, cold storage and packaging.

What a model needs, in order of how hard it is to obtain:

1. Actual production per plot and season, not aggregated per farm. That's the target the model learns to predict. Without three or four seasons of it, there is nothing to train on. 2. Traceable operations per plot: water applied, fertilisation, pruning, treatments, dates. This is what explains differences between similar plots. 3. Stable agronomic data: variety, rootstock, planting year, spacing, soil type. 4. Season weather: chill hours, heat spikes, rain during flowering. 5. Field observations: fruit set, manual counts on fixed dates.

With that you can build a per-plot forecast that updates through the cycle and narrows its margin as it goes. What you can't do is demand contract-grade precision in June: a serious agricultural forecast comes as an interval, not a single number. "Between 180 and 230 tonnes, 80% confidence" is a professional answer; "212 tonnes" in May is marketing.

One method error we see often: training the model on the good seasons and leaving out the bad ones. If your history only holds normal years, the model has no idea what a late frost does and will miss it entirely. It's the same historical bias that shows up in industrial demand forecasting.

What about machinery, livestock and the packhouse?

Three less glamorous fronts where data pays off quickly:

• Machinery. Tractors and irrigation equipment with logged running hours and breakdowns allow condition-based maintenance instead of calendar-based. It's exactly the approach behind predictive maintenance: it pays off when a breakdown mid-harvest costs far more than the service.
• Livestock. Collars and pedometers for heat detection and early health alerts. One of the most measurable returns in the sector, because a missed heat has a known cost per farm.
• Post-harvest and packhouse. Image-based grading on the packing line, forecasting intake at the co-op, packaging planning. Here the problem stops being agronomic and starts looking like any inventory optimisation exercise.

How do you start without wasting money?

A route that works on a mid-sized operation, in the order we recommend it:

| Phase | What happens | Duration | What you end up with | |---|---|---|---| | 1. Tidy the field records | Digitise operations per plot with a unique, stable identifier | 1-2 months | History starting to accumulate | | 2. Measure what it costs | Flow meters, electricity use, machinery hours | 1 month | A baseline to compare against | | 3. First rule-based case | Moisture-driven irrigation on 2-3 pilot sectors | 1 season | Measurable saving and team confidence | | 4. Extend | Remaining sectors, published pest risk models | 1 season | Stable operations | | 5. Prediction | Per-plot yield forecast with an interval | From season 3 onwards | A figure useful for contracts and logistics |

Two rules that save grief. First: a plot identifier that is unique and permanent. If the plot is "South Farm 2" in the ERP, "P-14" on the map and "the almond one" in the technician's notebook, the history can't be joined and four years of data are worthless. Second: before signing with a platform, ask to export your data. If there's no complete export in an open format, you're renting your own history.

On grants: Spain has agricultural digitisation funding lines, but they change every year and by region. Treat them for what they are — a discount on a project that already made sense — not the reason to do it. A subsidised sensor nobody looks at is still money gone.

Frequently asked questions

How many years of data are needed to forecast yield?

For a model with real utility, three or four seasons with production recorded per plot. With less, you can estimate from manual counts and agronomic rules, which is perfectly valid while the history builds up.

Is free satellite imagery enough, or do you need drones?

Public satellite imagery works for zoning large plots and spotting vigour anomalies. If you need plant-level resolution or guaranteed frequency without cloud gaps, you need a drone or a contracted flight.

Can a mid-sized farm do this without an IT person?

Yes, if it starts by tidying the field records and plot identification, which is organisational work, not programming. Technical support comes later, when integrating sensors and data into a single place.

Which case returns the investment soonest?

Irrigation, nearly always, because water and pumping energy have a known price and the saving is measured with a flow meter. In livestock, heat detection usually runs it close.

If you're weighing up where to start on your operation and want a view with no sales rep behind it, in our audit we look at what data you already have, what's missing and which case pays off first with your own numbers. And if you'd rather talk it through first, let's talk.