We've Got This

An Alexa+ add-on for families looking after a parent. It notices the care nobody has taken on yet, like the ride to Dad's eye check-up, and asks the right person. It never assigns.

Comment

Inspiration

I'm from Lagos, Nigeria. We're a family of five, and our mum has passed away. Our dad is approaching seventy, recently had surgery, and has to manage medications, supplements, check-ups, and other health-related responsibilities. He even had to time his own medication while trying to understand what was happening with his health. Meanwhile, my brother lives in the UK and still wants to know how Dad is doing.

Like many Nigerian families, we take care of our parents while working to make a living. Everyone cares, but nobody has the complete picture. Who is taking Dad to his eye check-up? Who is checking whether he needs a ride? Who makes sure someone follows up? Sometimes, the task that gets forgotten is the one nobody realised they were responsible for.

Most care apps start with a task someone has already entered. We wanted to start one step earlier, with the ordinary conversation before the task exists. When someone says, "Daddy's eye check-up is tomorrow at ten," We've Got This can recognise that transportation might be needed and ask the family to confirm it.

The name comes from what family members tell one another when life gets overwhelming: We've got this. We wanted to turn those words into something practical, helping families coordinate care without requiring a full-time caregiver or creating another source of stress.

What it does

We've Got This is an Alexa+ add-on for family care coordination: a self-hosted Model Context Protocol (MCP) server that Alexa+, or any MCP client, calls as tools. It maintains one shared care record for a family and identifies potential gaps in responsibilities before they become problems.

  • Understands everyday conversations: Recognises potential care tasks hidden in ordinary statements, such as an upcoming medical appointment that might require transportation.
  • Asks before assuming: Clearly distinguishes confirmed information from AI inferences. A suggested ride remains a question until someone confirms it.
  • Coordinates willing family members: Identifies suitable people based on availability and location, explains why they were selected, and waits for them to accept responsibility.
  • Follows up on commitments: Checks whether arrangements are still on track and can ask another available family member if the original volunteer cannot help.
  • Supports care beyond medication: Helps coordinate meals, companionship, transportation, appointments, and practical household needs.
  • Connects families across locations: A family member in London might arrange an order for someone in Lagos without being asked to perform tasks that require their physical presence.
  • Provides transparency without surveillance: Records commitments and completion information while avoiding unsupported claims about who performed an action. A doorbell event, for example, cannot establish someone's identity.
  • Works across multiple interfaces: Connects Alexa on an Echo, a React console, Telegram text and voice messages, Google Calendar, Gmail, a Fire TV application for Vega OS, and Ring-related functionality.

A central principle guides the entire system: a missing record is not proof that something was missed. The system supports the person receiving care as a participant in their own record, not merely someone being monitored.

Explore the interactive family simulation: https://krqi2tpsif.us-east-1.awsapprunner.com/world

Set up a demo household using made-up names: https://krqi2tpsif.us-east-1.awsapprunner.com/setup

How we built it

We built We've Got This using TypeScript and the official MCP SDK, with Streamable HTTP, OAuth 2.1 authentication with PKCE, structured tool outputs, resources, prompts, and interactive MCP Apps cards. The server exposes 31 tools and maintains a shared, append-only care record. Household-based data partitioning helps enforce access boundaries, while member credentials determine who is speaking instead of trusting identity claims made inside a conversation.

The system's core is the Care Gap engine, a deterministic component that identifies and ranks potentially overlooked responsibilities. Rather than asking an AI model to invent urgency scores, we calculate risk using explicit factors:

$$ \text{Risk} = \text{Cost} \times P(\text{dropped}) \times \text{Confidence} $$

Each result retains its contributing factors, making it possible to explain why a particular responsibility received its ranking. We also use property-based tests to verify key rules, including bounded values, deterministic calculations, and the principle that known information must not be treated as less reliable than an assumption.

Our agent also considers whether interrupting someone is worthwhile:

$$ \text{Value} = \text{Harm Avoided} - \text{Interruption Cost} $$

