AgroAsistente

A generic LLM tells a Venezuelan farmer what's true on average. It can't know that this plot is sandy clay, two weeks into a dry spell, with NDVI trending down. AgroAsistente grounds every answer in the data of the specific parcel the farmer drew on the map. Weather, soil, land-cover and satellite vegetation feed the prompt before the model ever sees the question.

It's built for the constraints of the market it serves: flaky rural connectivity and a region where API cost and reliability are first-order problems, not afterthoughts. Offline-first PWA, durable rate limiting, and a fallback chain that survives a Google outage. It's a functional MVP approaching production, not a hardened release.

Steps 01–03 run once when a parcel is registered: auth, draw the plot, then lazily fetch and cache its weather, soil, land-cover and NDVI. Steps 04–06 fire on each chat turn, assembling the cached context plus RAG and streaming a grounded answer from Gemini.

• /01

  Per-parcel geo-grounding

  The farmer draws the plot on a satellite map. Open-Meteo weather, SoilGrids soil, MapBiomas land-cover and Sentinel-2 NDVI for that exact polygon get assembled into the prompt, so the answer reflects this farm, not the regional average.

• /02

  RAG over a real agronomic corpus

  Retrieval runs against an INIA/FONAIAP corpus embedded in pgvector. Recommendations cite local agronomy, not whatever an ungrounded LLM happens to recall.

• /03

  Dual-role, one app

  The same surface serves the productor (grow advice) and the vendedor (supply and sales context). Role shapes the prompt and the retrieval, not the codebase.

• /04

  Voice and photo, in the field

  Voice input in Venezuelan Spanish and photo plant recognition mean a farmer with dirt on their hands can ask without typing. Multimodal input over a single chat turn.

• Q/01

  Why cache per-parcel enrichment in the DB row instead of fetching it per request?

  +

  Weather, soil, land-cover and NDVI come from rate-limited external APIs. Fetching all four on every chat turn would add seconds of latency and hammer quotas that aren't ours to burn. The data is fetched lazily once, cached on the parcel row, and reused. Chat stays fast and the external APIs stay happy.

• Q/02

  Why a 3-tier LLM fallback chain?

  +

  Gemini primary, a Gemini fallback model, then an OpenAI-compatible external (default Mistral free tier). The market is Venezuela: API reliability and cost are first-order constraints, not edge cases. When Google returns a 429 or a 5xx, the chain steps down with zero downtime instead of showing the farmer an error.

• Q/03

  Why one Supabase/pgvector surface instead of a separate vector DB?

  +

  Auth, tenant data and RAG embeddings all live in one Postgres. One place to secure, one auth model. A dedicated vector DB would add a second isolation boundary and a second set of credentials to keep in sync, for a corpus this size that doesn't need it.

• Q/04

  Why offline-first with Supabase-backed rate limiting, not in-memory?

  +

  Rural connectivity drops mid-conversation, so the PWA has to work offline and reconcile when the signal returns. In-memory rate limiting also breaks the moment Vercel spins up a second instance. Durable limits live in Supabase so they hold across instances and restarts.

• /01

  Refresh the per-parcel enrichment on a schedule, not just lazily. NDVI and weather go stale; a cron that re-fetches plots whose cache is older than its signal's natural cadence would keep answers current without making chat pay the fetch cost.

• /02

  Push parcel geometry and the cached context into the offline store more aggressively. Right now offline mode leans on the last chat state; pre-caching the full parcel context would let a farmer get grounded answers even on the first cold start without signal.