AI development for agriculture: pilots don't make it to the field
A typical story in AI for agriculture: a team trains a model on images from past seasons, gets clean accuracy on a holdout set, and presents it at review.
A month later, in a real field, the same model confuses crops and misses weed patches, and the agronomist stops opening the report.
The reason is almost always a mismatch between training data and reality: the variety changed, imagery was captured from a different altitude and in different cloud cover, some frames are darkened or blurred, and the seedlings are at a different growth stage.
The model works confidently where features match the training set and falls apart on the first field that doesn't look the same.
Yield forecasting is harder: a whole season passes between the image and harvest, and an error cannot be noticed and corrected immediately. No feedback appears for retraining, so quality does not improve from season to season.
As a result, a field AI pilot does not reach the decision-making loop. There is no protocol for imaging, labeling, and retraining; it is unclear who is responsible for the data and how the result gets into the farm's accounting system. The solution quietly settles in the developer's working folder — the farm does not use it.
AI development for agriculture starts not with the model but with the field data loop: an imaging protocol, labeling by agronomists, a metric tied to the decision — to treat the plot or not.
Then computer vision for fields and yield forecasting can withstand changes in variety, weather, and machinery. We break down how this is covered.
What AI in agriculture delivers: effect by plot
The effect of AI in agriculture is measured not by how "smart" the model is, but by the share of patches found on time and the number of extra machine passes.
Precision farming begins where there is a history for each plot: Sentinel-2 imagery, sensor readings, agronomist field walks, onboard logs of harvesting machines.
While the sources live separately, decisions are made on the field average — and a disease patch is noticed when it is already visible from the edge.
Field monitoring is moved into a regular cycle: every few days, fresh imagery is compared with the plot's baseline, and the model marks zones where the vegetation index has dropped faster than usual.
Early detection of plant diseases is measured specifically by the share of patches found before a noticeable part of the leaf surface is affected — treatment is applied as a patch, not across the whole field.
What changes in operations
Harvest planning is built around plot maturity, not the calendar: machinery enters where the crop is ready and does not return to ripening edges.
Repeated passes over the same contour are reduced, machine wear and fuel consumption fall, and the harvest window stops being a race against the weather.
Plot-level yield forecasting becomes stable: the model returns a range, not a single number, and it shows which fields are dragging down the overall result.
Management is fact-based: patches are caught earlier, machinery makes fewer passes, and the harvest plan matches the real picture of the field.
Implementation formats: from a pilot on one field to the entire network
Implementation format is determined by two things: how much data has already been accumulated on the farm and how typical the process we are automating is.
Comparing options "in general" is pointless — the difference shows up at the stage when the pilot needs to be turned into a working system, not a demonstration.
| Option | When it fits | Limitations |
|---|---|---|
| AI pilot project on a limited area | Need to test the effect on your own data: one or two fields, a specific crop, one machine | The model does not see the diversity of soils and seasons; the result does not transfer to the network without retraining |
| Retraining the model on farm data | Processes are typical; there is a history of operations, machine telemetry, imagery from past seasons | Requires a labeled dataset; quality depends on primary data, rare risk classes are detected worse |
| Model for a specific task from scratch | A non-typical process: your own agronomy, specific crops, a non-standard fleet of machinery | Longer development cycle, data is collected from the first season, labeling by agronomists |
| AI onboard machinery | No stable connection in the field, a decision is needed at the moment the machine moves | Onboard compute resources are limited, model updates are more difficult and less frequent |
The difference between formats is not in model complexity but in who is responsible for the data and how quickly the cycle closes on the result.
In a pilot, the dataset is small and from one area; with retraining, a labeled set from several seasons is needed; with task-specific development, agronomists participate in labeling from day one.
Practical order: first we look at what already exists on the farm, then we choose the format, and only then do we fix the architecture. If the task allows a pilot, we start with it, but with a pre-defined criterion for scaling to the entire network.
How we implement: from data audit to handover into operation
The workflow is the same for yield forecasting and fruit sorting: first we assess what is already in the data, then we fix the goal in measurable terms.
The stages are sequential — a skipped agricultural data audit produces a model that works on archived fields and falls apart in the field.
- Agricultural data audit. We look at what has been accumulated: machine logs, imagery, sensors, agronomist records, samples. We assess completeness, frequency, and missing-data rate — this determines which tasks can be solved without additional collection.
- AI problem statement with a measurable goal. We formulate the result in field terms: what we predict, over what horizon, with what permissible error. We agree it with the agronomist — otherwise the model metric diverges from the decision they make.
- Solution design. We define features, bring heterogeneous sources to a single grid by fields and dates, and mark places where additional collection or labeling is needed.
- Collection and labeling. We supplement the archives, agronomists label disputed cases, and we document the rules in writing so that the assessment of one plot does not differ between specialists.
- Model training and validation. We test on holdout plots and seasons the model has not seen, and separately analyze errors at field boundaries, under anomalous weather, and on rare crops.
- Handover of the solution into operation. We connect it to the accounting system, set up reporting and a protocol: what to do when model confidence is low and who makes the final decision. We train agronomists and support the first weeks — discrepancies on live data become the basis for retraining.
Datasets, labeling, and model retraining protocols
A model that recognizes seedlings and affected patches rests on data, and its ability to evolve rests on clear procedures.
Crop rotation changes, machinery is added, fields shift their boundaries — and without documented artifacts, no one except the system's author can say why accuracy dropped on a specific plot.
- Dataset for the agricultural model — imagery and telemetry for a full season, organized by plot, crop, and growth stage, with a description of sources and imaging periods.
- Data labeling rules — how to mark seedlings, weeds, and affected patches; from what threshold a disputed example goes to the agronomist for rechecking.
- Model passport — what task it solves, what data it was trained on, for which crops and conditions it is applicable, where it makes mistakes more often, and how often it is checked.
- Retraining protocol — triggers (new crop, new season, accuracy drop), the data preparation procedure, who approves the version, and how to roll back to the previous one.
- AI solution documentation — exchange schemas with the accounting system, input and output data, roles, access, and the procedure for granting rights.
- Instructions for agronomists — how to capture, what to check on site, how to dispute the model's conclusion, and where feedback goes.
- Control set — examples with a pre-known correct answer: every new version is run on them before going to the fields.
The set stays on the farm and is updated together with the model — the system continues to work when the season, crop, and people change.
Case study: how a class of plant disease failures was eliminated
The client — the agricultural holding Severnoye Pole — came after a season in which the same failure class repeated year after year: a disease patch was found at the field periphery and in zones of uneven irrigation when 10–15% of the leaf was already affected.
A field walk took up to three days, during which the patch expanded, and treatment was applied across the entire plot.
We started not with the model but with metrics: how many patches are detected at an early stage, how many false positives occur per confirmed case, and how much time passes from imaging to decision.
The history of observations from past seasons was labeled by coordinates — this gave a basis for comparison instead of the feeling that "it got better."
We changed three things: spot segmentation on imagery with coordinate referencing, activation thresholds by crop and vegetation stage, and the agronomist's inspection route instead of a continuous survey.
The agronomist remained the control loop: their confirmation returns to the training set, so the next season is more accurate than the previous one.
Metrics before and after
Share of missed patches — from 12% to 3%; false positives — from five per confirmed case to fewer than two; time from imaging to verdict — from three days to several hours.
The failure class "late detection of a peripheral patch" stopped repeating: treatments became spot-based, and the volume of preparations per plot fell by about a third.
"Previously we learned about the problem when the leaf was already yellow. Now the agronomist goes to a point with coordinates — the field walk has been reduced, and we make decisions based on data," — chief agronomist of the farm.
How yield forecasting differs from irrigation advice
Yield forecasting and irrigation advice are two different classes of tasks, and confusing them is costly. Forecasting answers what will happen to the field; management answers what to do with it now.
A predictive model in agriculture describes the system; a management task in farming intervenes in it and changes the field's state.
That is why different data is needed. Forecasting is satisfied with multi-year yield series by field contours, weather, soil maps, crop rotation history, and imagery in several spectral channels.
Irrigation recommendations additionally require an irrigation log, the lag in the crop's response to moisture, and limits: water volume, system throughput, and machinery schedule.
| Criterion | Yield forecasting | Irrigation recommendations |
|---|---|---|
| Question | how much we will harvest | when and how much to irrigate |
| Data | weather, soil, imagery, past-year yield | plus irrigation log and water limits |
| Validation | error on held-out seasons | comparison with a baseline strategy |
| Result | estimate with an error range | action plan with rationale |
Quality is checked differently. Forecasting is validated on held-out seasons, not on a random sample of observations: otherwise neighboring days of the same field will end up in both training and validation, and the error will be underestimated.
Recommendations are checked by comparison with a baseline irrigation strategy and by monitoring constraints.
Hence the choice of model type. If an action plan is needed, the forecast becomes an input for optimization under constraints, not the final result. In AgriTech AI projects, we first fix what the system decides — an estimate or an action — and only then choose the model.
Common doubts: model accuracy and connection to accounting
Agricultural model accuracy is not a property of the algorithm but a consequence of the farm's data: if the training set was collected on other varieties, soils, and machinery, it will drop on your contours.
Therefore the first step is an audit of what has been accumulated: a history of field operations, weather data, imagery, agronomist logs. This is enough for a working version for a narrow task, but not for an "ideal" solution across all crops at once.
Below are the objections most often raised at the start, and how we address them engineering-wise.
We have little data — will it be enough for the model?
The minimum set is two or three seasons of history by crop and plot boundaries. We start with a task where labeling can be partially extracted from your own logs: for example, identifying zones of suppression by vegetation indices. We collect the rest during the pilot in one cycle.
A monitoring system is already deployed — will we have to change it?
No. We connect to existing sources through standard interfaces, align coordinates, the treatment calendar, and crop directories, and supplement the missing layers. The existing monitoring loop and accounting system stay in place, and we return results into them.
Machinery operates without a stable connection. How is this accounted for?
The computation runs on the onboard computer: recognition happens locally, and the channel is needed only to synchronize results and update the model. If the connection drops, the machinery keeps working, and data is uploaded later without losing operations.
Won't the model degrade over a season?
Drift is inevitable: varieties, agricultural practices, and weather change. We build in quality control by class and a retraining protocol on fresh data.
When accuracy falls below the threshold, the system does not issue a recommendation but marks the plot as requiring an agronomist's check.
Who is responsible for labeling quality?
We perform labeling according to an agreed protocol, and send disputed cases to the agronomist for confirmation. You receive a dataset with versioning and class descriptions — reproducible, reusable, and expandable.
Let's discuss the task: what to send for project evaluation
AI project evaluation does not hinge on a description of the idea but on the state of the initial information about the farm.
A ready-made technical specification is not needed — what is already in use is enough: exports from accounting systems, operation logs, agronomist records, field imagery.
Below is the minimum data set to start a project, after which we return with an estimate of the scope of work and a plan for the first stage.
- What we are solving: what decision a person makes today, based on what attribute, how often, and with what delay.
- What data already exists: from which systems information about fields, crops, machinery, and yield comes, and how often it is updated.
- Depth of history: how many seasons of observations are preserved and whether they include different weather conditions.
- What confirms the result: who and how recorded actual outcomes — we use them to check whether the pattern reproduces.
- Plot constraints: soil heterogeneity, zones with a special treatment regime, fields without stable connectivity.
- Where we embed the output: which system or workflow receives the result — an alert, a map, an in-field recommendation.
- Who is responsible for implementation on your side and what access you are ready to open at the first stage.
Based on this set, we name the scope of work, data risks, and boundaries of the first stage — usually a hypothesis test on a limited plot with a measurable criterion.
Describe the task in your own words: we will clarify what is missing with questions, not with a request to prepare documents.
