DynaRoute — Project Story
Inspiration
Every delivery-gig app makes the same silent assumption: a driver looking at a new order will either take it or won't, and that's the end of the reasoning. In practice, most drivers just say yes — there's no real support telling them whether this specific order, given where they already are and what they're already carrying, is actually worth the gas and time it costs. That gap felt like exactly the kind of problem an AI agent should solve: not by hiding a black-box score behind a button, but by reasoning the way an experienced, sharp driver already does — and showing its work.
What it does
DynaRoute runs two delivery couriers side by side on the exact same stream of orders. One is a baseline that accepts everything, no questions asked. The other is an AI agent that asks a sharper question for every order: does taking this make my whole shift more profitable — not just this one trip?
The smart agent doesn't just accept or reject — it can hold several orders at once and re-plans its route every time a new one arrives, chaining nearby pickups and deliveries instead of driving back and forth. And every single decision comes with a plain-language explanation: the marginal profit that order adds, the rate it works out to per hour, and why that cleared or missed the bar. Nothing is a black box.
How we built it
We built two independent, fully working versions of the same core decision engine, on top of two very different stacks — a real-time web dashboard, and a version running on an actual local street-network graph of a real city, so routes reflect real turns and real distances instead of straight-line guesses.
At the center of both is the same idea:
$$\Delta J = J(O_t \cup {i}) - J(O_t)$$
— the marginal utility of adding a new order $i$ to the courier's current batch $O_t$. Utility itself nets out revenue against distance cost, time cost, and fuel. On top of that, a reservation rate stops the agent from accepting anything that's merely non-negative but still drags down its average earnings per hour.
We also built a small automatic tuner that runs the simulation many times with different cost weights and keeps the combination that earns the most per hour — instead of hand-guessing the numbers.
Challenges we ran into
The biggest surprise came when we swapped a toy map for real city coordinates: distances that used to be trivial were suddenly 15–30 km apart, and our agent turned pathologically cautious, rejecting almost everything because travel costs dwarfed the rewards. We had to recalibrate the whole economic model and bias demand generation toward realistic, mostly-local trips — real geography breaks assumptions that look fine on a whiteboard.
We also learned the hard way that "accept if profit is positive" isn't a smart rule on its own — our first version of the AI agent was actually less profitable per hour than the naive baseline, because it happily took barely-profitable orders that diluted its average. Adding the rate-based reservation threshold fixed that.
On the engineering side, letting the agent hold multiple orders means testing every valid pickup/delivery order — a combinatorial search that gets expensive fast. And real-world routing services aren't always reliable, so we had to build automatic fallbacks so the app keeps working, un-crashed, even when a route is genuinely impossible or a routing service is unreachable.
Accomplishments that we're proud of
- Two independent implementations of the same idea, both working end to end, both validated with real test runs.
- In testing, the smart agent earned roughly 3x more per hour than the baseline that accepts everything — with a fraction of the distance driven.
- Every decision the AI makes is explainable in a sentence, not hidden behind a score.
- The system survives real-world messiness — blocked roads, surge events, unreachable orders — without ever crashing mid-shift.
What we learned
Marginal-utility reasoning beats naive greedy acceptance, but only if you also account for rate, not just sign. Real geography changes an algorithm's behavior more than any parameter tweak. And for an autonomous agent to be trustworthy — to a driver, a judge, or a regulator — showing why it decided something matters just as much as the decision being correct.
What's next for DynaRoute
- Move from a demo routing service to a production-grade, self-hosted one.
- Upgrade the route optimizer to a proper solver for larger fleets and bigger batches.
- Add demand forecasting so the agent can position itself ahead of orders, not just react to them.
- Merge both prototypes into one deployable product.
- Pilot the model against real driver earnings data to validate it outside simulation.
Built With
- folium
- leaflet.js
- networkx
- openstreetmap
- osmnx
- osrm
- pandas
- python
- react
- recharts
- scikit-learn
- streamlit
- tailwindcss
- typescript
- vite
Log in or sign up for Devpost to join the conversation.