An analysis of an experience reported by John Deere, with illustrative examples for thinking about applications in other operations.
An application with a defined job
In a November 2025 announcement, John Deere describes See & Spray: cameras identify weeds and the equipment activates individual spray nozzles. The product documentation identifies computer vision and machine learning. This is AI connected to a specific physical task, using dedicated equipment. It is a different kind of system from one that interprets a conversation.
The useful starting point is the choice of application: a situation you can observe, a criterion for taking action and a way to check the effect. That sequence helps define a project with a clear beginning and scope before choosing a tool.
Start with the decision that needs to improve
Which decision in your operation depends on finding something out early? You might need to check production, understand why an activity stopped or identify a report that still needs confirmation. Each question calls for different information and people. Combining them all in an initial project makes it harder to tell what worked.
Choose a recurring task with an outcome your team can recognize. Describe how it works today: who reports, who checks, where the record lives and which action depends on it. Even this simple outline helps distinguish an information problem from a shortage of people, equipment or clear rules.
A possible test: from a voice report to a checked record
Imagine a production update sent as a voice message. An initial test could organize the quantity, location, activity and time, while keeping the original report available for review. If the location or unit is unclear, the workflow should ask for confirmation. Converting units requires a rule that applies to that operation and is understood by the reviewer.
The test would assess whether the team can record and check work more effectively while respecting how each activity is managed. Organized information does not, by itself, authorize closing a work order, changing inventory or making an agronomic decision.
What needs to be in place first
Define the fields you need rather than collecting everything just in case. Decide who can submit information, who reviews exceptions and where an approved record will be used. Account for conditions in the field: connectivity, noise, local terminology and the time people have to respond. The test needs to fit the work, including when information is incomplete.
Select examples from ordinary days and difficult situations. Include ambiguous messages, corrections and reports of work still in progress. Agree which steps the system may take and which require a person. A visible exception is more useful than a record that appears complete but is wrong.
Measure an improvement the team can recognize
Before the test, observe the effort required to check records, how many arrive incomplete and the delay before information becomes available. Track those same points afterward. Record new problems too: excessive confirmation requests, repeated corrections or tasks that have simply moved to someone else.
Agree on the intended improvement with the people doing the work and those using the information. If there is a consistent benefit, expand to a similar routine. If there is not, revisit the design. A first application is also a way to discover what conditions are missing.
A question for the next conversation
The transferable lesson is to choose the work carefully, identify the conditions it requires and check the effect. An application using cameras and machinery can inspire that discipline without providing a technical shortcut to another solution. Start with a concrete question: which information would change a decision if it arrived more clearly and at the right time?
Sources and context
Primary source: John Deere ↗ · .
Historical source consulted on September 16, 2026. Its original date is shown above; the analysis and application examples are Tenex’s editorial contribution.