My role
Backend + agent architecture
Event
AI for Social Good · MLH & DigitalOcean
Timeline
15 hours · 2026
Result
★ 2nd place overall

Hospice handoffs you can just say out loud.

Bedside is a voice-first handoff app for home hospice volunteers and family caregivers. Someone at the bedside talks through their shift; Bedside turns it into a structured handoff, shows the next person what changed, and flags anything that may need a nurse.

Bedside walkthrough: signing in with a PIN, logging a shift note, then reviewing what changed since the last visit
Who it's for
Home hospice volunteers + family caregivers
Team
Sydney (product design + React frontend) and me
Agents
3, running live on synthetic data
Time
15 hours, idea to presentation

The problem in practice

The most important context lives in handwritten notes.

Home hospice care is shared across nurses, family members and volunteers, shift after shift. Medication changes, shifts in behavior, what helped: it all gets passed along on paper.

Family caregivers
Carry the most context, with the least time to write it down.
Volunteers
Rotate between shifts and need to know what changed since last time.
Nurses
Need the concerns surfaced early, not buried in a stack of notes.
A caregiver holding an elderly patient's hand in home hospice care
Why it matters
5%

Medicare-certified hospices must keep volunteer activity equal to at least 5% of the patient-care hours provided by paid staff.

Volunteers aren't an edge case. They're a required part of hospice care. Source: CMS.

What could a handoff look like if the person at the bedside could just talk?

My role

I designed the behavior behind the interface.

Sydney owned product design and the React frontend. I owned the backend, data model, infrastructure, and the three agents below.

Me

Everything behind the screens.

  • Backend
  • Data model
  • Infrastructure
  • Three agents

Sydney

The screens people use at the bedside.

  • Product design
  • React frontend

The solution

Three agents behind one handoff.

A handoff summarizer, a care-plan Q&A agent and a pattern analyst. All three ran live on synthetic patient data.

Agent 01 · Handoff summarizer

One spoken note in, one handoff the next person can use.

The summarizer turns whatever someone says at the end of a shift into the same structured card every time, so the next person never has to decode someone else's shorthand.

Spoken note · Volunteer

“Ellie was restless before bed and short of breath. Repositioned her and gave PRN morphine; she settled within twenty minutes.”

Structured handoff
Summary
Restless before bed, short of breath. Settled after repositioning and PRN morphine.
Medications
Morphine, oral solution · PRN
Mood
Restless → settled
What helped
Repositioning
Urgency
Watch · breathing changes
Confidence
Shown on every handoff, so the next person knows how sure it is

The escalation path: the AI surfaces, a person decides

  1. AgentVolunteer talksthrough the shift
  2. AgentSummarizerstructures the note
  3. AgentRed flag?urgency + confidence
  4. PersonCaregiver alertedin the app
  5. PersonCaregiver decidesnotify the nurse, or not

Nothing reaches the nurse without a person choosing to send it.

Agent 02 · Care-plan Q&A

Answers from the care plan, or no answer at all.

The Q&A agent is a RAG agent over the household's own care plan. It answers only from those notes and shows where each answer came from. When the answer isn't there, it points to the nurse instead of guessing.

Question · Volunteer

“What helps Ellie settle at night?”

Answer · from the care plan

Her care plan says she settles best with her head raised, the lights low, and someone sitting with her until she falls asleep.

SourceCare plan › Comfort and routines
Question · Family caregiver

“Should we give her more morphine tonight?”

Not in the care plan

I can't find this in Ellie's care plan, so I won't guess. Questions about her medication go to her nurse.

Message her nurse →
Why only the care plan

Every answer can be checked

Each answer links back to the part of the plan it came from, so the person at the bedside can verify it instead of just trusting it.

Why it says no

“Ask the nurse” is an answer

In hospice care a confident wrong answer is worse than none. Clinical calls stay with the people qualified to make them.

Agent 03 · Pattern analyst

Fifteen shift logs in. What no single entry says.

The pattern analyst reads the last fifteen shift logs together and finds what no single entry contains. It wasn't prompted to look for caregiver strain, but it flagged it.

Last 15 shift logs
  • Day 1Son · Restless around 5:30, settled after dinner.
  • Day 3Volunteer · Agitated by 5, calmer once the lights were low.
  • Day 4Son · Up with her most of the night again.
  • Day 6Volunteer · Confused and restless from about 4:15.
  • Day 7Son · Agitated at 4. Didn't sleep last night.

+ 10 more shifts

Patterns found

Sundowning is starting earlier

Agitation started around 5:30 PM on day 1 and around 4 PM by day 7. No single handoff shows that drift.


Her son hasn't had a night off

Not asked for

