Farming does not wait. When a harvester goes down in the middle of a weather window, every hour of downtime is measured in lost crop, not lost convenience. Our client, a working agricultural operation running a mixed fleet of tractors, harvesters, and implements, came to us with a problem every farm knows: machines fail at the worst possible moment, and the knowledge needed to fix them is scattered across manuals, dealer phone lines, and the memory of whoever fixed it last time.
Operation profile
- Sector: Mixed arable farming, UK
- Fleet: Mixed fleet of tractors, harvesters, and implements across multiple manufacturers
- How maintenance ran: Paper logbooks, dealer phone lines, forum searches, and the memory of whoever fixed it last time
- Systems in place: Service manuals (paper and PDF), supplier catalogues, a shared calendar, and a great deal of experience
The challenge
Equipment maintenance on the farm ran on paper, phone calls, and experience. Fault codes meant a call to the dealer or an evening spent searching forums. Parts were ordered reactively, after a breakdown, with lead times that could stretch across exactly the days the machine was needed most. Service intervals slipped during busy seasons because nobody had time to check the logbook.
None of this was a technology problem in the usual sense. The operation did not need a new ERP or a fleet management platform. It needed the knowledge and the follow-through to arrive at the machine, in the field, at the moment of the fault.
The audit
Before building anything, we spent time inside the operation mapping how maintenance actually happened, machine by machine and season by season. The patterns were consistent:
- Diagnosis depended on a few people. Most faults were resolved by the same one or two experienced hands. When they were unavailable, everything queued behind them, or waited on a dealer call-back.
- The same faults recurred. A large share of breakdowns were repeat occurrences of known failure modes, already diagnosed once before, but the fix lived in someone's memory rather than anywhere searchable.
- Parts were ordered after the breakdown, not before it. Wear items with predictable lifetimes were replaced on failure, with lead times that regularly overlapped the busiest field days.
- Service intervals slipped exactly when they mattered most. Routine maintenance was deferred during planting and harvest, the periods when a breakdown was most expensive.
The conclusion was the same one we reach in most operations work: the expertise existed, but it was trapped in people's heads and spread across systems. The opportunity was not to replace judgment; it was to deliver the right knowledge to the machine at the moment of the fault, and to let follow-through run itself.
What we built
We built a set of AI agents around the operation's existing way of working, not a new system to learn:
- A diagnostic agent that takes a fault description or error code, in plain language, and works through the likely causes using the fleet's own service manuals, maintenance history, and known failure patterns. It answers the way an experienced mechanic would: most likely cause first, what to check, what tools and parts the job needs.
- A scheduling agent that tracks service intervals across the fleet and books maintenance into the calendar around the operation's actual work, moving routine jobs away from planting and harvest windows instead of into them.
- A parts agent that turns a confirmed diagnosis into a parts list, checks suppliers, and prepares the order for a human to approve. Wear items are flagged for reorder before they fail, based on hours and season.
Every action that spends money or commits the calendar goes through a person. The agents do the research, the chasing, and the paperwork; the farm keeps the decisions.
Delivery
The engagement was tightly scoped: one workstream, one problem that mattered, shipped and in use within weeks.
- Scope. A short discovery mapped the fleet, the failure history, and the highest-cost downtime scenarios, and fixed the scope before any work began.
- Build. The diagnostic agent shipped first, trained on the fleet's own manuals and service history, and was in use in the field while the scheduling and parts agents were still being built.
- Deploy. The scheduling and parts agents followed, wired into the calendar and suppliers the operation already used. No platform migration, no new software to learn, no dependence on connectivity the fields do not have.
- Operate. Every diagnosis, fix, and part number now feeds back into the system, so the agents get more useful with each season.
Results
| Before | After | | --- | --- | | Fault diagnosis meant a dealer call-out or a lost evening on forums | Faults triaged in minutes, in the field, from a phone | | Diagnosis queued behind one or two experienced people | Any operator can work a fault through to likely cause and parts list | | Parts ordered after breakdowns, with lead times across peak days | Wear items flagged and ordered before failure, based on hours and season | | Service intervals slipped during planting and harvest | Routine maintenance booked around field work, and the schedule defends itself | | Fixes lived in the memory of whoever was there | Every repair recorded in a system the operation owns, making the next one faster |
The deeper change is where the knowledge lives. Diagnoses, fixes, and part numbers now accumulate in a system the operation owns, instead of leaving in the head of whoever happened to be there. Every repair makes the next one faster.
Why it worked
The engagement was tightly scoped: one workstream, one problem that mattered, shipped and in use within weeks. No platform migration, no new software for the team to learn, no dependence on connectivity the fields do not have. The agents met the operation where it already worked.
AI does not have to mean a transformation program. Sometimes it means the harvester is running on Thursday.