This helps the system avoid overwhelming family members with notifications. It considers the potential benefit of an intervention against the disruption it creates and reduces repeated requests to the same person.

For AI planning, we use Claude Sonnet 4.5 through Amazon Bedrock with the Strands agent framework. We created a custom NoBlame plugin to prevent the system from turning missing information into accusations. Our Echo talks to the server through the open-source Alexa skill MCP bridge, hosted on Amazon Bedrock AgentCore Runtime, and we measured Amazon Nova Pro under that bridge's system prompt, a stand-in for the Alexa+ orchestrator's prompt that we did not write. Our own planner is deployed on AgentCore Runtime too, though no family uses that path yet.

Our infrastructure runs on AWS, using Amazon DynamoDB for the care record, Amazon SNS for delivering requests, and AWS App Runner, CodeBuild, and Amazon ECR for deployment. The React console and three-dimensional family simulation act as MCP clients. Telegram supports text and voice notes through Amazon Transcribe and Amazon Polly, with custom speech vocabularies for family names and medication terms. Google Calendar synchronisation works in both directions, and Gmail is integrated as well.

We also built a Fire TV application for Vega OS, allowing users to access the Care Board with a remote. It ran on the Vega Virtual Device, not a physical Fire TV. For Ring, we implemented a webhook following the Partner API contract, including HMAC verification and idempotency handling. We also built a client that reads a Ring Developer Playground doorbell's devices, Event History and pictures from Ring's real API. Because the Playground does not send webhooks, the motion, ring and package events in our demo are simulated, signed with the real partner key, and clearly identified as such.

Testing was a major part of the build. We created a multi-person household simulator that became the open-source npm project household-sim. Our automated test suite contains 842 tests, including adversarial scenarios involving credential swaps mid-session, cross-household access attempts, and prompt injection through notes.

Challenges we ran into

Working around Alexa+ limitations: Alexa+ add-on tools were not available to independent builders, and we could not deploy our server directly into the native add-on environment. We worked around this by testing the server on a real Echo through a fork of the open-source Alexa skill MCP bridge. We also evaluated scenarios under the bridge's own prompt rather than relying exclusively on our custom instructions.

Giving the AI reliable time information: MCP gives a server no way to know the current date, and our planner was never told it. It invented one, resulting in a live medical record dated 19 December 2024. We addressed the issue with three safeguards. This taught us that AI systems must receive and validate essential contextual information rather than being trusted to infer it.

Handling different languages: In one test, a family member referred to eye drops in Spanish as "gotas para los ojos." The expression did not match the scheduled medication entry, and the system reported that there was no record of the dose. We encountered similar problems in 10 of the 11 languages tested before fixing the issue at the server level. The challenge was not just recognising different words, but matching them safely against existing records without inventing facts.

Preventing unnecessary tool calls: Under the bridge's prompt, Nova Pro routed two unrelated requests, "Remind me to water my plants every Sunday" and "I ordered a new phone case", to our two newest care tools. We added one sentence to each of those tool descriptions stating what does not qualify as care. This fixed both cases, although it reduced performance on two held-out Nova Pro evaluation cases. We retained the change and reported the trade-off.

Integrating Ring events: The Ring Developer Playground provided a virtual doorbell but did not send the webhooks needed for our full event-driven workflow. Its event-history filtering also behaved unexpectedly. We implemented a simulator for the missing delivery path while ensuring simulated events were not presented as real-world observations.

Managing AWS evaluation quotas: A zeroed Amazon Bedrock daily quota returned a throttling error that looked like an exhausted daily quota. Diagnosing this cost us much of a day. Because our evaluations and our family's production Telegram experience shared a daily budget, we also had to schedule expensive tests carefully.

Accomplishments that we're proud of

Our biggest accomplishment is building a system that does not turn silence into blame. In our tested absence scenarios, the raw model produced false accusations in 50-58% of cases, while our system recorded 0% false accusations in those evaluations. When a support worker logged a medication dose on another person's behalf, the raw model misattributed the action to the person in 25% of cases, while our system recorded 0% such misattributions in the tested scenarios.

