Applied AI + Agriculture + Decision Systems
Farm Intelligence
AI-enabled tools built around the real decisions of a working family farm — records, profitability, weather, marketing, and cattle markets.
- My role
- Designer and builder
Tools
- AI agents
- Scheduled jobs
- Live database
- Mobile access
Systems in this group
- 01
Cattle records and management
Animal history, herd records, and operational decision support, replacing a decade of notebooks and inconsistent annual spreadsheets.
- 02
Farm profitability
Enterprise-level costs, margins, cash flow, and scenario outcomes, so the question “does this enterprise actually make money” has an answer.
- 03
Cash bid and commodity marketing intelligence
Automated collection of bids across buyers, with basis, contract month, location, and timing handled correctly, so the farm compares real alternatives rather than numbers that merely look alike.
- 04
Weather model intelligence
Forecast interpretation aimed at operational decisions, with an explicit read on confidence rather than a single number presented as certainty.
- 05
Cattle market agents
Agents that monitor, organize, and synthesize market information and regional coverage into a briefing, with claims attributed to their sources.
The model proposes; deterministic logic and validation decide. Anything that fails a constraint returns upstream to be re-planned instead of reaching the user.
Context
My family farms in central Missouri. Grain and cattle. The decisions that determine whether a year works are not complicated to state — when to sell, what an enterprise actually costs, which animals to keep, whether to act on a forecast — but the information needed to make them is scattered across a dozen websites, a stack of notebooks, and several years of spreadsheets.
This is the environment most agricultural software is built about rather than for.
The problem
Farm decisions are made against data that is messy in specific, structural ways.
Prices update five times a day at one buyer and go eleven days stale at another. Basis is quoted against different contract months by different elevators, so two numbers that look comparable are not. Cash prices and futures both move minute by minute, so a comparison assembled from two page loads taken twenty minutes apart is simply wrong. Government report dates drift from any rule you might compute them with. Livestock records live in paper notebooks and annual spreadsheets with inconsistent formats going back more than a decade.
None of this is exotic. All of it silently produces confident, wrong answers.
Why it mattered
These are not analytical exercises. A marketing decision on a grain contract is a five-figure decision for a family. A weather call determines whether a crop gets sprayed in a usable window. Cattle records determine which animals stay and which go.
The cost of a plausible-looking wrong number is real money, and the people absorbing it are family.
Approach
I built for the decisions rather than for the data.
Fix the weakest number on the board first. The farm's main delivery point had the stalest data of any buyer, because it was the only one entered by hand — eleven days old while everyone else updated five times a day. The buyer they actually haul to was the buyer they had the worst information about.
Read pages the way a browser does. Where a site renders its numbers through its own scripts, the parser loads the page, lets those scripts run, and reads the result. It never reimplements anyone's logic. It is also the durable route: a decoder breaks silently into plausible-looking numbers when a page changes, while rendering keeps working.
Be a guest on other people's systems. A handful of page loads per weekday, one retry and only on a load failure, an ordinary browser user agent, no parallel requests. Less traffic than refreshing the page on a phone.
Make every comparison apples-to-apples, or refuse to make it. Delivery location is matched exactly and a blank location is a hard failure rather than a wildcard — the neighboring town's beans were fifteen cents off on a day that would have been easy to get wrong. A buyer's basis is stored against the contract month they quote it against, while the farm's own basis log stays against the front month, so the two can never be confused. Cash and futures are taken from the same page load.
Prefer published truth to computed truth. Report dates are read from the official release calendar. The arithmetic version is a labeled fallback, because measured against the real schedule it had half the dates wrong.
Label estimates as estimates, everywhere, on screen.
What I built / led
A working decision platform, in daily use by the farm's owners, covering cattle records, profitability, marketing intelligence, weather interpretation, and market agents.
Built on a modern web stack with scheduled jobs, a live database, and mobile access, because the people using it are in a truck or a barn, not at a desk.
Result
In production use by the farm's owners. The system replaced hand-entry for the buyer that matters most, consolidated more than a decade of livestock records, and put marketing, weather, and profitability information in one current place.
What I learned
Real-world AI work is mostly data-integrity work. The reasoning layer was the straightforward part. Everything difficult was making sure two numbers were genuinely comparable before anything compared them.
Domain knowledge is what makes the system correct. Knowing that basis can be quoted against a deferred month is not a software insight. Without it the application produces confident, plausible, wrong output — and no amount of model capability recovers from that.
Honest uncertainty beats false precision. A forecast with a confidence rating attached is more useful than a forecast presented as fact, and people trust a system more once it has told them when not to trust it.
Screens
