Building AgriSentinel: a Gemini agent fleet for the farms AI can't see
AgriSentinel: a fleet of specialized Gemini agents that turn raw satellite signal into action for smallholder farmers, crop insurers, and carbon-credit buyers — built for the All Things Agentic Hackathon, "Fortified Enterprise Fleet" category.
"Unlikely hero": the smallholder farmer, the crop insurer's field team, and the carbon-market auditor — none of them are standard corporate IT roles, and none of them can read raw SAR backscatter or PINN output. AgriSentinel's job is to make Gemini agents do that translation for them, autonomously.
Inspiration
Most agricultural AI is trained on massive, single-crop industrial fields. It falls apart the moment you point it at the farms that actually feed most of the world: a half-acre plot in Sub-Saharan Africa growing maize, beans, and cassava mixed together; a field in Southeast Asia blinded by monsoon clouds for weeks during its highest-risk growing period; a smallholder who switched to no-till farming with no affordable way to prove it for a carbon credit. These aren't edge cases — they're the majority case, and they're underserved because the AI genuinely can't see them clearly. We wanted to build something that treats "the farmer no one built for" as the actual target user, not an afterthought.
What it does
AgriSentinel is a fleet of five specialized Gemini agents, coordinated by a Gemini 3.5 orchestrator, that turns raw satellite and sensor signal into action for three very different stakeholders on the same plot of land:
- Plot Disaggregation Agent — untangles intercropped micro-plots using constrained spectral unmixing, so "what's actually growing here" becomes answerable even on a mixed sub-acre field.
- Cloud Piercing Agent — reconstructs an optical-imagery estimate from cloud-penetrating SAR radar data, so monsoon-season cloud cover no longer means weeks of blindness during the highest-risk growth window.
- Stress Sentinel Agent — watches evapotranspiration and canopy temperature for sustained anomalies, flagging drought or disease stress days before it's visible to the eye or to standard NDVI.
- Carbon Verification Agent — estimates soil organic carbon change from remote-sensed proxies using a physics-informed model, giving carbon-credit buyers a scalable alternative to expensive physical soil coring.
- Farmer SMS Agent (Gemma) — the last-mile translator. It takes the combined output of the other four agents and compresses it into a single SMS-length, plain-language message a farmer can read on a basic phone with no data connection.
The orchestrator doesn't just chain these agents — it decides, per plot per cycle, which of them are actually relevant given the live situation (is this plot intercropped? is it cloudy today? is it enrolled in a carbon program?), runs the relevant ones concurrently, and persists plot state across a growing season via a Memory Bank.
How we built it
The orchestrator and all five agents run as a single FastAPI service deployed on Cloud Run, with Vertex AI as the Gemini/Gemma backend (authenticated via the Cloud Run service account's Application Default Credentials — no exposed API keys in production). An Agent Registry catalogs each agent with its version and owning team, so, for example, an insurer could reuse the Stress Sentinel Agent without touching how it was built. Pub/Sub triggers a cycle asynchronously when a new satellite pass lands, in addition to a direct HTTP endpoint for synchronous testing. Every agent decision is logged as structured JSON for audit-trail observability.
Each agent pairs a genuine, runnable algorithm with a Gemini reasoning layer on top: constrained non-negative least-squares for spectral unmixing, a Pix2Pix-style U-Net for SAR-to-optical translation, a rolling z-score anomaly detector for pre-visual stress, and a Q10-style physics model for soil carbon turnover. Gemini's job in each agent isn't to do the math — it's to interpret the math's output, assess confidence, and decide what to do next, which is the actual "agentic" layer the fleet is built around.
Challenges we ran into
Model availability across regions. gemini-3.5-flash wasn't served on Vertex AI's us-central1 regional endpoint for our project — it required routing through the global endpoint instead, which we only discovered by reading the actual 404 response closely.
Free-tier quota walls. Our first deployment used a plain Gemini API key, which hit the AI Studio Free Tier's ~20-requests/day cap almost immediately once the orchestrator started making 4-5 calls per cycle. We migrated the whole service to Vertex AI, billed against our GCP project instead of a free-tier bucket, which also let us drop the API key secret entirely in favor of the Cloud Run service account. Latency. Sequential Gemini calls made a full cycle take ~47 seconds. Since the four core sub-agents are independent (different sensor modalities), we parallelized them with a thread pool, cutting cycle time to ~14-17 seconds.
A crashing Pub/Sub handler. A malformed test message sent through the console crashed our push-subscription endpoint and triggered an infinite Pub/Sub retry loop (a non-2xx response means "redeliver forever"). We rewrote the handler to always acknowledge (200) even on unparseable payloads, logging the failure instead of throwing.
What we learned
That the hardest part of building an "agentic" system for underserved users isn't the individual models — it's the orchestration discipline: deciding what to run, when, with what confidence, and how to fail gracefully when a sub-system (a low-confidence SAR reconstruction, a malformed async message, a regional model gap) doesn't behave as expected. We also learned, concretely, the difference between Gemini API key access and Vertex AI access in terms of quota, auth, and production readiness — the kind of thing you only really learn by hitting the wall.
Honest scope
Two of our five agents ship with real, runnable architectures but untrained/simplified models rather than production-accuracy weights, given the 4-week build window: the SAR-to-optical U-Net is architecturally complete but untrained (no paired training pipeline was feasible in time), and the carbon estimator uses a closed-form physics approximation rather than the full gradient-penalized PINN described in our chosen challenge. Both are documented in-code and in the README, with an explicit roadmap for the production upgrade path. We'd rather be transparent about scope than overstate it.
What's next
Training the SAR-to-optical model on the SEN12MS-CR paired dataset, upgrading the carbon estimator to a full physics-informed neural network fused with SoilGrids priors, and adding the enterprise hardening layer (Agent Identity, Agent Gateway, Model Armor) needed before real farmer data flows through the system.
Log in or sign up for Devpost to join the conversation.