Bellhop

Thumbnail
Landing page
Insights
Features
Resident profile
Ring a bell
Learns then remembers
Dispatch
Learned in conversation
Live board

Inspiration

Most call bells in a care home are not emergencies. They are a glass of water, a chat, a question about lunch, or a small request. But every press still pulls a nurse away from someone who needs hands. Nurses are stretched thin, and the non-urgent bells are the easiest work to hand off. We built Bellhop to give that time back.

What it does

Bellhop is an autonomous fleet of small robots that answers the non-urgent call bells so nurses do not have to.

Answers the bell. When a resident presses it, the closest free robot drives to their room, greets them by name, and listens.
Triages by voice. It scores every call for urgency. Falls, pain and distress go to a nurse immediately, with the urgency stated in words as well as colour.
Remembers each resident. It learns small facts from conversation, like "likes tea with honey". Uncertain facts wait in a review queue until a nurse approves or rejects them.
Keeps nurses in charge. A live dashboard shows every call and every robot. Nurses can resolve a call, add or move residents, review what the robots learned, and send any robot to any room by hand.

How we built it

Robot: Raspberry Pi robots. Speech to text uses Deepgram, with Moonshine as an offline fallback. Piper handles text to speech, and Claude writes replies and triage.
Backend: Python and FastAPI, built as a hexagonal design (domain, ports, services, adapters) so each part, like the database or the speech engine, can be swapped independently. It streams live events to the dashboard over Server-Sent Events.
Memory learning: Claude proposes facts from each resolved call. Every fact must be backed by a verbatim quote from the resident, and uncertain facts go to a nurse review queue instead of being stored.
Persistence: SpacetimeDB stores residents, memory, care data and call history, so a restart loses nothing.
Frontend: React, TypeScript and Vite, with a typed client generated from the API contract, so a contract change breaks the build.
Demo tooling (not part of the product): because we cannot put a fleet in a real care home for a hackathon, we wrote a separate simulator that plays a fictional home through the same public API the robot and staff use. The dashboard cannot tell the difference, and it never contains any mock data of its own.

Challenges we ran into

Keeping the robot safe. It must never decide a medical question alone, so everything unsure escalates to a nurse.
Not storing wrong facts about a resident. We gate each fact (quote grounding, confidence floor, hedge detection) and send borderline ones to a human.
Connecting hardware, ML and the backend in one weekend. We held the API contract steady, and built a demo simulator so each part could be tested on its own.
Making the dashboard calm and readable for nurses at the end of a long shift. We used large type and strong contrast, and urgency is never colour alone.
Teaching the robot to find rooms and drive to them on its own. It has no map. It reads a marker on each door with its camera, works out which room it is looking at, and steers toward the right one. We had to bound how far it explores, stop it safely when it loses a marker, and refuse stale drive commands so it never lunges toward an old target.

Accomplishments that we're proud of

A complete loop from bell press to robot visit to triage to learned memory to nurse review, with a live dashboard on top.
Over a thousand automated tests across the backend, simulator and frontend, including a test that fails if the API contract and the dashboard types drift apart.
Data that survives a backend restart, verified against a real SpacetimeDB server.

What we learned

Design for the nurse first. If a nurse cannot read a screen at a glance, it does not matter how clever the AI behind it is.
A clear API contract lets a team work in parallel without blocking each other.
For anything that touches a resident's care, precision beats cleverness. We would rather miss a fact than store a wrong one.

What's next for Bellhop

Run the full fleet on real hardware in a care setting with staff feedback.
Hand robots non-urgent tasks beyond talking, such as fetching water.
Dispatch without blocking the bell request, and reject stale drive commands on the robot.
Staff login and per-role views.
Measure the fact-extraction accuracy of Claude on a held-out set before trusting it.