Why Deploying AI in Horticulture Is Hard

Everyone is launching AI right now. The demos look good. The marketing sounds confident. And growers, who've watched a lot of technology promises fall flat, are right to be skeptical. Because building genuinely useful AI for a greenhouse is one of the harder technical and domain challenges I've encountered, and I say that after years of working on it full-time with a team that's thought about very little else.

This paper is my attempt to explain why. Not to discourage anyone from using AI, we believe the upside is enormous, but to help growers and operators understand what it actually takes to do it well. Because the gap between a system that's been properly built for horticulture and one that hasn't is the difference between a tool that makes you better and one that quietly erodes your confidence in your own judgment.

Context is everything. And most systems don't have it.

Ask a general-purpose AI what to do when your humidity is rising at sunrise and you'll get a reasonable textbook answer. But that answer won't know that your Block 3 vents are running behind, that your boiler was serviced last week, that you're in week six of a tomato crop approaching peak generative load, or that your head grower has spent three years dialling in a specific approach to early morning dehumidification that works for your particular setup.

Context is what converts generic knowledge into advice you can actually act on. Without it, you're talking to a very well-read stranger who's never set foot in your greenhouse. And a well-read stranger, it turns out, can give you a lot of confidently wrong answers.

Building a system with real context means integrating live sensor data, crop history, hardware constraints, grower protocols, and operational notes, and having a reasoning engine that knows how to use all of it together in real time. That's not only a data pipeline problem. It's a genuinely difficult knowledge engineering problem, and it's one most AI products launched at horticulture haven't seriously attempted to solve.

Confident wrong answers are the worst kind

One of the well-documented failure modes of large AI systems is hallucination, stating things with confidence that are simply untrue. In most applications, this is annoying. In a greenhouse, it can be expensive.

If a system recommends increasing CO₂ enrichment while your screens are closed and temperatures are already climbing, a grower who trusts that recommendation creates real crop stress. The system didn't know about the screen position, the solar load, or the interaction between the two. It filled the gap in its knowledge with a plausible-sounding answer. That's not a minor edge case, that's a foreseeable failure on a normal operating day.

This is why guardrails aren't optional. A properly built AI for horticulture needs hard constraints on what it can and can't recommend, calibrated against real greenhouse operating conditions. It needs to know what it doesn't know, communicate uncertainty clearly, and refuse to make recommendations outside the bounds of what it can actually reason about. Building those constraints requires a deep collaboration between AI engineers and experienced growers, and it takes a long time to get right. When you see an AI product that was apparently built and launched in a few months, the question worth asking is: where are the guardrails?

The variability problem is bigger than it looks

Here's something I didn't fully appreciate until we were deep into this: greenhouses are extraordinarily diverse. The variation across facilities, even within the same crop and the same country, is vast enough to make any one-size-fits-all approach fundamentally unreliable.

Consider the range: a facility running a combined energy and shading screen on a single rail is operating under completely different constraints than one with separate systems. Boiler capacity sets hard limits on what's physically possible overnight. The difference between a well-instrumented operation with slab sensors and dendrometers versus one relying on a single climate box per bay isn't just a data quality issue, it changes what an AI can and can't reason about. A mountain that blocks morning sun, a microclimate that traps humidity, an unusual wind pattern that affects how you vent, these factors are invisible to any system that hasn't been told about them specifically.

And that's before you factor in the cultivation goals, which change everything. A grower optimizing for yield runs a fundamentally different program than one chasing quality or market timing. An AI calibrated for one will give actively misleading advice for the other. Add shifting energy prices, which constantly move the cost-benefit line on heating decisions, and the experience level of the grower actually running the system day to day, and you start to understand why building for 'the average greenhouse' isn't really building for any greenhouse at all.

I mention all this because when you see a product marketed as a universal AI layer for commercial horticulture, the natural question is: which greenhouse is it actually calibrated for? And if the answer is vague, that's a signal.

Surface observations are not intelligence

A useful insight isn't just an observation. 'Your EC is elevated' or 'your temperature deviated from setpoint last night' are notifications. They move the cognitive load from the dashboard to the grower, but they don't reduce it. Real value comes from tracing the chain: why did the EC rise? Was it a dry-back that ran too long, a fertigation issue, or sensor drift? And given the answer, what should you do, and what do you monitor over the next 24 hours to know if it worked?

A shallow alert is often worse than no alert, because it creates urgency without direction. A grower who increases irrigation frequency in response to a high EC reading, when the actual problem was an aggressive dry-back, has just made things worse based on a tool that was supposed to help them. The depth requirement extends further: a crop is a system, and changes in one variable ripple through others. Temperature affects transpiration. Transpiration affects water uptake. Water uptake affects root zone EC. An AI that reasons about these in isolation rather than as a connected system will consistently miss the interactions that actually matter.

You need to see the reasoning, not just the recommendation

Even the most experienced growers in the world disagree with each other. Walk a crop with two veteran tomato growers and they'll read the same plants differently, make different steering calls, and often produce excellent results through entirely different paths. Horticulture is genuinely still part art. The scientific literature is advancing, but it's still catching up with the best of what experienced practitioners know from years of observation.

This creates a real problem for AI systems. If you train on general horticultural knowledge, you capture the average of a lot of disagreements and conflicting approaches. That average will sometimes conflict with your grower's protocols in ways that are hard to explain and harder to trust. And a system that just tells you what to do, without showing why, is asking you to replace your grower's judgment with a black box. The best growers I know won't accept that, and they shouldn't.

The explanation isn't a nice-to-have. It's the mechanism that lets a grower evaluate whether the advice is actually sound. When a system says 'raise your minimum pipe by 3 degrees tonight, because the incoming weather pattern and the stress signals your outer bay plants showed this morning point to a frost risk that's higher than your current settings account for, here's the logic', the grower can agree, push back, or override. That's a conversation. That's trust being built over time.

This is also why the knowledge behind a system matters as much as the AI itself. A system is only as good as the expertise encoded into it and the reasoning framework built around that knowledge. Getting that right requires sustained collaboration with exceptional growers, not just a data science team. It's slow and hard and not the kind of thing you can shortcut.

What we've built, and why it took this long

At Sera, we've spent years on these problems. We’ve taken that time because they're genuinely hard and because we refused to launch something until it actually worked. That means deep context integration across climate computers, sensors, scouting logs, and grower notes. It means guardrails built with real horticulturalists from different parts of the world who pushed back every time the system gave a reasonable-sounding wrong answer. It means reasoning that goes from observation to root cause to downstream consequence, not just symptom flagging. And it means a knowledge base that's calibrated to the specific protocols, quirks, and goals of the operation it's serving, not averaged across a generic model of what a greenhouse looks like.

I'm proud of what we've built. I think it's genuinely different from anything else in this space, and I think the growers who've worked with it closely would say the same. We're not done, there's a lot more to do, but we've cleared the bar that I think matters most: it makes experienced growers better, rather than making them explain why the AI is wrong.

If you're evaluating AI for your operation, I'd encourage you to ask hard questions of anyone you're talking to. What context does the system actually have access to? How does it handle missing or noisy data? What stops it from giving a confident wrong answer? Can you see its reasoning? Has it been calibrated to your type of operation or to a generic one?

The answers will tell you a lot. And if you want to see what it looks like when those questions have good answers, we'd love to show you.