Inspiration

Older adults and people with disabilities should be able to get practical support without giving up control of their choices or sharing a constant stream of personal information. I wanted to explore how a TV and a conversational assistant could help someone learn at their own pace, find recurring activities, and ask for help while keeping privacy and consent visible.

Saathi is a prototype built around that idea—not a care service, medical product, or emergency-response system.

What it does

Saathi brings together an Alexa+ web simulation and a Vega OS TV app using one local demo backend.

  • Explore four recurring clubs, such as Garden Circle and Slow Morning Chess, with different ways to participate.
  • Join or leave a club and see the same membership and upcoming sessions across the web and TV experiences.
  • Follow practical guides at a chosen pace, with brief or step-by-step instructions.
  • Ask Saathi questions using a deterministic local planner, or optionally use a configured model provider.
  • Review exactly what a help request would share, then explicitly confirm it in the UI.

The TV app is designed for remote navigation and includes Alexa voice-select labels for controls. Voice selection requires a compatible physical device and remote; it has not been verified in the Vega Virtual Device. The Alexa+ experience is a web simulation, not a live Alexa+ connection.

Contacts, activities, and requests are seeded demo data. Help delivery is simulated: no person or emergency service is contacted. Saathi does not monitor users or track whether they completed a task.

How we built it

The web app and server use browser APIs and Node.js built-in modules, so they need no extra npm dependencies. The server provides activity, guide, preference, and support APIs, a local MCP Streamable HTTP endpoint, and an offline tool planner.

The TV app is built with React Native for Vega OS and the Amazon Vega SDK. Both clients use the same local backend to demonstrate shared activity and preference state. Amazon Bedrock Mantle Chat Completions is an optional model-backed path; the local planner remains available when model credentials are not configured.

Challenges we ran into

Vega tooling downloads timed out several times before a retry completed. The Vega Virtual Device was useful for building and remote-navigation work, but it does not use its microphone, so it cannot verify Alexa voice selection. That needs a compatible physical Vega device and Alexa Voice Remote.

We also encountered an Operation not allowed error using the AWS CLI Converse route. We used the separate Bedrock Mantle Chat Completions route instead. Keeping help requests behind a user-reviewed consent step was another important design constraint: the model can prepare a preview, but it cannot send a message or confirm consent.

Accomplishments that we're proud of

  • Built a Vega OS TV app and a browser experience around one shared backend.
  • Made activity membership, task guidance, and privacy choices visible across both interfaces.
  • Added a server-enforced consent boundary for demo help requests.
  • Kept the web/server dependency-free and provided an offline assistant fallback.
  • Added automated server and TV app tests, and built release packages for Vega.

What we learned

We learned that voice support on a TV can mean selecting clearly labeled on-screen controls, not giving an app unrestricted access to a remote’s microphone. We also learned to distinguish a model’s suggested action from a user’s consent, and to make demo status and failure limits explicit.

Building for Vega is distinct from building for Fire OS. The Virtual Device helped with early testing, but it cannot replace hands-on checks of voice, focus, and accessibility on a compatible physical device. Our personas and accessibility choices are design hypotheses that still need feedback from older adults and disabled people.

What's next

We want to test Saathi with older adults and disabled people, and validate the Vega experience—including voice selection—on compatible physical hardware. Before any real-world use, the prototype would need authenticated profiles, durable privacy controls, verified contact details, reliable consent-based delivery, moderation, and clear failure handling. Those capabilities are not part of this demo.

Built With

Share this project:

Updates

Submission history