Practical AI in Agriculture

AI has created a kind of super Dunning–Kruger effect on both sides of the value argument. Whether commentators exalt or decry the technology, they are supremely confident because they themselves are “using AI” daily. Their experience with AI in their own workload must, apparently, generalize to every possible workload.

I do not have a general answer to the AI value question. I have a narrower set of observations from building generative-AI tools for agriculture. Oxrow is a platform that uses generative AI to improve farm and agribusiness outcomes. These lessons are things I have learned alongside our product and engineering teams while trying to make it useful in real agricultural work.

Start with the jobs AI can finish

In any industry, dashboards, forecasts, reports, or a detailed ChatGPT exchange create deferred value. That value is often not realized until someone turns the information into a new plan, a different schedule, a revised budget, a call to a vendor, or work in the field. In short, these “systems of insight” produce contingent payoffs that may never arrive at all.

Large corporations in other industries often employ teams devoted to turning information into action. In a lean agribusiness, the person receiving the insight is more likely to be the same person running irrigation, allocating labor, managing equipment, negotiating rent, or talking to customers. The work that remains after an answer arrives is part of the total cost of the software itself. When buying software, ag operators tend to discount contingent payoffs and favor systems that shorten the path from insight to action.

Complete work loops. AI can create contingent payoffs too. Used for open-ended analysis, it often generates the next question, the next scenario, and the next handoff. Those outputs can be valuable, but their value still depends on further work by someone else. At Oxrow, we have found it helpful to start instead with complete work loops: a daily labor plan, a packout recommendation, a compliance draft, or a grower-returns report. The heuristic is simple: can an AI agent take a preexisting workload and return something the operator can approve and use immediately?

The lessons from robotic process automation are useful here: automation works best where the job is already well defined. The best starting point is not an open-ended question, but a recurring job with known inputs, known constraints, and a recognizable finished output. AI improves on traditional RPA because it does not require the entire rulebook to be explicit before it can help. In the right bounded workflow, it can handle routine work whose rules are only partly stated and improve that work by incorporating new information.

Examples from growers and packers. At one central Washington apple ranch, the operations manager assembled the morning crew plan by hand from labor records downloaded from an app, field priorities, crew availability, and the previous day’s progress. Oxrow now uses those same data sources to prepare a proposed crew plan before the morning meeting: assignments by crew, job, and ranch; expected hours and cost; overtime risks; and any exceptions that still require her judgment.

The same pattern appears in a different part of the business. At a tree-fruit packing house, the equivalent output is not a crew plan but a proposed packout plan: which exact bins to run, and what they are likely to yield by grade, size, culls, and packs per bin. To prepare that recommendation, the system pulls together inventory, QC and door samples, historical packout, the strategic crop pack schedule, and the marketing desk’s packing instructions.

Output quality. All of this makes an operator faster, but is the output any good? When the crew-planning agent sits on top of labor and payroll data, it can optimize against explicit operating constraints. It can see that ladder pruning averages $30 per acre overall; that three crews are running closer to $25 per acre; and that one of those crews is nearing this week’s overtime threshold.

The default task is to prepare tomorrow morning’s crew plan. But the operator can focus on a specific objective with a single instruction:

Give me a burn-down of this week's and month's labor budget, and recommend crew allocations that help us meet our cost targets without creating avoidable overtime.

This isn’t just a faster version of the old planning process. The agent is using the same operating data to weigh cost, crew performance, and overtime risk, and to propose a different allocation of work for the operator to approve. In a week where crew allocation is materially off plan, that kind of intervention is worth thousands of dollars in labor cost. The payback in time saved is immediate; the payback in dollars saved is weekly.

There are dozens of these multi-system job loops in ag, where an AI in the right context with the right tool calls can match or exceed human performance. Information in locations a, b, c, and d needs to be collated, cleaned, interpreted, and served at location e. One key reason these fast work loops are so effective is that they slot into existing, data-reliant workflows.

AI will be retrofit into existing ag processes before it transforms them

A lesson from electric power. In 1990, Stanford economic historian Paul A. David used the earlier spread of electric power to explain the computer-era productivity paradox. He argued that general-purpose technologies can create early gains while their larger effects are delayed by the systems, routines, and organizational structures built around what they replace. Factories first bolted electric motors onto steam-era plants, keeping the shafts, belts, layouts, and buildings. They inserted a new technology into the old operating model, and the larger gains waited for the rest of the organization to catch up.

Computers followed a similar path: firms added them to existing data-processing and recordkeeping routines, sometimes retaining paper procedures alongside the new systems. The larger payback came when information flows, roles, and operating models were redesigned around them. Agriculture is still partway through that transition. Many businesses work through a patchwork of crop-specific software, generic systems forced into agricultural work, spreadsheets, texts, and sometimes paper. That makes AI harder to integrate: before it can reason across the business, analogue information often has to be captured, structured, and digitized. But this scenario also creates immediate opportunities for AI to connect and act across work that existing software has served poorly.

Like the dynamo and the computer, AI is a general-purpose technology. Its cumulative value will not come from one feature or use case, but from deployment across organizational processes and the data they generate. In the near term, that often means retrofitting: making the existing operating model work better before redesigning it. Organizations are already redesigning work in software development, customer support, healthcare administration, legal operations, and finance, where AI increasingly handles first-pass work and people focus on exceptions, approval, escalation, and judgment.