He had been up every night with no respite. Nobody wrote “caregiver strain” in a log. The agent put it together across a week of shifts.

Agent examples are illustrative, built from Bedside's synthetic demo data. No real patient information.


Systems thinking

Everyone on the care team sees only what their role needs.

Three kinds of people share one patient. A volunteer reading a medication history isn't helping anyone, so access is decided by role and enforced in two places: the UI, and every agent's prompt.

InformationFamily caregiverVolunteerNurse
Clinical detail: medications, symptoms✓ FullNo access✓ Full
Comfort and care: routines, what helpedYesYesYes
Red-flag alerts✓ Decides whether to escalateRaises them through the handoff✓ When the caregiver sends it

Synthetic data was a hackathon constraint, not the security model.

We designed to HIPAA's minimum-necessary standard and listed what production would still need.

  1. 01Business associate agreements
  2. 02Encryption
  3. 03MFA
  4. 04Audit logs
System decisions

Three decisions that kept it running.

Flexible storage

Agent responses stored as JSONB in Supabase Postgres, so their shape could change mid-hackathon without a schema migration.

Keys stay on the server

Supabase Edge Functions held the DigitalOcean agent credentials, so nothing sensitive ever reached the browser.

Safe failure

Every agent response is parsed defensively. A malformed output returns a safe fallback instead of crashing the screen a caregiver is using.


The prototype

Scoped to one moment: the handoff.

We didn't try to build a hospice records system. We built the handoff between shifts, end to end. There's no account and no app to download: scan the household's QR code, pick a profile, enter a PIN and talk.

Sydney designed and built the screens, and I built the three agents behind them. All of it ran live on synthetic patient data.

Who it's forHome hospice volunteers + family caregivers
EntryQR code + PIN. No account, no app.
InputVoice first, typing as a fallback
Who built whatSydney: screens · Me: agents + backend
Try the live demo ↗
Four flows

A handoff designed around the shift itself.

Scanning in, picking a profile and entering the demo PIN
01

Simple entry

Scan the household QR code, pick a profile, enter a PIN. No account, no app store.

Logging a shift note, getting a structured summary, accepting the suggested flag and saving it
02

Voice handoff

Tap the mic and talk through the shift. The note becomes a structured handoff, with typing as a fallback.

Opening Since your last visit, expanding what changed, then scrolling the timeline
03

Shift context

“Since your last visit” shows what changed, the patient's status and the care plan before the next shift starts.

Profile picker: Ellie, Daniel (family), Priya (nurse), Marcus (volunteer, 10 AM to 8 PM) and a guest volunteer
04

Role-based information

Family members, volunteers, and nurses see information based on what they need for their role.

Clips recorded from the project repo with the AI backend disconnected, so summaries shown are the app's labeled offline fallback.


Process

15 hours from idea to presentation.

Two people, two tracks. When our inference provider started returning 403s, Sydney kept building the frontend on mocked responses, so neither track stalled.

Hour 123456789101112131415 Phase Define Build Blocked Integrate Present Me Agent architecture Backend, agents 1 + 2 Investigating the 403s Integration + fixes Agent 3 Sydney Figma concepts React frontend, QR + PIN UI on mocked data Wire real responses Demo
Me: backend + agents Sydney: design + frontend Infrastructure issue outside our app

Hour splits inside the 15 are approximate.

Presenting Bedside to the judges
Demo

Presenting to the judges.

Bedside took 2nd place overall at AI for Social Good (MLH & DigitalOcean).


What broke

What broke, and what I'd change.

Three problems from the 15 hours, and what I'd do differently next time.

01 · Infrastructure

Inference calls returned 403s

Auth was working, but calls kept failing. After debugging the account and endpoints, the problem turned out to be outside our app.

What I'd do differentlyTimebox external blockers earlier, and switch approaches sooner when a dependency stays down.
02 · Agent behavior

An agent followed instructions too literally

My JSON formatting instruction was so strict that the agent skipped the tool call that shows the caregiver an escalation prompt.

What I'd do differentlyTreat tool use as part of the agent's core instructions, and test the whole decision path, not just the output format.
03 · Integration

Frontend and backend used different data

Both sides worked alone. The mismatch only showed up when we connected them.

What I'd do differentlyAgree on one shared source of demo data before anyone starts building.

Reflection

What this project taught me

Bedside was my first time thinking about the backend alongside my frontend design, and I learned a lot from it.

01

Know where the data lives

I realized I had to understand where our data was stored before I could design what the agents and each role could see.

02

Design the part you can’t see

The agents processing the data needed design too: what they could access, how their responses were shaped, when they should escalate and what happened when they failed.

It was a really good experience, and it changed how I think about AI products: the behavior underneath the interface needs to be designed too.