An AI operations manager for campus water
It watches every tank, spots a leak or an overflow, works out the cause, acts, and then checks that the fix actually worked.
Sensors are simulated in this demo. The ingest API takes real flow meter readings in the same shape.
A loop that finishes the job, not a dashboard that waits for you
Most monitoring stops at an alert. Here the alert is the start: the agent investigates, decides, acts and confirms, and every step lands in a timeline you can read.
A heartbeat reads every tank and meter and flags readings that break the baseline it has learned for that building.
Recent readings, baseline flow, water balance, pump log and the maintenance schedule. It does not conclude before it has looked at all five.
One cause and one permitted action, with its reasoning written down. The tools refuse any action that does not match the decision.
Only reversible actions: close a riser valve, stop a pump, alert the warden and plumber.
It waits, re-reads the sensors, and only then closes the incident. If the fix did not work, it escalates to a human.
The same alarm, three different answers
An outflow alarm is not always a leak. The agent decides from evidence, so the right action changes.
Isolate it
Outflow is far above baseline, the tank balance is intact and the pump is only refilling a draining tank.
Closes valve V2 on the riser and alerts staff.
Stop the pump
The tank is full, water enters but never leaves through a meter, and the pump keeps running. The float switch is stuck.
Stops the pump and asks staff to inspect the float switch.
Leave it alone
A tank flush is on the maintenance schedule. The flow is large, but it is expected.
Dismisses the incident with no action and stays quiet until the flush ends.
Built on AWS
Serverless end to end, defined in one SAM template. The agent runs as a Strands agent on Bedrock, and falls back to a rule-based planner, saying so in the timeline, if the model call fails.