HomeKeep

Inspiration

Elders in households usually know when an appliance stops working, but often don't have the model number, the invoice or the purchase date. Booking apps, repeated explanations and lost service records turn a simple fault into a burden. We wanted a helper they could simply talk to. Initially we have focused on TV, Fridge and AC, but it can be expanded to cover almost every appliance.

What it does

HomeKeep lets an elder report an appliance problem by voice, in their own words, with no paperwork. It keeps each appliance case alive across conversations, from the spoken problem to a fix the elder / family confirms.

• Remembers appliances and open cases between conversations; nothing but the appliance type and a nickname is ever required.
• Offers checks only when they are backed by a reviewed manual for the exact, verified model. Otherwise it says it has no approved guidance and offers service.
• Stops and gives approved safety advice on warning signs such as a burning smell or sparks.
• Reads a booking back in full (provider, full date, time window, fee or fee uncertainty, demo status) and books a demo technician only after the elder says "yes" at the right moment. The decision is made by deterministic code, never by the language model.
• Closes a case only when the elder confirms the problem is fixed; a technician marking a visit complete is not enough.

How we built it

• Alexa+ track: a self-hosted MCP server (/mcp, spec 2025-11-25, Streamable HTTP, stateless, OAuth via Amazon Cognito) built with the MCP Python SDK 1.29.1. HomeKeep's own agent calls its tools only through an MCP client over HTTP, so the MCP path is exercised on every turn (code path: app/orchestrator/agent.py, which connects through mcp.client.streamable_http).
• Conversation: The Strands Agents SDK on Amazon Bedrock (Converse API with tool use), running Amazon Nova Pro. The agent sees only customer tools; approval and execution tools are reachable only by the channel's deterministic approval guard.
• Data: one Amazon DynamoDB table with optimistic versions, conditional writes and transactions. (Document uploads to Amazon S3 are designed but not part of this release.)
• Hosting: one ARM64 container on Amazon ECS Express Mode (Fargate behind an Application Load Balancer with an AWS-provided HTTPS domain), images in Amazon ECR, logs in CloudWatch, costs watched by AWS Budgets.
• Voice client: TypeScript and Vite, using the browser's Web Speech API with the en-IN locale; the browser voice client is the simulated Alexa+ experience on top of the MCP server.
• Process: an AI-native SDLC with Claude Code: an approved plan per slice, tests first, an independent verifier and a policy reviewer before each merge (docs/SDLC.md).

Challenges we ran into

• Cognito's wizard forcing email or phone for username sign-in
• Managed login showing "Login pages unavailable" until a style exists
• Bedrock's use-case form: a Marketplace subscription was required to use Anthropic Haiku 4.5 model that our role could not create, so switched to Nova.
• Had to switch to Nova and hardening the server for it (stripping <thinking> text, carrying state between turns).

What's next for HomeKeep

HomeKeep is built so that adding an appliance means adding reviewed guidance content, not new code. Next, we plan to:

• Extend it from ACs, fridges and TVs to washing machines, water purifiers, geysers and other appliances common in Indian homes;
• Add Hindi, Bengali, Tamil and other major Indian languages, so elders can speak in the language they're most comfortable with;
• Connect to Alexa+ through the same MCP server, so a household can use HomeKeep without a screen; partner with real service providers to replace the demo service desk, keeping the same rule that nothing is booked without the elder's clear "yes".

Built With

• amazon-alexa
• amazon-bedrock
• amazon-cloudwatch
• amazon-cognito
• amazon-dynamodb
• amazon-ecr
• amazon-ecs
• amazon-nova
• aws-fargate
• aws-iam
• docker
• fastapi
• mcp
• python
• strands
• typescript
• vite
• web-speech-api