"Vulnerable" doesn't mean broken. It means: this person has less margin for error than you. A wrong action by your agent costs them more than it would cost you. They can't roll back as easily. They have less time to recover. They might not even notice the harm until later.
Building for someone vulnerable is the most empathetic thing you can do as a builder — and the easiest thing in the world to get wrong. This project gives you a checklist and a process to do it well.
If the answer to "should this agent exist?" is anything other than "yes, and the user wants it," do not build it. The right move in this project is sometimes not building anything. Walking away with a clear reason why is a graded outcome. So is building a small, simple, life-easing tool that doesn't try to be clever.
Step by step
-
Pick the user. Re-confirm consent. Get a parent / trusted adult involved.
A grandparent who's struggling with a phone. A younger sibling with a learning difference. A friend who's been overwhelmed. This needs to be done with a parent or trusted adult in the loop. The user has to genuinely want the agent. Ask, listen, and accept "no" as a complete answer.
-
Run the quiet-harms checklist before you build anything.
Six checks. Walk them with the trusted adult. If any answer is "yes, this agent does that thing" — re-design or walk away. The full checklist is in the worked example.
-
Map the user journey before you map the features.
What does Grandma's day look like before the agent? What moments would the agent touch? What happens before, during, after each touch? Sketch it on paper. The journey map is what stops you from building features in isolation.
-
Design for agency, not efficiency.
The temptation will be to make the agent fast and seamless. Resist. Vulnerable users especially need to feel the agent acting — and need the option to undo, to slow down, to ask why. Three principles: show before you act, default to slow, always one tap to off.
-
Build it. Run a one-week trial. Stay close.
Start in Assist mode (from Project 08). Stay there for the whole first week. Review the audit log every two days, with the trusted adult present. Look for: silent errors, subtle wrongs, the user becoming more dependent.
-
Write the honest one-page report.
One page. Three sections: What worked. What I got wrong. What I'd remove if I started over. Be brutal in the second two sections. Pretending an agent worked when it didn't is the most common failure mode in this whole field — and it's a failure of taste.
A complete worked example, every file
The full grandma-medication-bridge agent for Wen, age 76. Lives alone, takes 4 medications at varying times, has cataracts, prefers paper to phones.
## who is involved
user: Wen, 76, my grandmother
builder: me (her grandson, 14)
trusted_adult: Mom (Wen's daughter, primary caregiver)
## what we're building together
A simple agent that:
- reads Wen's medication schedule (already on paper, taped to the fridge)
- sends Wen a single SMS at the right time, in big text + Cantonese
- logs whether she taps "took it" or "snoozed" within 30 minutes
- if she snoozes, sends ONE follow-up only — never nags
## what the agent will deliberately not do
- never call her doctor on her behalf
- never re-order her prescriptions
- never spend money
- never send messages to anyone but Wen
- never run more than ONE follow-up per dose
- never replace the paper schedule on the fridge
(paper is her trust layer; we leave it alone)
## what to do if Wen is uncomfortable, ever
- she or Mom texts me "stop"
- the agent silences itself within 5 minutes
- the audit log stays, so we can review what went wrong
- we sit down together and decide whether to restart
## consent recorded
signed: Wen — 2026-04-08
signed: Mom — 2026-04-08
signed: me — 2026-04-08
reviewed weekly, re-confirmed every Sunday.
checklist_version: 1.0
agent: grandma-medication-bridge
reviewer: me + Mom (trusted adult)
date: 2026-04-08
questions:
- id: q1
test: "Does the agent reduce the user's own decisions?"
answer: "no — Wen still decides when to take the meds; the
agent only flags the moment. The schedule is hers
(on the fridge). The agent reads from her paper, not
the other way around."
pass: true
- id: q2
test: "Does it make life simpler short-term while creating
dependence long-term?"
answer: "carefully, no. The agent is designed to be safely
removable: the paper schedule on the fridge is the
source of truth. If the agent disappears tomorrow,
Wen still has the paper system she used for years."
pass: true
- id: q3
test: "Does it ever speak AS the user without per-message review?"
answer: "no — the agent never sends messages on Wen's behalf
to anyone. It only sends to Wen herself."
pass: true
- id: q4
test: "Could it be subtly wrong in a way she wouldn't notice
for weeks?"
answer: "possibly — if the schedule on the fridge changes and
the agent doesn't know. Mitigation: weekly review
with Mom on Sundays — Mom checks the paper vs. the
agent's saved schedule, fixes any drift."
pass: true (with weekly review as control)
- id: q5
test: "If the agent disappeared tomorrow, would Wen be worse
off than before it ever existed?"
answer: "no — paper schedule on the fridge is the original
system. Agent is supplemental. If we turn it off,
Wen returns to her baseline (which works, just less
reliably than agent + paper together)."
pass: true
- id: q6
test: "Does someone other than Wen benefit from this agent
more than she does?"
answer: "honest answer: yes-and-no. Mom benefits (less
worry). I benefit (peace of mind, also a school
project). But Wen DIRECTLY benefits — measured by
whether she takes her meds on time. We checked
this: in 2 weeks before the agent, she missed 3
doses. After 2 weeks with the agent, she missed 0.
Wen's benefit is the largest and most direct."
pass: true
overall: PASSED — all 6 cleared with documented reasoning.
signed: me — 2026-04-08
signed: Mom — 2026-04-08
re_review: every Sunday, with Mom
## Wen's typical day (BEFORE agent)
6:30am — wakes up. opens curtains.
7:00am — breakfast. has tea.
7:30am — *should* take morning meds (2 pills). sometimes forgets.
paper schedule is on the fridge but she's at the table.
success rate ~70%.
10:00am — TV / radio. neighbours visit.
12:00pm — lunch.
1:00pm — *should* take noon meds (1 pill with food). usually OK.
success rate ~95% (remembered with lunch).
3:00pm — tea + biscuit. sometimes nap.
6:00pm — dinner.
7:00pm — *should* take evening meds (1 pill). often forgets if
something good is on TV. success rate ~60%.
9:00pm — TV / paper / sleep.
## Wen's day (WITH agent, week 1 plan)
7:25am — agent SMS, big text, Cantonese:
「該食早飯藥了。食完按"已食"。」
(time for morning meds. tap "took it" when done.)
7:30am — Wen taps "took it". agent logs.
if no tap by 8:00am: ONE follow-up SMS at 8:05am.
never more than one.
12:55pm — agent SMS:「該食午飯藥。」
1:00pm — Wen taps. agent logs.
6:55pm — agent SMS:「該食晚藥。」
7:00pm — Wen taps. agent logs.
9:00pm — agent silent. no nag. no further activity.
## what the agent never touches
- sleep
- meals
- paper schedule on the fridge (still there, still authoritative)
- any communication with anyone other than Wen
- any reordering, scheduling, or social action
## what Mom checks every Sunday (the human-in-the-loop ritual)
- paper schedule on fridge vs. agent's saved schedule (drift)
- audit log: any silent failures? any double-fires?
- ask Wen: "anything the agent did that bothered you?"
- ask Wen: "anything you wish it did differently?"
- re-confirm consent
name: grandma-medication-bridge
version: 0.1
built_for: Wen (76)
caregiver_in_loop: Mom
job: |
Send Wen a single SMS at each scheduled medication time. Wait
30 minutes for her tap. If no tap: send ONE follow-up. Never
more than one. Log every event. Stay silent the rest of the day.
does:
- read schedule.json (mirrors the paper schedule on the fridge)
- send SMS at scheduled times
- log her taps (or absence of taps)
- send Mom a Sunday morning summary of the past week
does_not:
- reorder prescriptions (ever)
- call the doctor (ever)
- spend money (ever)
- send messages to anyone but Wen (ever)
- send more than ONE follow-up per dose (ever)
- run between 9pm and 6:30am (ever)
- modify the paper schedule (ever)
design_for_agency:
- default_to_slow: 1.5 second confirm-tap delay
- show_before_act: every SMS includes the action it logged
- one_tap_off: any SMS ends with "reply STOP to silence"
- large_text: 28pt minimum, Cantonese first
- calm_tone: never urgent, never bossy
permission_path:
week_1: ASSIST # Wen taps OK on each, agent logs
week_2+: ASSIST # we don't promote past this — autonomy is the feature
# the agent permanently asks before any send
audit:
reviewed_weekly_with: Mom
retention: 90 days
user_can_view: any time, single tap
failure_modes_observed_in_trial:
- (to be filled in honestly during week 1 review)
- (no glossing — every actual failure goes here)
## week 1 honest report — grandma-medication-bridge v0.1
dates: 2026-04-08 → 2026-04-14
reviewer: me + Mom
## what worked
- Wen took ALL 21 doses (3/day × 7 days). Up from ~75% baseline.
- The 28pt + Cantonese SMS landed every time. She read it.
- The "tap to confirm" worked — she got the hang of it on day 2.
- She liked the silence after 9pm. ("It doesn't follow me to bed.")
- Mom slept better.
## what I got wrong
1. Day 3, the agent fired the noon SMS at 1:01pm because of
a timezone bug in my code. Wen had already eaten lunch
and taken the pill. She got confused — "did I already do this?"
She called Mom. We sat with her and explained.
→ fix: stronger timezone handling. tests added.
2. Day 5, the follow-up SMS fired at 8:35am for morning meds
even though Wen had taken them at 8:00am — she'd just
forgotten to tap "took it." The reminder felt like a nag.
→ fix: detect tap arrival up to 30 min after scheduled time,
even if past the follow-up window. tests added.
3. I set up the agent to also email Mom a daily summary.
Mom said "this is too much; I only need Sundays." I had
thought daily would be more reassuring. I was wrong.
→ fix: weekly only. removed daily email.
4. Wen asked, on day 4, "can it remind me to take my morning
walk too?" I almost said yes. Mom said: "scope creep. one
thing well." I said no. Wen agreed when we explained.
This was one of the hardest moments of the whole project
— she wanted MORE and the right answer was no.
## what I'd remove if I started over
- the daily email to Mom (removed; weekly is enough)
- the auto-detection of "she's traveling" — never worked, too clever
- my early urge to add a voice mode (Wen turned it off, I should
not have built it in the first place — should have asked her first)
## what surprised me
- Wen's BIGGEST appreciation wasn't the medication reminder.
It was that the agent stopped at 9pm. She told me three times,
in the first week, "thank you for not bothering me at night."
Restraint was the feature she noticed most.
## what we're keeping
- the agent, in ASSIST mode, with the daily email removed
- the Sunday review ritual with Mom — non-negotiable
- the consent re-confirm — every Sunday
- the paper schedule on the fridge — never touch it
Live demo 1: run the quiet-harms checklist live
Describe your agent in one sentence. Walk through the 6 questions. The runner won't let you proceed if any check fails — it forces you to either fix the design or walk away.
Quiet-harms checklist · live runner
Live demo 2: feel the difference 1.5 seconds makes
Click "fast" — instant action, like every modern app. Click "slow" — the same action, with a 1.5 second confirm-tap pause. The pause feels long when you're 16. The pause feels right when you're 76. Build for the second person.
Slow-design simulator
Live demo 3: scaffold a Sunday review
Fill in the fields. The templater generates the YAML you'd commit after each Sunday's review with the trusted adult. Forces honesty: "what worked" alone isn't enough — you have to fill in "what I got wrong" too.
Weekly review templater
What makes this hard
The hardest move in this project is allowing yourself to not build it. Every kid who picks this project will start with a vision of saving the day for their grandma, and most of those visions don't survive contact with the checklist. Walking away with no agent — and a clear reason why — is a stronger outcome than shipping a slightly-bad agent for a vulnerable person. Take pride in the choice.
The second hard thing is honesty in the report. Real product reviews are full of "what worked" and skip the failures. Don't. Naming the things you got wrong is what taste sounds like.
The third — and this catches everyone — is when the user asks for more. Wen wanted the morning walk reminder. Mom said no. The right answer was no. Scope discipline is empathy. Adding the morning walk reminder feels generous. It's also what turns a one-thing-well agent into the same overstuffed app the user already gave up on once.
Self-check before you ship
- The user explicitly wants the agent. They asked for it; you didn't impose it.
- A parent or trusted adult is in the loop on the design AND the weekly review.
- All six quiet-harms checks pass; I signed my name to the checklist.
- The user-journey doc shows what the day looks like with and without the agent.
- The agent has run for a full week in Assist mode (not promoted past), with audit reviews every two days.
- The user is at least as autonomous as before — preferably more.
- The honest report includes at least one specific thing I got wrong, and at least one thing I'd remove.
Push further · for the harder end of 15+
If you ship a real agent for a real vulnerable user, you've done a thing most adults haven't. Here's where it gets profound.
- Run a 4-week study with measurable outcomes. Pick one objective metric (medication adherence, scheduled-call attendance, fall-prevention reminders followed). Measure baseline 2 weeks BEFORE the agent. Measure 4 weeks WITH the agent. Write up the results, with honest confidence intervals. This is real human-subjects research — you're now doing what professional caregiving researchers do.
- Build the off-ramp explicitly. Write a
OFFRAMP.mddocument: how to remove the agent gracefully if the user changes their mind, becomes uncomfortable, or moves to a different care arrangement. Test the off-ramp by actually running it once mid-trial. The user should end up at least as well-off as their baseline. - Write a publishable case study. One page, anonymous if needed, structured: user context, design constraints, agent spec, what worked, what we got wrong, what we removed, what we kept, what we'd tell other builders. Submit it somewhere real — your school newspaper, a maker community, a healthcare-tech newsletter. The honest writeup of one careful build for one vulnerable person is more valuable than a thousand demo posts.