Mazorca: An Offline AI Agronomist for Cacao Plots, Powered by Gemma 4

When AI Steps Into Mexico's Cacao Groves

In Cárdenas, Tabasco, Mexico, a cacao-growing developer built an offline agronomy assistant called Mazorca using Gemma 4. The project started from a humble place: his family's 3-hectare cacao plot faced a real and pressing problem — moniliasis (frosty pod rot). This disease, caused by Moniliophthora roreri, can take a substantial share of the harvest if infected pods aren't detected and removed early in the infection cycle.

Yet most local smallholders don't have a technician visiting weekly, and there's usually no cell signal under the canopy. Mazorca (Spanish for "cacao pod") was designed for exactly this scenario: a phone, a laptop, and pest/disease identification plus a weekly management plan — all under the trees, with no network connection.

How It Works

Photo-Based Scouting and Diagnostic Cards

Users walk through the plot taking photos block by block. Each photo is analyzed by a locally running Gemma 4 model, which generates a diagnostic card containing:

• Specific findings observed (frosty pod rot, black pod disease, witches' broom, overripe pods, excessive shade, pruning needs, weeds, waterlogging)
• A confidence level for each finding
• Counts of healthy vs. affected pods
• Up to four actionable practical recommendations

The key design detail: each card begins with "Lo que la IA ve" (What the AI sees). This lets the farmer immediately judge whether the model is looking at the same thing they are — if the model's observations don't match reality, the user can spot it right away.

7-Day Plot Reports and Weekly Plans

Beyond single-photo diagnostics, Mazorca also generates 7-day reports for each plot, including photos, a problem list, the proportion of affected pods, and the trend compared to last week (up, down, or flat). This part doesn't rely on model computation — it's deterministic, so the data itself is reliable and reproducible.

The weekly action plan is then generated by the local model based on this report and can be read aloud in Spanish via ElevenLabs — a feature that genuinely matters for farmers who'd rather listen than read under the blazing sun.

The system also includes a cut-test (estimating the proportion of well-fermented, purple, hard, or moldy beans), CSV export (to bring to the cooperative or technician), and more.

Why Two-Step Diagnosis

Here's a technical design worth noting. If you directly tell a vision model "this is a cacao plot, look for diseased pods," the model gets "primed" and will find signs of illness even on healthy plants.

Mazorca's solution is a two-step call:

1. Neutral observation: The prompt says nothing about cacao, disease, or agriculture — it only describes the scene, counts people, and reports whether fruit is visible with an estimated count.
2. Diagnosis: This step receives the observations from step one and cannot contradict them.

Afterward, the server enforces hard rules rather than trusting the model: if no fruit was visible in the observations, all pod-related findings and counts are removed; if counts far exceed the observation estimate, they're scaled down proportionally.

This design also touches on the problem of prompt bias in vision-language models (VLMs). When the prompt explicitly names a target category, the model tends to "find" objects matching the description in the image — even when they don't exist. This kind of over-association is usually harmless in general image captioning tasks, but in agricultural diagnostics it directly leads to false positives and incorrect treatment. The essence of the neutral observation step is to have the model perform open-ended description first, separating "what is seen" from "what is judged" in the reasoning chain, giving subsequent diagnosis a factual baseline to compare against. The server-side hard rules then serve as a deterministic validation layer, using logical constraints to compensate for the unreliability of probabilistic model output — a key engineering technique for turning AI from a "mysterious black box" into an "auditable tool."

Engineering Details

The project is implemented with zero-dependency Node, using only node:* modules — no npm install needed — and can be copied to an old laptop via USB stick. The frontend is an offline PWA in Mexican Spanish, using high-contrast colors for readability in direct sunlight.

Photos are re-encoded via <canvas> before upload, stripping EXIF/GPS information to ensure farm locations never leave the phone. All model text is inserted via textContent to avoid injection risks.

To handle the issue where different Ollama builds may return 501 or silently ignore the format parameter, the project also places the JSON schema in the prompt itself, can extract JSON even when wrapped in markdown, and has one retry attempt.

Frosty pod rot (moniliasis) is one of the most destructive fungal diseases in cacao-growing regions of Central and South America, caused by Moniliophthora roreri. It primarily infects cacao pods, initially showing as inconspicuous brown spots that rapidly expand into a white spore layer, ultimately causing pod rot. The key difficulty: early infection is nearly asymptomatic, and once the spore layer appears, the disease has already spread within the plot. Therefore, timely scouting, early identification, and removal of diseased pods are the core control measures. For smallholders using the offline assistant described in this article, this weekly systematic scouting combined with local AI identification fills precisely the structural gap left by the absence of professional plant health personnel.

The Three-Tier Payment Logic: Farmers Use It Free — Who Pays for the Data

Mazorca's business model deserves a closer look. The developer readily admits: individual farmers won't pay upfront, because many are paid by the kilo with razor-thin margins. The payers are those already spending money on field visits:

• Cacao cooperatives and collection centers: They need consistent monitoring across dozens of members and prefer weekly CSV reports per plot over WhatsApp photos. An annual cooperative license plus a cheap laptop or mini PC as a "field box" costs less than hiring another technician.
• Chocolate makers with direct sourcing and sustainability or traceability programs: They need evidence of good agricultural practices from their sourcing regions.
• Extension technicians and agronomy consultants: One technician can cover more farms when producers send structured weekly reports instead of random photos.

Farmers use it for free; those who need data at scale pay for deployment, support, and Kestra reporting.

Open Source Here Isn't a Philosophy — It's a Prerequisite

For the cacao plot scenario, open source and innovation aren't a philosophical discussion — they're conditions for whether the product can exist at all:

No signal in the field. Closed vision APIs require connectivity at the moment of taking a photo, while open-weight models can run on a laptop next to a phone hotspot under the trees.

Farm data stays on the farm. For smallholders selling beans to intermediaries, plot photos, yields, and disease levels are sensitive. Local inference means no data leaves the laptop except the optional audio plan text.

Zero marginal cost. Each farm walk is 30 to 60 photos per week. Per-image pricing would break the business model for cooperatives serving hundreds of members; local inference costs only the electricity for a laptop.

Replaceable and auditable. When a better model appears, or a cooperative fine-tunes one on its own disease photos, switching is just an environment variable. Prompts, normalization, and safety rules are all public — technicians can read exactly what the tool was told and what it's forbidden to say.

It's worth distinguishing that open-weight models are not the same as open-source models. Open-weight only means the model parameters can be downloaded and run locally, while training data, code, and training pipelines may not be public. For the cacao plot scenario, what actually matters is the offline inference capability that open weights provide: identification can be done locally without a network, data never leaves the device, and the model can be freely swapped as hardware improves. As for open-sourcing the code and prompts, that additionally gives cooperatives or technicians the ability to audit and fine-tune — making the entire system truly controllable and reproducible in field deployment.

The Developer's Own Test Results

The developer is the first user. He tested it with photos from his own 3-hectare cacao plot and gave honest feedback:

• Scene description performed well (understory vegetation, shade, harvest piles, bean buckets, young pods on trunks), and "what the AI sees" makes errors easy to spot.
• Counts are approximate estimates, not precise inventories.
• One real mistake: It misread his pile of opened cacao shells as "overripe pods on the ground." This is a reasonable visual error — and precisely why every finding comes with a confidence level and a prompt for the user to confirm with a technician.
• Frosty pod rot not yet validated: It was the post-harvest period, with no photos of active frosty pod rot. Detecting the disease on his own pods when new pods emerge is the next test.
• One correction: Early prompts implied that cacao shell piles cause frosty pod rot. This is incorrect — shells from healthy pods don't cause disease, but if diseased pods are mixed in, they can spread spores. The developer fixed the prompt, which now only recommends spreading or composting shell piles away from trees.

Mazorca positions itself explicitly as an observation aid, not a diagnostic tool, and doesn't replace a technician or laboratory. But it has already given the developer something he didn't have before: a structured weekly view of his plot.

From the real-world feedback, a more general pattern emerges: current vision-language models are already quite usable for "descriptive tasks" but remain unreliable for "counting and measurement" tasks. Accurate scene descriptions of understory vegetation, harvest piles, and bean buckets show the model has good perception of overall composition and object categories; but misreading an open pile of cacao shells as "overripe pods on the ground" exposes the model's limitations in fine-grained discrimination and contextual reasoning. Such errors are costly in agricultural settings — if a farmer misjudges the disease situation and takes the wrong action, it can cause unnecessary losses. This is why the developer positions Mazorca as an "observation aid," emphasizing confidence levels and human review — a pragmatic choice aligned with the current state of the technology.

How to Run It

ollama pull gemma4:e4b-it-qat
git clone https://github.com/gartox/mazorca && cd mazorca
npm start

Open http://127.0.0.1:3000 on the laptop, or open the laptop's LAN IP on a phone connected to the same hotspot. The model can be swapped via the MAZORCA_MODEL environment variable; Ollama's default timeout is 180 seconds. The Kestra workflow is optional and disabled by default.