The Forward Deployed

Real Deployments

FDE Case Study: John Deere and Blue River See & Spray

Study a production computer-vision deployment where latency, field conditions, hardware, safety, measurement, and adoption meet the physical world.

By Reviewed

Real and cited, with two honesty notes up front. First, this is not an OpenAI engagement and not a forward-deployed vendor project. See & Spray is John Deere's own technology, built by Blue River Technology, which Deere acquired in 2017. Second, it isn't an FDE staffing model; it's here as the clearest public example of the hardest thing this role's work demands: production AI that meets the physical world in real time, on messy data, where a wrong answer is a real event. Where the public record runs out, the page stays high-level.

The customer context

Broadcast spraying treats a whole field to kill the weeds in part of it, so most of the herbicide lands on bare soil or crop. See & Spray puts cameras and onboard processors on the spray boom; computer vision distinguishes crops from weeds in real time and fires individual nozzles only at the weeds. In 2025, John Deere reported the system ran across more than five million acres and reduced non-residual herbicide use by an average of nearly 50%, saving nearly 31 million gallons of herbicide mix. Independent field trials from the University of Arkansas put the reduction in a comparable range against broadcast spraying.

The distinctive tension

Every case turns on one thing. Here it's real-time correctness at the edge, on data the lab never saw.

The model has no cloud, no second chances, and milliseconds to decide. The machine moves at up to 15 mph, scanning over 2,500 square feet per second, classifying every plant and actuating a nozzle before it passes. A demo that works on clean images in an office is worthless; the system has to be right on a specific weed, at speed, in dust and glare and rain, in a field it has never seen. John Deere framed 2025 as a season of "elevated weed pressure and frequent rains", and it still cleared ~50%.

Before reading on: you have a weed-vs-crop classifier that scores well on your labeled test set. Name the reason it might still fail in a customer's field. It isn't the model architecture.

The reason is distribution shift: your test set is clean daytime images from a few farms, and the field is a different lighting, a different weed you never labeled, mud on the lens, a crop stage you didn't sample. The model is only as good as how well your evaluation data matches the messy reality it'll actually run on.

How the FDE-relevant work maps

Public sources describe the outcome and the constraints, and Blue River's own engineers have put the core of the vision stack on the record, though the full production pipeline stays private. The shape of the work is the shape this whole site teaches.

  • The data problem is the product. A classifier is easy; a classifier that holds across regions, weeds, crops, lighting, and weather is the years of work. That's the evaluation discipline at industrial scale. The gap between demo and field is closed by relentlessly expanding what you measure against.
  • The constraint drives the architecture. Real time and no cloud force inference onto the machine at the edge, a cost-and-latency constraint so hard it dictates the whole design. You cannot round-trip to a server; the model runs where the nozzle is.
  • Being wrong is a real event. Spray a crop and you damaged it; miss a weed and the field suffers. There's no "confidently wrong text" here. The failure is physical, which raises the bar on knowing, continuously, that it still works.

The stack, on the record

For a system this proprietary, an unusual amount of the vision stack is public, because Blue River's own director of computer vision and machine learning, Chris Padwick, documented it in 2020. The classifier is a convolutional neural network (CNN) trained in PyTorch that segments each camera frame pixel by pixel, labeling crop versus weed instead of judging the frame as a whole, and that per-pixel map is what lets the boom aim one nozzle at one plant. The model runs on the machine, on an NVIDIA Jetson AGX Xavier built into the sprayer; NVIDIA's own account describes those onboard modules deciding weed-or-crop on frames from the rig's cameras in real time, since a moving sprayer has no server to call and milliseconds to decide. That write-up is from 2020, so the current fleet likely runs newer silicon and an updated model; the durable part is the shape, a CNN classifying every pixel at the edge in real time.

Bad / Good / Great — "your classifier works in testing; how do you know it'll work in the field?"

Bad — "it scored high on our test set, so it's ready." A benchmark number with no relationship to the field's distribution. It's the answer of someone who's never watched a model meet reality. The test set is clean and the field is not.

Good — "we'd test on data from several real farms before shipping." A real step toward field validation, sampling actual conditions. The gap: it's a one-time check, and it says nothing about the conditions and weeds you didn't sample, or about catching failures once it's running at scale.

Great — "the field is a different distribution than any test set, so the work is continuously expanding what I evaluate against — new regions, weeds, crops, lighting, weather — and measuring on the ugly cases rather than the clean ones. I'd instrument the machine to surface where it's uncertain or wrong so those cases feed back into training, and I'd treat robustness on messy real input as the metric, ahead of benchmark accuracy." You located the problem in the data distribution and made the evaluation a standing, expanding process, the reason this took years of work.

The transferable pattern

When AI meets the physical world in real time, the achievement is robustness on messy real input, not accuracy on a clean benchmark. You get there by making evaluation a continuously expanding process against the ugly cases. The model is the easy part; the gap between a demo and a field is closed by the data and the eval discipline. Carry this into any system-design round with real-world sensing: lead with how you'd measure correctness on the distribution you'll actually face, and how you'd catch the cases you didn't anticipate.

Sources & further reading

Next: Airbus × Palantir. The engagement where the product is the trusted integration itself.
NextAirbus × Palantir