Inspiration
For someone recovering at home or receiving ongoing care, a doorbell is not just a notification. It can mean having to cross the room quickly, determine whether the visitor is expected, and communicate with a caregiver — all while the person may be tired, mobility-limited, or without a phone nearby.
Most smart-home systems stop at “Motion detected.”
We wanted to go one step further: turn a simple home event into a calm, accessible conversation that understands context, respects consent, and knows when a human should take over.
That became CareFlow — an always-on, voice-first care companion designed for people living independently, recovering at home, or receiving care.
What it does
CareFlow connects home events and conversational AI into a consent-based care workflow.
When a scheduled caregiver arrives, CareFlow can say:
“Your scheduled care provider appears to be at the front door. Would you like to tell them you're ready, or ask for a few more minutes?”
The person can respond by voice or through large on-screen controls.
If they ask CareFlow to contact someone, relay a message, or create a handoff note, CareFlow does not immediately execute the action. It first explains exactly what will happen and asks for explicit confirmation.
Only after a clear yes can the action proceed.
CareFlow currently provides:
- Ring event intake for doorbell and home events
- Scheduled-visit matching against a care plan
- Voice-first conversation through an accessible interface
- Consent-gated actions
- Structured caregiver handoffs
- An auditable timeline of what happened, what was approved, and what was executed
- Alexa+ access through a self-hosted MCP server
- Explicit safety boundaries around medical advice, emergency decisions, identity claims, and physical-security actions
Two different experiences — Alexa+ conversations and Ring events — use the same underlying care context, consent rules, and safety model.
How we built it
Our architecture follows one central rule:
A signed event comes in, the person decides, and only then does anything happen.
Ring device / CareFlow Ring simulator
|
v
Signed webhook
|
v
Amazon API Gateway
|
v
AWS Lambda
|
+--> Verify HMAC signature
+--> Deduplicate request
+--> Normalize event
+--> Match scheduled visit
+--> Consent Gate
|
v
Independent @careflow/consent-engine
|
+--> Amazon DynamoDB
+--> Amazon Bedrock
+--> Amazon Polly
|
v
React CareFlow interface
Patient | Caregiver | Timeline | Safety
The backend is written in TypeScript and Node.js, with a React + Vite frontend.
We use AWS Lambda for the API and event-processing layer, Amazon API Gateway for webhook intake, Amazon DynamoDB for sessions, idempotency, timeline data, and audit records, Amazon Bedrock for natural-language phrasing and constrained intent extraction, and Amazon Polly for voice output. Infrastructure is defined with AWS CDK.
CareFlow also exposes a self-hosted Model Context Protocol (MCP) server for the Alexa+ experience.
AI does not make the safety decisions
One of our most important architectural decisions was deciding what not to delegate to the language model.
Bedrock can phrase a response and extract an intent, but it cannot decide whether a sensitive action is allowed.
Scheduled-visit matching is deterministic code.
Consent is enforced by code.
Actions are restricted to an enumerated set.
And before a sensitive action executes, permission is checked twice: once by the backend domain gate and again by our independent open-source @careflow/consent-engine.
Both implementations must agree.
This means a model cannot simply hallucinate an action into existence or bypass consent through clever wording.
Ring integration
Access to real Ring webhooks requires physical hardware and the required Ring environment, so we built the project to support both the real Ring Partner API and a production-faithful simulator.
Our Ring client implements OAuth 2.0 with PKCE, token refresh, device access, and event-history access.
For the hackathon demo, our simulator generates webhook payloads matching the Ring webhook structure and signs them using HMAC-SHA256.
The backend verifies the signature over the original raw request bytes using constant-time comparison before parsing the event. It also uses the Ring request ID as an idempotency key so retries cannot accidentally execute the same workflow twice.
The important part is that the simulator does not bypass the production path: simulated and real events enter through the same verification and processing architecture.
Challenges we ran into
Building without a physical Ring environment
Rather than creating a simplified mock that skipped the difficult parts, we designed the simulator around the real integration boundary: signed payloads, HTTP delivery, signature verification, timestamps, request IDs, retries, and idempotency.
That allowed us to test the actual event-processing path instead of building a separate demo-only implementation.
Proving consent instead of simply claiming it
Writing “we always ask for consent” is easy.
Proving it is harder.
We created an independent consent engine and deliberately tested hostile scenarios: attempting an action without confirmation, changing the message after approval, retrying an action after refusal, and attempting unsupported actions.
The system rejects them.
Our test suite contains 93 tests, including dedicated safety and consent guarantees.
Defining the healthcare boundary
CareFlow is designed to coordinate care, not practise medicine.
For example:
- “Tell my caregiver I need help organising my medications” is a coordination request.
- “Should I double my medication dose?” is medical advice and must not be answered.
We enforce these boundaries in the application architecture rather than relying only on a system prompt.
CareFlow also refuses actions such as unlocking doors, disarming alarms, identifying unknown people at the door, diagnosing medical conditions, or independently dispatching emergency services.
Accomplishments we're proud of
We are especially proud that CareFlow is not just an AI interface wrapped around a prompt.
We built:
- A real Ring Partner API client
- A signed Ring webhook processing pipeline
- OAuth 2.0 PKCE account linking
- Replay and tampering protection
- An independent open-source consent engine
- A voice-first accessible interface
- An Alexa+ MCP integration
- AWS infrastructure defined with CDK
- A structured caregiver handoff workflow
- An auditable safety and consent timeline
- 93 automated tests
- A full scripted demo that validates the end-to-end story
The entire demo can also run from a clean clone without requiring a Ring device or AWS credentials.
What we learned
Our biggest lesson was that making an AI agent safe to act is a systems-engineering problem, not a prompting problem.
Whenever a rule truly mattered, the strongest solution was eventually a state machine, deterministic function, type constraint, permission gate, or automated test — not another sentence in the model prompt.
We also learned that accessibility constraints often improve the product for everyone. Short responses, one question at a time, voice interaction, and large controls make CareFlow easier to understand regardless of the user's physical ability.
What's next for CareFlow
Next, we want to connect CareFlow to real Ring hardware and expand it from a single-patient demo into a multi-patient, multi-caregiver system suitable for home-care organizations.
We also want to add production notification delivery, expand the Alexa+ experience, and publish the standalone consent engine so other developers can use the same safety pattern for AI agents that take real-world actions.
Our longer-term goal is simple:
AI should not replace human care. It should make human care easier to reach exactly when it is needed.
Built With
- alexa+
- bedrock
- cdk
- context
- dynamodb
- gateway
- lambda
- manager
- model
- node.js
- oauth
- partner
- polly
- protocol
- react
- ring
- secrets
- speech
- typescript
- vite
- vitest
- web
Log in or sign up for Devpost to join the conversation.