At Oxrow, we are already seeing smaller versions of this redesign in agribusiness.

The best AI crosses systems; the best software vendors let it

Because agriculture is a many-hats industry, one operator may touch half a dozen single-purpose applications and documents in a day. Operators do not stay in clean functional lanes: agronomists become operations managers, CFOs become data scientists and customer-relations managers, and irrigators become construction engineers. That makes routine work high-friction: finding information, comparing it, translating it into a decision, and carrying that decision into the next system. AI is useful here because it can reduce friction both across systems and within them.

Two early use cases on the Oxrow platform illustrate the point. First, AI serves as a single interface across multiple applications. When someone is preparing a management review or a compliance report, it compiles the relevant information without requiring them to open each system, find the right report, export it, and reconcile it by hand.

Second, AI reduces friction even within a single application. A satellite-data or irrigation-sensor platform may contain the information needed to compare heat stress or evapotranspiration across fields and time periods, but not make that comparison easy. What might otherwise require dozens of clicks, exports, and calculations becomes an instant answer.

Retooling ag software. This raises an obvious question: will the ERP, irrigation, satellite, and other point-software providers simply add AI themselves? Some will, and they should. But AI layered onto a single-purpose system becomes single-purpose AI. It can work well for answering questions about the data it holds, but it is less able to help when the work requires that data to be combined with payroll, field operations, inventory, quality, weather, financials, or customer commitments.

The more important question for software vendors is whether they will make the data their systems generate available to the AI tools their customers choose to use, via MCP servers or APIs. When I began building analytics tools for agribusinesses six years ago, few agricultural-software vendors offered both accessible APIs and contract terms that clearly recognized the buyer’s right to use its own data. The situation has improved, but not enough.

For years, data access could be treated as a defensive issue: making it easy to extract data made it easier for a customer to defect. AI alters that logic. Customers will increasingly favor systems that are easy to connect to the rest of their operating data and to the AI tools that help them act on it. Interoperability will move from a feature that some vendors reluctantly tolerate to a competitive advantage, and eventually to a basic expectation.

If the old moat was keeping the customer’s data inside the application, the new moat is building an application that works effectively inside a customer’s wider operating system.

The AI model matters less than the context around it

For AI product companies such as Oxrow, the model matters less than the operating context built around it. Model capabilities have converged to a level of general competence where, for many general tasks, it is increasingly hard to distinguish their outputs.

A frontier model may be able to reason about labor, inventory, weather, irrigation, and finance in the abstract because it has been trained on much of the available knowledge in those fields — but it still needs to understand how those things relate in this particular business, which exceptions matter, what “good” looks like for this operation, what decisions it is allowed to make, and how its work should be checked.

Two observations I’ve read recently capture this gap between model capability and operating context better than I can:

“AI will win a Fields Medal before it can manage a McDonald’s.”

— Comment in a Hacker News discussion of AI and discrete geometry, May 2026

And, from a University of Nebraska–Lincoln assessment of ChatGPT on real-world crop production decisions:

“Data availability and quality are critical to AI performance. The system performed well when provided with structured, relevant data, but struggled when key inputs, such as real-time weather forecasts, irrigation costs, or spatial field variability, were missing.”

— Cory Walters, University of Nebraska–Lincoln, April 30, 2026

A discrete-geometry problem has a stable context. The operating context of a restaurant is changeable: inventory, staffing, demand, equipment, suppliers, and customer service can all shift within an hour. Agricultural work is like the latter. A capable model is necessary, but it cannot do useful work without a current picture of the operation and the means to act within it.

At Oxrow, we think of that context in five parts:

The model provides a general intelligence capability. The context layer teaches it how a specific business works, what it is trying to optimize, and how to perform a job loop without creating new work or risk.

Context in action. I witnessed this firsthand recently. We have developed an internal test suite to evaluate Oxrow against real-world requirements. One test comprised twenty questions of increasing complexity about potato irrigation and sensor data. Claude Code answered seventeen correctly; Oxrow answered all twenty. This is not a claim of superior underlying model performance, only of stronger tool design. Oxrow’s context includes a carefully designed agent prompt, tool harness, and semantic layer that restrict what the AI sees and when. Claude Code had access to the data, the code, and the kitchen sink. In its own explanation of the three misses, it said it had “exploded” the scope of its own unlimited tooling into parts of the database the task did not require.

Making a start with AI

The debate about AI in agriculture should not be between two bad conclusions: that the technology is mostly useless, or that it will rapidly remake the industry. Both takes miss the opportunity already in front of growers and processors. AI is already creating material value by enhancing defined operational work: preparing a crew plan, assembling a compliance report, reconciling data across systems, flagging overtime risk, or helping a packer decide what to run.

That work is difficult for a generic LLM or a point-software feature to handle. It requires a current view of the business, clear definitions for the data involved, access to all relevant systems, and constraints around what the AI can recommend or do. It also requires an output that fits the way the operator actually works, rather than another answer to interpret, check, and hand on.

Schedule time with us to identify where Oxrow could save you time, reduce cost, or improve a decision in your business.