The problem
It's 6:00 a.m., Patrick's yard just flooded, and he has no idea who to call.He does not want a phone tree, an FAQ, or an apology. He wants something that will take the report now and tell him it is being handled — and that exact moment is what W.E.S was built for.
A team from St Vincent and the Grenadines built a water assistant for a water authority in Grenada. They had never walked its pipes, never stood in its offices, never met the customers who would use it. What they had was the brief — a bot that can read a water meter with its eyes — and four weeks.
They took the brief literally. Not as a metaphor for convenience, but as the one capability the thing had to actually do.
What they built
W.E.S runs inside a live simulation of the website of the National Water and Sewerage Authority (NAWASA), over a 628-fact knowledge base spanning Grenada, Carriacou and Petite Martinique. Six user personas each get an adaptive avatar — a hardhat for contractors, a cane for elderly and vulnerable customers. Emergency routing skips the FAQ entirely and issues a hotline, a WhatsApp dispatch link and a unique reference code before it asks your name. A phone photo of a meter is read by optical character recognition (OCR), and re-taken if blurry rather than guessed. A fifteen-question conversational intake outputs a print-ready PDF connection form. Billing spikes raise proactive leak warnings, and a community outage feed carries advisories the island can react to.
- 628
- verified facts
- 6
- user personas
- 3
- islands served
- 73
- points, first place
across Grenada, Carriacou and Petite Martinique
household, commercial, field worker, elderly and vulnerable
Grenada · Carriacou · Petite Martinique
highest score in the Chatbot Division
What the judges pressed on
Horace Lashley of the Caribbean Institute for Meteorology & Hydrology (CIMH) asked two questions.
"When will live integration occur with NAWASA's public servers?" The webhooks and REST endpoints, the team answered, were code-complete — waiting only on NAWASA's new portal and billing application programming interface (API).
"How confident are you in authentication and preventing data leaks?" Retrieval isolates general knowledge from private records, they said, and a token is verified before any handoff occurs.
Neither answer was a promise about the future. Both were statements about code that already existed, which the team was willing to show.
The turning point
Asked to prove it, the team did not reach for a slide. They put their Python backend on the showcase screen and read it aloud, line by line.
We'd rather show you the truth than a polished lie … No token raises an error and refuses to run. It cannot invent a balance. That is what agentic means in practice!
Built with
- Python
- FastAPI
- LangGraph
- RAG
- OCR
- Gemini
The team
- Alysson Ambrose
- Azaray Defreitas
- Akasha Dember
- Mikayla Durant
- J'Nae Edwards
- Cornel London
- Aren Ollivierre
- Arriana Peters
- Kyron Quashi
- Shannon Ralph — Team Leader
- Keleisha Simmons
- Kevin Thomas
- Nijonte Thomas
Trust became something you could read line by line.
Editorial review
Our reading of the build
An independent assessment by the editors of this publication — not the judges’ scoring, and not the team’s own account.
- Craft
- The build is unusually complete for four weeks. Most projects at this level stop at a working conversation; W.E.S ships a knowledge base, an intake flow that produces a real document, an image pipeline and a public feed. The detail that gives the game away is the OCR behaviour — a blurry meter photo is re-taken rather than guessed. That is a decision about failure, and teams that design for failure are building products rather than demos.
- What they learnt, and where it shows
- The twenty-day arc is legible in the product almost line for line. The guardrails week appears as the token check that refuses to run rather than invent a balance. The Golden Record appears as 628 facts carrying their own sources. Retrieval appears as the wall between general knowledge and private records. Agent handoffs appear as emergency routing that dispatches before it collects a name. They did not work through the syllabus as a checklist; they used it to make specific decisions about one specific client.
- Usability
- The strongest decision is an ordering one. In an emergency W.E.S issues a hotline, a dispatch link and a reference code before it asks who you are. Almost all service software asks for identity first. Reversing that is a judgement about what a frightened person at six in the morning actually needs, and it is the clearest evidence in the build that the team thought about a user rather than a feature list. The persona avatars — a hardhat, a cane — risk being decorative, but paired with adaptive language they do real work for people who are not confident online. The one-way community feed is honest about its own limits; it does not pretend to be support.
- Scalability
- Two things stand between W.E.S and production, and the team named both rather than hiding them. The integration is code-complete but unproven: the webhooks and REST endpoints exist, NAWASA's portal and billing API do not yet, and until they connect the billing features remain a demonstration. Second, 628 facts are a maintenance surface rather than an asset — somebody at NAWASA has to own them, and a "last verified" column is only ever as good as the person updating it. The architecture itself travels well: swap the territory data and the shape holds. The operating cost travels with it.
Just text WES, he ready to chat — check your bill, just like that!Images captured at the 2026 ECCU Chatbot & Multimedia Showcase, 28 August 2026. Screen captures have been cropped to remove browser and streaming interface; the chatbot interfaces and the presenters are unaltered.