We are also proud of our measured tool-selection results. Claude Sonnet 4.5 selected the correct first tool in 170 of 187 cases, achieving 90.9% accuracy. On 84 held-out phrasings, it selected correctly in 73 cases. Amazon Nova Pro, operating under a prompt we did not write, achieved 86.6% accuracy, selecting correctly in 162 of 187 cases.

We tested whether the system could leave unrelated requests alone. On Amazon's MASSIVE en-US test set, it correctly left 87.6% of 2,538 non-care requests untouched, with 87.3% on the held-out development set.

Beyond the benchmarks, my own family uses the production system. Since 23 September, we have been using it through Telegram. When I added Dad's upcoming check-up, it asked whether he would need a ride. I accepted responsibility, and the task was completed. That was the moment the project became more than a technical demonstration. It helped turn a real family conversation into an action someone agreed to take.

We also made the project easier for others to explore. Running npm run story replays the entire simulated day without requiring an AWS account or credentials. Combined with our 842 automated tests and open-source household simulator, this makes the system's behaviour easier to inspect and reproduce.

What we learned

The most important lesson came from our own family's care record. During the first 28 days, two of Dad's 108 scheduled medication doses had a recorded entry. The other 106 had no record. We could not honestly conclude that those doses had been missed, because the absence of an entry did not prove what had happened. One of the two recorded doses was even logged after the board had already displayed "no record."

That experience reinforced a fundamental principle: absence of evidence is not evidence of absence. A care system must distinguish between a confirmed event, a reported event, an inference, and something that remains unknown.

We also learned that trust has to live in the architecture, not just in the prompt. Asking an AI model to avoid blaming people is not enough if the system still allows it to turn incomplete records into accusations. By putting important calculations and record descriptions in deterministic code, we made those components incapable of expressing certain unsupported conclusions.

Another lesson was that AI performance depends on the tools, instructions, and evaluation conditions surrounding the model. Clear tool descriptions improved routing, but changes sometimes introduced trade-offs elsewhere. We learned to evaluate those trade-offs, include held-out cases, and report measured results rather than presenting only our best run.

Finally, we learned that care technology must respect the dignity of the person receiving care. The system should help families coordinate without treating their loved ones as surveillance subjects. It should preserve who recorded information, distinguish observations from assumptions, and make uncertainty visible. Technology can help families follow through on responsibilities, but it should never replace human judgement or pretend to know something it cannot establish.

What's next for We've Got This

Our next goal is to bring We've Got This to more families while preserving its core principles of consent, accountability, and transparency.

  • Native Alexa+ integration: When add-on capabilities become available to builders, we want to connect the server directly and display the Care Board on Echo Show.
  • Ordering through Alexa: Relatives abroad can already say they ordered Daddy's lunch from the app they use, and someone nearby is asked to take it in. Next, we want to hand the order itself to Alexa's own shopping, with a clear confirmation before anything is bought.
  • Real Ring webhook integration: We plan to test the complete event-delivery workflow with a physical Ring doorbell.
  • More local languages: We want to support Nigerian English, Yoruba, Igbo, and Nigerian Pidgin through voice as suitable speech services become available.
  • Testing with more families: We plan to work with additional households, with their informed consent, to understand different care arrangements, communication habits, and privacy expectations.
  • Continued reliability testing: We will keep improving our evaluations for tool selection, language matching, access control, false assumptions, and unnecessary interruptions.

Our broader ambition is to make family care easier to coordinate, especially for people who cannot afford a full-time caregiver but still need to balance work and caring for loved ones. We do not want to replace family relationships with automation. We want to give families a clearer picture of what needs attention, who has agreed to help, and what remains uncertain.

We've Got This began with our dad, but the problem reaches far beyond our household. We believe technology can help families care for one another more reliably, without creating more guilt or confusion. The goal is simple: when someone says, "We've got this," the family has the information and coordination needed to make those words mean something.

Built With

Share this project:

Updates

Submission history