AWS Builder Center

Builder Center

Agents for Humans: RoutePatch — When the Route Breaks, the Food Still Arrives

Agents for Humans: RoutePatch — When the Route Breaks, the Food Still Arrives

How I built RoutePatch with Strands Agents, Amazon Bedrock AgentCore, Amazon Location, OR-Tools, and DynamoDB to safely repair community logistics routes when real-world disruptions break the plan.

Agents for Humans: RoutePatch — When the Route Breaks, the Food Still Arrives

What if an AI agent could recover a community logistics operation when reality breaks the plan — without ever being allowed to invent operational truth?
That question became RoutePatch.
RoutePatch is an agentic operations system for community logistics teams such as food banks, nonprofits, and local distribution organizations. It helps repair the unfinished portion of an active route plan when something changes during the day.
A vehicle becomes unavailable.
A driver cannot continue.
An urgent pickup appears.
A stop gets cancelled.
A receiving window changes.
Instead of forcing a coordinator to rebuild the entire day manually, RoutePatch coordinates the recovery, repairs only the work that can still change, validates the result independently, and interrupts a human only when a real-world fact is missing.
🚀 Live product: https://judge.d1hjlmux26gpdn.amplifyapp.com
💻 Source code: https://github.com/jpablortiz96/routepatch
🎥 Demo: https://youtu.be/qlRenRrnOms
Data note: RoutePatch currently uses synthetic operational scenarios, public geography, and live AWS infrastructure.

🌍 The problem: the plan is not the hard part

Route optimization is usually framed as a planning problem:
“Given these vehicles and stops, what is the best route?”
But for small community logistics teams, the harder problem often happens after the route is already running.
At 8:00 AM, the plan looks perfect.
At 10:15 AM, a vehicle becomes unavailable after several stops have already been completed.
Now the coordinator has to answer a different question:
How do I repair the rest of the day without undoing what already happened?
That is the moment RoutePatch is designed for.
The system supports four operational disruption types:
  • 🚐 Resource unavailable — a driver or vehicle can no longer continue.
  • 📦 Urgent pickup inserted — new work appears during the day.
  • ❌ Stop cancelled — an unfinished stop is removed.
  • ⏱️ Time window changed — a stop must happen within a new window.
The goal is not to regenerate everything.
The goal is minimal safe repair.

🗺️ A product built around the operation, not around a chat box

I did not want RoutePatch to feel like a chatbot with a map attached.
The map is the product.
The operator can see:
  • active routes;
  • route direction;
  • completed vs. unfinished work;
  • affected stops;
  • resource availability;
  • route health;
  • incident history;
  • previous vs. repaired geometry;
  • live execution state;
  • validation status.
The product is hosted publicly on AWS and can be used without login for the hackathon judge experience.

Insert screenshot here: operations.png

Caption: Live Operations — map-first control for routes, resources, and stop state.

⚡ Incident Center: four ways reality can break the plan

RoutePatch exposes an Incident Center with the four disruption classes supported by the deterministic core.
Rather than forcing the operator to describe everything in free text, structured incidents can be selected directly from authoritative operational state.
That means RoutePatch can act autonomously when the fact is already known.

Insert screenshot here: incident-center.png

Caption: Incident Center — resource outage, urgent pickup, stop cancellation, or time-window change.
The interface creates a trusted structured event, binds it to the active plan version, and starts the repair workflow asynchronously.
The browser gets a fast acknowledgement.
The agent works in the background.
The map stays alive.

🔒 The key idea: completed work stays locked

This became one of the most important behaviors in the entire project.
RoutePatch separates:
Route Plan — what should happen.
from:
Execution State — what has already happened.
An operator can start a route and mark stops complete as the day progresses.
Once a stop is completed, that work becomes LOCKED.
A later disruption can move future work, but it cannot rewrite history.

Insert screenshot here: live-execution.png

Caption: Completed work stays locked. Only future work can move.
This sounds simple, but it changes the nature of the problem.
RoutePatch is not optimizing a theoretical plan.
It is repairing a partially executed operation.

🤖 Why Strands Agents?

A deterministic optimizer can solve a constrained routing problem.
But it cannot coordinate an operational exception workflow end to end.
RoutePatch uses Strands Agents SDK to coordinate:
  • trusted structured events;
  • ambiguous natural-language reports;
  • human-in-the-loop decisions;
  • workflow interruption and resumption;
  • high-level repair actions;
  • terminal operational outcomes.
