Harvest Convoy_UGMDU

• 

Inspiration

In most Indian villages, one combine harvester is shared across eight or more farmers. When unseasonal rain approaches, everyone phones the same operator on the same evening — and he takes them roughly in call order. Smallholders lose crops that were ready. Some crops are cut too early. Nobody is coordinating, and every rainy season farmers lose grain that didn't need to be lost.

Custom Hiring Centres already exist across Tamil Nadu — 65 in Theni district, 100 in Thanjavur, funded by the state. What doesn't exist is a way to decide who gets the shared machine first when the harvest window is short. That gap is the problem this project targets.

What it does

Harvest Convoy is an AI agent that schedules the shared harvester across a village cluster before the rain arrives — and, uniquely, tells some farmers to do nothing.

A farmer registers once on Telegram in Tamil or English (their choice) with four short messages: village name, a location pin, crop confirmation, transplant date and area. From May registration to September harvest, they hear almost nothing. The agent talks; the farmer, mostly, doesn't.

When rain enters the forecast, the system fires at 6 AM daily. Farmers whose crops are ready get "the machine is coming today, you're second in the queue." Farmers whose crops are not ready get "your crop is not ready — do nothing, no need to check in. We're tracking it every day." That second message is the whole point of the project. Software that only tells you what to do is a chatbot. This one tells you when not to act.

When multiple ready plots compete for scarce capacity, AI advocates argue on their behalf. If they deadlock, one operator tap resolves it with two named buttons. Every farmer bumped in a past season argues harder next time — with a mathematical ceiling that never lets history override a real crop emergency.

How we built it

A strict design rule: the AI never touches a number.

Crop ripeness (Growing Degree Days from real Open-Meteo weather), machine capacity, route ordering, and the fairness weighting are all plain tested Python. Amazon Nova Pro on Bedrock is only used for advocacy and judgment — never for calculation. If an official asks whether the AI made up a maturity date, the answer is no, and the code proves it.

Multi-agent negotiation. A coordinator plus one plot advocate per farmer, capped at three rounds. Deadlock is the human escalation. Structured claims only, never free prose. Built on the AWS Strands Agents SDK.

Deployed on AWS in ap-south-1: Bedrock AgentCore Runtime hosts the agent (ARM64), EventBridge fires a daily 6 AM check via a Lambda shim, DynamoDB stores farmers, plots, decisions and the fairness ledger, and CloudWatch traces every decision nine levels deep. Prompt caching cut model cost by 64% — about $0.011 per full scheduling run, roughly $2/month standing.

Tamil and English. Every farmer-facing string is hand-authored and reviewed by a native speaker across multiple rounds. We deliberately do not model-generate safety-critical Tamil — see the challenges section.

Sixteen ADRs. Every architectural decision is recorded before code was written, with alternatives considered and consequences. Verification steps caught ten separate defects that tests missed.

Challenges we ran into

Nova Pro produced invalid Tamil script. When we asked the model to generate Tamil, it returned character sequences that are not valid Tamil words. Structured fields (urgency, days-overdue, acres) were unaffected, so scheduling was never compromised — but user-facing Tamil is now generated from hand-authored templates. Documented publicly with verbatim samples.

EventBridge Scheduler cannot invoke AgentCore Runtime directly. The scheduler cannot format the blob body the runtime expects. A small Lambda function sits between them as a translator.

ADOT defaulted to localhost:4318. The AWS observability library silently defaulted to a local collector that doesn't exist in AgentCore's code-deployment mode. Found by reading the library's source; fixed with one environment variable.

A season-long backtest exposed a scheduling bug. We replayed the real 2025 Kuruvai season across two Tamil Nadu clusters (Theni and Thanjavur delta) using archived weather. The backtest immediately revealed that the scheduler had no memory of harvested plots — a plot the machine visited kept competing for capacity on every later day. All eleven affected plots regressed this way. Every short demo had missed it. Only a full season exposed it.

Ten defects found by verification. Registration was never persisting to storage. Three callback handlers had no authorization check. Rollover was actively excluding unreachable farmers instead of including them. Each was caught not by tests, but by attempting to actually use the code path. Documented as its own README section: "Verification finds what tests don't."

Accomplishments that we're proud of

• A working, deployed, autonomous system that has fired unattended for consecutive mornings and delivered Tamil messages to a real phone.
• Validated against a real past season — not just tested on synthetic data. The 2025 Kuruvai backtest caught a production bug we would otherwise have shipped.
• A fairness ledger with a mathematical ceiling — inspectable, testable, and provably unable to override genuine agronomic urgency.
• An auditable AI system. Every decision is reconstructable from stored records via a decision-replay tool. Never LLM-regenerated.
• A documented model limitation. Rather than hide Nova Pro's Tamil failure, we tested it, published the samples, and designed around it.
• Sixteen ADRs, 659 tests, and complete honesty about the gap between local and deployed paths.

What we learned

That verification finds what tests don't. A test confirms what you thought to check; verification exposes what you didn't. Ten separate defects across this project were caught not by a red test suite but by trying to use the code with a real phone, a real forecast, or a real season. This is now a documented pattern in the README rather than a run of luck.

That the honest answer is often a better one. When Nova Pro couldn't produce Tamil, we didn't disguise it — we documented it and templated the messages. When our backtest exposed a scheduling bug, we didn't quietly rewrite the results — we published both the before and after. When authorization gaps surfaced, we wrote up all three publicly. Every one of these decisions strengthens the submission, not weakens it.

That designing for silence is harder than designing for messages. The most important message this system sends is the one that says do nothing. That took as much thought as everything else combined.

What's next for Harvest Convoy

A real pilot. Everything to date runs on real weather and real coordinates but simulated farmers. One village cluster, one real machine operator, one Kuruvai season — that's the next step. AC&RI Madurai (in our home city) is where we'd take the crop ripeness thresholds to be validated by an agricultural scientist before any pilot begins.

FPO federation scale-out. Multiple villages, multiple operators, cross-cluster fairness — designed for, not yet built.

A second crop. Maize is the defensible next target: combine-harvested, moisture-critical at harvest, with real published research behind its thermal thresholds. Paddy stays the priority.

The system was deliberately scoped to solve one problem completely rather than five half. Everything above is future work, honestly labelled.

Built With

• amazon-bedrock
• amazon-web-services
• bedrock-agentcore
• cloudwatch
• dynamodb
• eventbridge
• lambda
• nova-pro
• open-meteo
• pytest
• python
• strands-agents
• telegram-bot-api