Inspiration
We build Flo, care software that's already live in extra care, supported living and sheltered housing, used by councils and care providers. It's a real product, not a hackathon prototype. Our other entry, FloRing, uses Ring to spot when something's wrong, or more often when something ordinary hasn't happened: no one's been seen in the kitchen by mid-morning. FloCompanion is the other half of that. Not safety, but company.
What we kept coming back to is that most voice skills have no memory of you. You ask, they answer, and next time it's like you've never met. For someone living on their own, that's a bit bleak. What makes something feel like a companion isn't clever answers, it's that it remembers: that you watched a film this morning, that you slept badly, that you used to bake. And that it starts the conversation with that, instead of waiting to be told what to do.
Memory across sessions is what an Alexa+ add-on is for, so the brief and the product lined up.
Why it matters
Loneliness is one of the biggest health problems older people face. The WHO estimates that about 1 in 6 people worldwide feel lonely, and links it to 871,000 deaths a year (WHO Commission on Social Connection, June 2025). In the UK, around 940,000 people over 65 are often lonely (Age UK, December 2024).
We have seen what a voice on the side table can do. In an independent evaluation by Newcastle University of Flo in Durham's Extra Care schemes, over 80% of residents said the quality of their care had improved, and many described their Alexa simply as "company". FloCompanion builds on that: not just answering when asked, but remembering the person and picking up where they left off.
Who it's for
Flo is already live in extra care, supported living and sheltered housing with councils and care providers, so the people in this demo are composites of residents we build for every day rather than a guess at a user. That is where FloCompanion goes first: an Echo already on the side table in a scheme, with the conversation summary landing in the care record a carer is reading anyway.
But the problem is not confined to care settings. Most older people living alone are not in a scheme and never will be, and the daughter who rings on a Sunday wanting to know how the week has been is describing the same need. Everything here runs on a self-hosted MCP server, synthetic data and one environment variable for the model, so the same companion that serves a housing provider serves a single household with a smart speaker and no care package at all. Alexa+ is designed to call servers like this directly, which is the route from a product we run for councils to one that works in any home.
What it does
It's a companion on a resident's Echo. When a resident opens it, it starts the conversation for them, drawn from the time of day, any overnight movement, and what they did earlier. It talks back and forth reminiscence, their day, a gentle quiz and it remembers across sessions, so the next day it can pick up where you left off:
Session 1 resident shares a memory about their Sunday scones
Session 2 (a new day, a new session)
Flo opens: "Good morning. I hope you got back off after being up
around two - how was the film this morning?"
later: "Last time you told me about your Sunday scones,
the ones your granddaughter loved…"
Each conversation also leaves a short summary in Flo, so carers and family can see what a resident has been talking about and pick it up with them.
Everyone in the demo is invented. There's no real care data anywhere in it.
How we built it
Two parts.
The deliverable the track asks for is a self-hosted MCP server (spec 2025-11-25, over Streamable HTTP) that holds the resident's context and their memory and exposes them as tools. The other part is a normal Alexa skill whose Lambda is a real MCP client, calling that server on every turn.
Alexa+ is designed to call MCP servers like this directly; here a skill acts as that client. The MCP server is the real, runnable thing; the skill shows it working on an actual Echo. The conversation is generated by Amazon Bedrock we run Claude, with Nova as a fallback, and switching is one environment variable. Memory sits in DynamoDB behind the server, and everything runs on Lambda behind an IAM-gated Function URL, so the endpoint is never public.
Challenges we ran into
Honestly, getting it to talk like a companion was much harder than any of the infrastructure. The plumbing problems had answers. The conversation took round after round of listening to it and fixing what sounded wrong.
The first version was too transactional: a fixed "hello, would you like your day, a memory, or a quiz?" every time. That's a menu, not a companion. Moving to an opening built from context helped, but the back-and-forth kept failing in ways that were obvious the moment you heard them:
- Reminiscence went generic and dead-ended. Ask for a happy memory, get a lovely one back, reply "that sounds lovely", silence. At one point a resident asked it something - "what was that food I used to make?" - and it said "that sounds delicious." It answered a question with a non-answer. We reworked the prompts so it latches onto the specific thing the person said, and if they ask it something, it answers before carrying on.
- The opening chat would sometimes just quit to the menu. Someone would say "I missed the film, what else is on today?" and instead of answering, the conversation ended. That was a proper trap: the newer Claude model reasons before it replies by default, and on a short turn that hidden reasoning ate the whole token budget, so nothing came back, and the skill read the empty reply as "nothing more to say." Turning thinking off for these short turns fixed it, and we started giving the model the rest of the day so it could actually answer "what's on."
- Voice has a rule we kept relearning: the mic stays open after it speaks, so every line has to end with something the person can clearly answer. End on a flat statement and they're left unsure whose turn it is. A fair chunk of the prompt work was making sure it always leaves the door open without sounding like an interrogation.
The infrastructure was more straightforward, just fiddly. The MCP Node transport returned empty bodies on Lambda behind serverless-http (we swapped to the web-standard transport). SigV4 signing quietly dropped our lowercase content-type and the server bounced the request. The AWS account we built in blocks public Lambda URLs, API Gateway, and the inline IAM the one-command Alexa deploy wants, so we landed on an IAM-gated Function URL with SigV4, which is tighter anyway. And Bedrock's Claude models sit behind an approval form that, until you complete it, fails with an error that looks like the model doesn't exist. It's all in the friction log.
What we're proud of
That the memory genuinely works, end to end, on a real device: tell it something, come back in a new session, and it remembers that specific thing. And that none of it is faked the MCP server is real and a judge can run it themselves.
What we learned
Most of this product isn't in the code, it's in the prompts and the flow, and the only way to get it right was to keep listening and adjusting. We also found that putting everything behind MCP tools was the right call: the skill never had to know whether the data was made up or live, and we could change the model with one setting.
What's next
- Connect it to the real Flo platform (gated, with consent) so it knows a resident's actual day.
- Let the Ring events from our other entry run through the same memory, so "you were up at three" is real sensing.
- Proper reminders, so it can actually offer them.
- Deeper reminiscence drawn from a person's life story.
Built With
- alexa-skills-kit
- amazon-apl
- amazon-bedrock
- amazon-dynamodb
- amazon-nova
- anthropic-claude
- ask-cli
- aws-iam
- aws-lambda
- aws-sdk-for-javascript
- model-context-protocol
- node.js
- sigv4
- streamable-http
- typescript
Log in or sign up for Devpost to join the conversation.