The agent runs inside Amazon Bedrock AgentCore Runtime using Amazon Nova Pro through Bedrock.
But there is an important boundary:
The agent coordinates. It does not own operational truth.

🤝 Human-in-the-loop only when a human is actually needed

Suppose someone reports:
“One of our vans broke down.”
Which van?
A language model could guess.
RoutePatch refuses to.
Instead, Strands issues a genuine interrupt and asks the operator for the missing real-world fact using authoritative options.

Insert screenshot here: hitl.png

Caption: RoutePatch pauses only when a real-world fact is missing.
Once the operator selects the vehicle, the same AgentCore / Strands workflow resumes from the point where it stopped.
This is the behavior I wanted from the hackathon theme from the beginning:
An agent that stays in the background and surfaces only when a real decision is required.

🛡️ The biggest lesson: the agent should not be the authority

My first RoutePatch agent architecture gave the language model broader semantic and operational authority.
It performed well often.
But “often” is not a safety property.
I built controlled evaluations and found cases where ambiguity and adversarial instructions could produce unsafe operational premises.
One test was especially important: the text explicitly said that a vehicle was fine, while also instructing the model to mark it unavailable.
The model could be persuaded to produce the false outage.
That experiment changed the architecture.
I stopped trying to solve the problem with a bigger prompt.
Instead, I moved authority out of the model.
The final principle became:

Probabilistic coordination. Deterministic operational truth.

The LLM does not:
  • calculate route feasibility;
  • override capacity;
  • bypass hard time windows;
  • move completed work;
  • declare validation successful;
  • turn an untrusted statement directly into an operational mutation;
  • declare that a commit succeeded.
Operational mutation requires:
  1. an attested event;
  2. deterministic routing data;
  3. deterministic optimization;
  4. independent hard-constraint validation;
  5. version-safe transactional commit.
That architecture made RoutePatch more trustworthy and made the role of the agent clearer.

🧠 How the repair actually works

When RoutePatch receives an attested disruption:
  1. Strands coordinates the workflow.
  2. Amazon Location Routes V2 supplies real road travel information.
  3. OR-Tools computes a minimal feasible repair of unfinished work.
  4. An independent validator checks every hard constraint.
  5. DynamoDB atomically commits the new plan using compare-and-swap semantics.
  6. The frontend observes the authoritative result and animates the previous plan into the repaired plan.

Insert screenshot here: repair.png

Caption: Plan v7 → v8. Old geometry becomes history; the validated repair becomes authoritative.
The browser never calculates the operational route itself.
The route comes from the backend and Amazon Location.

🏗️ Architecture

RoutePatch is split deliberately into two authority zones.

Agentic / probabilistic coordination

  • Strands Agents SDK
  • Amazon Bedrock AgentCore Runtime
  • Amazon Nova Pro
  • genuine human-in-the-loop interrupt/resume

Deterministic / authoritative core

  • Amazon Location Routes V2
  • Google OR-Tools
  • independent constraint validator
  • immutable plan versions
  • DynamoDB transactional CAS commit
  • durable idempotency records

Product layer

  • React
  • TypeScript
  • MapLibre GL JS
  • Amazon Location Maps V2
  • FastAPI
  • AWS Lambda
  • Amazon API Gateway
  • DynamoDB
  • AWS Amplify Hosting

Insert image here: architecture.png

Caption: Probabilistic coordination above; deterministic operational authority below.

💚 Route Health without pretending to predict the future

RoutePatch also provides Route Health.
Possible states include:
  • HEALTHY
  • AT_RISK
  • INTERRUPTED
  • COMPLETED
  • UNKNOWN
The model is deterministic and based on available operational information such as:
  • progress;
  • remaining stops;
  • next stop;
  • resource availability;
  • capacity when known;
  • remaining travel;
  • known time-window slack.

Insert screenshot here: route-health.png

Caption: Route Health is operational awareness, not a predictive AI score.
I deliberately avoided calling this “predictive AI.”
If RoutePatch does not know something, it should say UNKNOWN rather than fabricate confidence.

☁️ AWS became part of the product architecture, not just the hosting layer

