Before You Walk

Check whether the water point is working before making the trip.

Comment

Inspiration

The question I kept coming back to was simple: what can you build when there isn't money for new hardware? Start with a shared phone, patchy connectivity, and one everyday problem worth solving.

A report that a water point worked this morning isn't much help if it has stopped working by the time someone gets there. Before You Walk starts with that gap. Check what is known, ask the right person when it isn't clear, and don't turn an old report into a confident answer.

What it does

Before You Walk checks reports for ten fictional water points. Old reports expire. Conflicting reports stay visible. It also checks whether a report will still be fresh when someone is expected to arrive, not just when they set out.

If a closer point is uncertain, the agent can ask its opted-in caretaker for confirmation. A clear reply can change the recommendation. No reply means it stays uncertain. There is a small message budget, so the system can't keep pestering people.

The public demo lets you try the decision rules and play the caretaker. A separate runnable Strands agent uses a local model over the same rules; its recorded run is available on the site. The locations, reports, and messages are simulated. This isn't connected to real caretakers or SMS, and it hasn't been piloted. Water availability is not a water-quality or safety assessment.

How we built it

The project uses TypeScript, Strands Agents SDK, Zod-validated tools, and a React/Vinext interface. Five tools inspect the reports, request confirmation, read a reply, record its interpretation, and return a checked answer.

The important split is between the model and the rules. The model coordinates the work. Code decides whether a report is fresh, whether contact is allowed, and whether the answer is supported.

The recorded run uses Gemma 4 through Ollama. The browser itself doesn't call a live model. Bedrock is an optional configuration that hasn't been live-tested; AgentCore isn't implemented.

Challenges

The tricky part wasn't getting an answer. It was deciding when there wasn't enough information to give one.

A reply can't make itself a trusted source, change the clock, or grant permission to contact someone. For now, the parser accepts a narrow set of English replies. Ambiguous messages and unsupported languages stay unknown. That's a real limitation, but a useful one to make visible at this stage.

Accomplishments

The recorded Strands run completed all five tool steps in about 11 seconds. It replaced a stale Market tap report with a new simulated caretaker reply and returned the result checked by the shared rules.

All 32 synthetic tests passed, including checks for stale reports, contradictions, arrival time, consent, duplicate requests, timeouts, replay, and unsupported reply content. These are prototype checks, not evidence of real-world impact or a model reliability benchmark.

What we learned

An agent doesn't need more freedom everywhere. Here, it needs enough freedom to ask a useful question, then firm limits on what it can do with the answer.

Sometimes the most useful result is still "I don't know yet."

What's next

Talk with prospective users and caretakers before adding more features. Find out how quickly reports become unreliable, which languages matter, and what contact methods people actually want to use.

Then add verified opt-in messaging, saved state, and offline delivery. A small consent-based pilot could test whether this actually saves unnecessary trips. That benefit still needs to be measured.

Credits

By James Thannickal, with OpenAI Codex assistance across development and submission preparation. Built with Strands Agents, React/Vinext, the OpenAI Sites scaffold, shadcn/Base UI, Lucide, and Zod. Video narration is synthesized. Project work began September 4, 2026. Project code is MIT-licensed; dependencies and model weights retain their own licenses.

Built With

Share this project:

Updates

Submission history