The model matters less than the layers around it

By Dzmitry Yablonski, CTO, GeoPard Agriculture

Someone asked me last week which model our AI agronomist runs on. It is the most common technical question we get, and it is usually the wrong one to lead with.

Here is the honest answer, and then the more useful one.

The honest answer: several

We route each task to the model best suited for it. In practice that means separate paths for:

• Geospatial reasoning. Reading zone statistics, comparing layers, explaining why one part of a field behaves differently from another.
• Rate math. Removal coefficients, critical thresholds, build-up conventions, unit conversions.
• Conversation. Understanding what an agronomist actually meant by a half-sentence request.
• Task classification. Deciding which workflow a request belongs to before anything else happens.
• Guardrails. Checking outputs before they become artifacts.

No single model is best at all five. The ones that reason well over messy spatial context are not always the ones that hold arithmetic discipline. The ones that converse naturally are not always the ones that classify reliably.

We do not publish the routing table, and not to be coy. It changes. Model releases land every few months and each one shifts the balance on one or two of those paths. Freezing the answer in a blog post would make it wrong by autumn.

The more useful answer: the layers

If you swapped our models for a different frontier set tomorrow, the product would still work, and it would still be recognizably ours. That is the design goal, and it is worth explaining why.

An agronomic recommendation is not a text answer. It is a number that ends up in a machine terminal and gets applied to a field. The distance between those two things is where the engineering actually lives.

Take a concrete class of failure. A model can produce a perfectly reasoned phosphorus prescription in pounds of P₂O₅ per acre. Correct removal coefficient, correct threshold, correct build-up logic. Then the rate gets attached to a product that is 4 percent P₂O₅, and the spreader receives it as a product rate. The plan was right. The application is off by more than an order of magnitude.

No amount of model quality prevents that. A conversion layer does.

The same applies to unit systems, to regulatory rate ceilings, to soil-test values above which the agronomically correct rate is zero, to the difference between what a lab reports and what an equation expects. These are not reasoning problems. They are systems problems, and they are the ones that decide whether a recommendation is safe to act on.

So the layers around the model do the work that matters.

Grounding. The assistant reads the customer’s own data. Their soil tests, their cleaned harvests, their topography, their as-applied history. Not a general picture of agronomy, theirs.

Explicit parameters. Every coefficient, threshold, and convention used to build a rate is surfaced and editable before generation. If the agronomist disagrees with an assumption, they change it. A number the user cannot inspect is a number they cannot own.

Deterministic math. Rate calculation runs in code, not in prose. The model decides what to compute and why. It does not do the arithmetic.

Validation before generation. Plans are dry-run checked against agronomic rules for the region, plus whatever rules the customer has added to their own knowledge base, before a single map exists.

Human approval. Nothing reaches a machine until a person signs off. This is not a UX concession. It is the last and most important layer.

What we evaluate

Because of all of the above, evaluating the model in isolation tells us very little.

A high score on agronomy multiple choice tells you a model has read the textbooks. It does not tell you whether the system will correctly convert a nutrient rate to a product rate, or refuse to recommend phosphorus on a field that already tests high, or notice that a soil report came back in a different extraction method than the equation assumes.

So we evaluate the system end to end. Does it retrieve the right layers from the customer’s account. Does it use defensible coefficients. Does it show its reasoning. Does it catch its own errors before they leave the building. That is harder to reduce to a single number, which is precisely why we think it is the right thing to measure.

Bring your own model

Through MCP, you can point your own model at your GeoPard data and ask it about your fields directly. Some of our more technical users already do, and we think that is a good thing. The AI Assistant documentation covers how it works.

Worth saying plainly though: when you do that, you inherit the layers. The grounding, the parameter transparency, the unit discipline, the validation, the approval step. Those are not in the model. They are the part someone has to build.

Why this is a bet, not a hedge

Model capability is commoditizing fast. Every few months the frontier moves and everyone gets the new floor for free. Betting on one specific model is betting on a temporary advantage.

The layers compound. They accumulate agronomic rules, regional conventions, customer knowledge, and every failure mode we have found and closed. That gets better with use, and it does not reset when a new model ships.

Which is a long way of saying: ask what a system does with a wrong answer. That tells you more than knowing which model produced it.

Here is the assistant doing exactly that, from question to exported prescription, in two minutes:

For the interactive version, with every reasoning step visible, see the GeoPard AI Assistant page.