This is a submission for the Hermes Agent Challenge
What I Built
FarmRoute Agent v4.0 — an AI-powered agricultural delivery planner
that decides which crops to deliver first, plans optimal routes across
10 villages, handles real-world disruptions like flooding and road
closures, and self-improves by learning from past delivery errors.
The entire project was built with Hermes Agent. I gave Hermes a skill
file describing the problem — Hermes planned the architecture, wrote
873 lines of backend code, built the animated UI, and ran the first
delivery simulation entirely by itself.
The problem it solves:
A farmer has 8 types of perishable crops (strawberry spoils in 12h,
potato lasts 96h) that need delivering to 10 villages with different
weather conditions, road risks, and time windows. Which crops go first?
Which route wastes the least time? What if a bridge closes?
FarmRoute Agent answers all of this in real time.
Demo
Code
https://github.com/Suhail-26/farmroute-agent/
My Tech Stack
- Hermes Agent (Nous Research) — built the project + powers delivery planning
- owl-alpha via OpenRouter — free LLM reasoning backbone
- Python 3.14 + Flask — simulation engine (873 lines)
- Vanilla HTML/CSS/JS — animated terminal-style UI (28KB, zero dependencies)
- memory.json — persistent self-learning across sessions
How I Used Hermes Agent
- Hermes Built the Entire Project
I created one skill.md file and typed this in Hermes:
Hermes read the skill, wrote app.py (873 lines), built
the animated UI (28KB), created the memory system, started
the Flask server, tested all API endpoints, and delivered
the first complete delivery plan — without me writing
a single line of code.
2. Hermes Reasons Through Every Delivery
Every RUN triggers 25+ reasoning steps:
- Recalls past sessions and learned lessons from memory
- Checks spoilage urgency for all 8 crops
- Checks weather conditions at all 10 villages
- Detects road disruptions before planning
- Runs LLM chain-of-thought planning via OpenRouter
- Generates scored delivery report with bonuses
Every step is visible in the animated reasoning feed —
you watch Hermes think in real time.
3. Hermes Learns From Its Own Errors
Every session is saved to memory.json. The agent learns from:
- Disruptions → village risk score increases next run
- Critical spoilage → crop priority bias increases
- Low scores → human-readable lesson generated
Bias decays 0.95× per run so learning stays fresh. After
10 runs you can watch the agent improve — priority bars
shift, lessons accumulate, scores trend upward. This is
Hermes Agent's memory system applied to real logistics.
Top comments (2)
A crop-delivery planner that learns from errors is a great applied use of agents, and the learns-from-errors part is the bit that separates a useful tool from a static optimizer, because real logistics is full of the messy exceptions (a road out, a delayed harvest, a buyer who changed quantity) that a fixed plan can't anticipate but a system that adapts from what went wrong can. The design question that decides whether learns-from-errors is real or just a tagline is how the error feedback is captured and reused: does a failed delivery become a durable signal that changes future plans (this route is unreliable in monsoon, this buyer's estimates run high), or does it evaporate after the run. Memory with provenance is what makes the learning trustworthy, you want it to remember the lesson and why, so a once-true fact (this bridge is closed) can be revised when conditions change rather than ossifying into a wrong rule. The other thing I'd watch is grounding the planner's decisions in real constraints (capacity, perishability windows, distances) so the optimization is over reality, not the model's guesses, because in logistics a confident-but-wrong plan has real spoilage cost. Capture the errors as durable, revisable lessons, and ground the plan in hard constraints. That learn-from-failure-with-memory instinct is core to how I think about Moonshift. How are you feeding errors back, updating a model/heuristic, or storing them as retrievable cases the planner consults next time?
Thank you for this — you've put your finger on exactly the
design tension I was thinking about while building this.
To answer your question directly: FarmRoute stores errors as
retrievable cases the planner consults next time, not as model
updates. Every delivery session writes to memory.json with full
provenance — what happened, which village, which crop, what the
weather was, and what the delay cost in reward points. The next
run reads this before making any decisions.
The bias system works in layers:
Crop bias — if strawberry hit critical spoilage, its
priority score increases next run. Not permanently — it decays
0.95× per session so a one-time event doesn't permanently
distort the plan.
Village risk — if Harborpoint had a bridge closure, its
risk score increases. Future runs route around it or add
buffer time. When it stops causing problems the score decays
back toward baseline naturally.
Human-readable lessons — every disruption generates a
plain text lesson like "bridge_closure at Harborpoint: +35min
delay" stored alongside the numeric scores. This is exactly
your provenance point — the agent remembers the lesson AND why.
Your point about once-true facts ossifying into wrong rules is
the exact reason I chose 0.95× decay over permanent storage.
A closed bridge eventually reopens. A flooded road dries out.
The decay means the system revises naturally as conditions
change without needing explicit "forget this" logic.
The grounding question is where I'd say this is currently
honest-but-limited. The constraints are real — spoilage windows,
vehicle capacity (max 4 crops per trip), distance limits (120km),
time windows per village. But the disruption data is simulated
rather than pulled from a live feed. In a production version
you'd want real road condition APIs feeding the disruption engine
so the planner is optimizing over actual current reality rather
than sampled scenarios.
Moonshift sounds genuinely interesting — the provenance-aware
memory framing is exactly the right mental model for this kind
of system. How are you handling the revision problem when a
learned rule turns out to be wrong?