The most important line in the WhatsApp bot I built last weekend is “consult your local agricultural extension officer.”
I built Loam AI to prove a specific architecture pattern: an AI assistant for smallholder farmers in Kenya that grounds every answer in curated sources, cites those sources on every reply, and escalates to a human whenever it is not sure. The pattern matters because the alternative, a thin wrapper over a language model that will happily invent a pesticide dose, is not merely unhelpful. When a wrong answer costs someone their season, it is malpractice.
This is a note on how it is built and why it is built the way it is.
The failure mode of most farming chatbots
There is a specific failure mode I keep seeing in agricultural AI products: the model is asked a question it does not know the answer to, and it invents a plausible-sounding answer. Fungicide brand X at Y millilitres per litre. Fertilizer at Z kilograms per acre. This is the failure mode language models are optimized for. Sound coherent, keep the conversation going, satisfy the user in the immediate turn.
In consumer productivity, that failure mode is annoying. In agriculture, it is dangerous. A farmer who over-applies fertilizer based on a chatbot’s hallucination does not get a chance to iterate. Their season is the eval loop.
The right response to a question you do not know is not to produce an answer that sounds correct. It is to say “I do not know” and route the question to someone who does. This is obvious in medicine and law. It is inexplicably rare in agricultural AI.
Four architectural commitments
Loam AI is built around four commitments, each of which turned out to be simpler to implement than to hold to.
Retrieval before generation. Every answer starts with a vector search over a curated knowledge base of Kenyan agronomy guidance, grounded in KALRO, CABI Plantwise, and FAO sources. The language model does not answer from its training data. It answers from the retrieved context, or it does not answer at all. The system prompt makes this a rule with no exceptions.
Citations on every reply. Each answer ends with the source it drew from. “Chanzo: KALRO Maize Production Guidelines.” “Source: CABI Plantwise potato late blight factsheet.” A farmer who wants to verify the advice can. A field officer reviewing the bot’s logs can trace every claim back to a document. Provenance is not a nice-to-have. It is the difference between an advisor and a slot machine.
Structured escalation. Every response includes a confidence score between zero and one, produced by the model against its own answer. Below a threshold, the reply is routed to a human agronomist queue rather than shown to the farmer as-is. Out-of-scope questions escalate by default. The model can also flag an escalation for reasons of its own. The queue is where the system’s blind spots become someone’s actual job.
Continuous evaluation. Twenty-five golden test cases run against the pipeline on demand, graded by a smaller language model acting as an LLM-as-judge. Grades are persisted with the generation model version and the prompt version. Any edit to the system prompt bumps a version string. Any regression is a visible line on a dashboard. This is the part most demos skip. It is the part that separates “we built a chatbot” from “we can tell you when the chatbot is degrading.”
The build
Loam AI is a Next.js 15 application on Vercel with a Supabase Postgres database using pgvector for the vector store. Twilio’s WhatsApp Business API handles the messaging layer. The generation model is Claude Sonnet 4.6. Embeddings come from Voyage AI’s voyage-3 model, with OpenAI as a switchable fallback. The eval judge is Claude Haiku 4.5.
The pipeline for a single message:
Twilio receives the WhatsApp message and posts to the webhook.
The webhook verifies the Twilio signature and rejects unsigned requests.
The message is classified as English or Swahili by a heuristic detector.
The question is embedded and used to search the knowledge base for the five most relevant entries.
A versioned system prompt is constructed with those entries as retrieved context.
Claude generates a structured JSON response with an answer, a confidence score, citations, and an escalation flag.
The response is validated against a Zod schema. Malformed output falls back gracefully.
If confidence is below threshold, the reply is marked for escalation.
The conversation is logged with the farmer’s phone number hashed against a server-side salt.
A TwiML message is returned to Twilio and delivered to the farmer.
None of this is novel individually. The point is not the individual pieces. It is the discipline of putting them together in a way where every step is inspectable and the whole system can be evaluated as a unit.
Bilingual by design
The knowledge base is bilingual: every entry has an English question, a Swahili question, an English answer, and a Swahili answer, with a shared source citation. Language detection happens at ingestion, which routes the farmer to the correct language pair. Retrieval works across both because the embedding model is multilingual and topics cluster semantically regardless of surface language.
This is worth calling out because it is a decision most global agricultural AI products get wrong. English-first with Swahili as a translation layer produces stilted responses that read like a machine talking to a farmer. A Swahili speaker reads the difference immediately. Building bilingually from the knowledge base up is more work in the short term and disappears in the output, which is exactly what a well-considered decision looks like.
What was left out
Honesty about limitations is part of the design.
The knowledge base is thirty entries. A production deployment needs five hundred or more, reviewed by qualified agronomists. Thirty entries prove the pattern; they do not cover the actual scope of a farming season.
The language detection is heuristic token matching. A production system should use a proper detector.
There is no SMS or USSD fallback. Farmers without smartphones or WhatsApp are excluded from this demo. A real deployment would need multi-channel from day one.
There is no integration with a farmer system of record, no memory across conversations, and no tool use for weather or market prices. The retrieval is single-shot: one question, one search, one answer.
The evaluation set is twenty-five cases graded by a single judge. A production system needs two hundred or more cases with human review and inter-rater reliability checks.
Every one of these is a legitimate criticism. None of them undermine the core claim, which is that this is the shape a farmer-facing AI system should have.
Why this matters beyond farming
The pattern generalizes. Anywhere an AI system is asked questions where wrong answers cost real money or real health, the same four commitments apply: ground every answer, cite every source, escalate every uncertainty, evaluate continuously. Medical triage, legal information, veterinary guidance, insurance underwriting, financial advice. The failure mode of a hallucinating model is the same in all of them. The architectural response is the same in all of them.
Loam AI is a demonstration of that pattern in a specific domain. What matters is that the pattern is buildable in a weekend by one person, deployable on infrastructure that costs less than a hundred dollars a month at demo scale, and observable enough that a real operator can tell when it is degrading. The technology is not the hard part. The hard part is deciding you will build it this way even when the shortcut of “just wrap a chatbot around a language model” is faster.
I built Loam AI as a portfolio artifact and as an argument. The argument is that farmer-facing AI has to earn its place in a farmer’s decision-making, and the way to earn it is by being right, being verifiable, and knowing when to defer. Everything else is a demo.