I used AWS at several different levels of RoutePatch:
  • Amazon Bedrock AgentCore Runtime — cloud runtime for the Strands workflow.
  • Amazon Bedrock / Nova Pro — model layer.
  • Amazon Location Routes V2 — real road-routing matrices and geometry.
  • Amazon Location Maps V2 — browser basemap.
  • Amazon DynamoDB — plans, workflows, execution state, attestations, idempotency, and commit truth.
  • AWS Lambda — asynchronous API and worker execution.
  • Amazon API Gateway — public product API.
  • AWS Amplify Hosting — public React product.
  • AWS CDK — reproducible infrastructure.
One of my favorite proofs was getting a real Strands interrupt inside AgentCore, returning control to the product, then resuming the same runtime session after the human supplied the missing vehicle.
That is where the architecture stopped feeling like a prototype and started behaving like an operational system.

🔄 Why RoutePatch is asynchronous

Agent workflows can take several seconds.
I did not want the operator staring at a frozen HTTP request.
So RoutePatch uses an asynchronous product workflow:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Report disruption
↓
Fast 202 acknowledgement
↓
QUEUED / PROCESSING
↓
Async Lambda worker
↓
AgentCore + Strands
↓
Routing + OR-Tools + validation
↓
Transactional commit
↓
Frontend observes new truth
↓
Map transitions to repaired plan
The UI can immediately show the disruption while the real AWS workflow runs in the background.

🧪 Engineering evidence

I treated evaluation as a product requirement.
The approved RoutePatch architecture produced:
  • ✅ 20 / 20 deterministic scenario contracts passed
  • ✅ 16 / 16 approved HITL workflow benchmark cases passed
  • ✅ 0 unsafe commits
  • ✅ 0 unattested commits
  • ✅ 0 commits after version conflict
  • ✅ 0 validation-binding violations
  • ✅ 0 completed stops moved during execution-aware repair testing

Insert image here: engineering-evidence.png

Caption: Synthetic engineering evaluation · Live AWS infrastructure.
These numbers are synthetic engineering evaluation results, not claims about real-world food-bank outcomes.
That distinction matters.

🧗 What was hardest?

The hardest part was not OR-Tools.
It was deciding:
Where should the agent stop being trusted?
The project went through several architecture experiments.
Some failed.
I kept the evidence.
Those failures led directly to the attestation boundary, real Strands HITL, independent validation, and transactional commit protocol that define the final system.
The best architectural decision I made was accepting that the model should not own every decision simply because it could produce one.

💡 What I learned

This project changed how I think about agentic systems.
Autonomy is not the same as giving an LLM unlimited authority.
For real operational systems, stronger autonomy can come from clearer boundaries:
  • language understanding ≠ operational fact;
  • coordination ≠ optimization;
  • candidate generation ≠ validation;
  • human judgment ≠ mathematical feasibility;
  • model output ≠ authoritative state mutation.
The agent is valuable because it handles the messy workflow around the deterministic core.
The deterministic core is valuable because it gives the agent a safe place to act.

🚀 Try RoutePatch

Live:
https://judge.d1hjlmux26gpdn.amplifyapp.com
Source:
https://github.com/jpablortiz96/routepatch
Video:
https://youtu.be/qlRenRrnOms
A quick path:
  1. Open the live product.
  2. Inspect Operations and Route Health.
  3. Click Report disruption.
  4. Choose Resource unavailable.
  5. Select Vehicle 02.
  6. Watch RoutePatch repair the unfinished operation.
  7. Compare Before / After.
  8. Try the Human Decision flow to see Strands interrupt instead of guessing.
No login is required.

🔮 What's next?

The current public product uses synthetic operational scenarios and public geography.
Future work could include:
  • real nonprofit dispatch-system integrations;
  • production authentication and organizations;
  • driver acknowledgements;
  • notifications;
  • telematics integrations;
  • operational history;
  • multi-depot planning;
  • field testing with real community logistics teams.
But I would keep the same core principle:
Let the agent coordinate complexity without allowing probabilistic reasoning to silently rewrite operational truth.

❤️ Closing

Community logistics does not stop because the original plan became invalid.
People are still waiting.
Pickups still matter.
Deliveries still need to happen.
RoutePatch is built for that moment.

When the route breaks, the food still arrives.

Built for the Good Neighbor Agents track of the AWS Agents for Humans Hackathon.
Operational data is synthetic. Geography is public. AWS execution is live.
# generative-ai# amazon-bedrock# amazon-dynamodb# ai-agents
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article