Care communication technology
We build personalized voice, Korean-language check-ins, and caregiver reporting with original records, used with consent and clearly labeled as AI.
MemoryThread · Care communication · In development
Familiar voices,records you can review.
MemoryThread is an AI-assisted communication service that helps people receiving care stay connected with their families and authorized caregivers. Starting from a guardian-voice TTS MVP evaluated and demonstrated in 2024, we are developing short Korean-language check-ins on a smart speaker and caregiver reporting.
Product
MemoryThread
MemoryThread is an AI-assisted communication service designed to help people receiving care stay connected with their families and authorized caregivers. It responds to growing care needs in an aging society and to how hard it is for families to check in every day.
Building on a guardian-voice TTS MVP developed with support from South Korea’s Pre-Startup Package and evaluated and demonstrated in 2024, we are developing a smart-speaker-based service for short Korean-language check-ins and caregiver reporting.
Our planned system combines conversational AI agent interactions, on-device sound-event detection, and structured reports with original conversation transcripts. Authorized caregivers can review both the AI-generated summaries and their supporting records before deciding what to do next. An optional home camera will operate through a separate, consent-based photo-sharing process without routine AI image analysis.
MemoryThread is designed to support human care and judgment, not to replace medical diagnosis or professional emergency services.
Verified track record
MVP built & evaluated (2024)- Product
- MemoryThread memorythread.app
- Scope
- Personalized TTS MVP from a guardian’s voice sample
- Program
- Pre-Startup Package (예비창업패키지), selected in 2023
- Run by
- KISED, under the Ministry of SMEs and Startups
- Outcome
- MVP developed during the program; final evaluation and demo in 2024
Features
The service we are building
Apart from the guardian-voice TTS MVP, nothing below is offered as a service yet; each item is either in development or planned. Each item shows its current status.
Smart speaker
Development goalWe plan to develop a speaker installed in the home of the person receiving care. It will hold short check-in conversations and play voice messages approved by guardians, and the user will always be able to switch the microphone off.
- Microphone & speaker
- Check-in input; AI replies and approved guardian messages
- Physical mute
- The user can stop microphone capture directly
- Status light
- Shows microphone use, active conversation, and connection
- Wi-Fi & Bluetooth
- Service connection, setup, and accessory pairing
- On-device model
- Detects predefined sound candidates on the device
- Fault logging
- Separates network failures, device errors, and no response
It is not designed as an always-recording device. While idle, it processes only the minimum signals needed on the device, and we will explain in advance when audio is sent to the server: scheduled check-ins, user requests, and permitted follow-up checks. Sending raw audio off the device would require a separate legal basis and consent.
Five feature areas
- MVP built & evaluated (2024)Development goal
Familiar Voice Messages
익숙한 목소리로 전하는 메시지
With a guardian’s explicit consent and message approval, we generate personalized TTS speech. Only messages the guardian has approved are delivered in that guardian’s voice; general AI-generated conversation uses a separate AI voice. The personalized TTS MVP completed its final evaluation and demo in 2024; separating it from AI conversation is planned for the next product.
- In development
AI Check-ins
정기적인 AI 안부 확인
We are developing Korean-language AI conversations at scheduled times or on the user’s request. They focus on everyday topics such as meals, sleep, activity, mood, and help needed, never on diagnosis or treatment instructions. The conversational AI agent is used to run the conversation and organize what was said.
- Starts at a time agreed in advance
- The user can ask for a conversation on the device
- Follow-up check after a permitted sound detection
- The user can decline or end at any time
- No response is never treated as either a problem or an all-clear
- In development
Source-backed Reporting
원본 기록을 확인할 수 있는 보고
We are building reports that pair the AI summary with the original conversation transcript and related event logs. Caregivers can check the evidence behind each summary and decide on follow-up themselves.
- Follow-up goal
On-device Sound Awareness
단말 기반 소리 감지
A lightweight model on the speaker can detect predefined sound events and try a follow-up check-in. Sound detection is not a definitive judgment of an accident or emergency and does not replace professional safety equipment.
- Follow-up goal
Optional Camera Connection
선택형 홈 카메라
We are exploring delivery of camera photos to approved recipients, based on the user’s consent and separate permission settings. Photos are not used for AI analysis by default, and capture scope and retention are set separately.
Follow-up after a sound event (follow-up goal)
The model looks for predefined types such as sounds that may be groaning, loud impacts, and alarm-like tones. Each result is treated as a sound candidate that needs checking, not as a finding that something happened.
- The device detects a predefined sound pattern
- Time and event type are logged
- The agent is called under configured conditions
- A short check-in question to the user
- Response, no response, or unclear response is logged
- Result and event log are sent to the caregiver
When immediate danger such as fire is suspected, waiting for a conversation to finish could itself be risky, so we are considering a separate alert path for high-risk events. Sound alone cannot reliably identify a fire or emergency or guarantee a response, and this feature does not replace certified detectors or emergency services.
Reports & records
AI summaries, with the original records
In developmentCaregivers should see not only a summary but also the original transcript and system events behind it. This reporting structure is in development and not yet offered as a service; the screen shown is an example built from fictional data.
- AI summary
- Daily status, key statements, things to check
- Original transcript
- AI and user turns in time order
- Event log
- Check-in start, sound detection, agent call, alerts
- Evidence links
- Each summary line linked to its statements and events
- Review & follow-up
- Whether a caregiver has read it, and optional notes
- Summaries separate what the user actually said from what the AI infers, and do not state unconfirmed facts as certain.
- The transcript is text produced by speech recognition (STT), not an audio recording. We are designing a way to flag passages where recognition is uncertain.
- If original audio is kept, it gets its own consent, retention period, and access rights, separate from the transcript.
Example screen · fictional data
Morning check-in report
Report created 09:01 · fictional user
AI summary
Original transcript (translated from Korean)
- Good morning. Have you had breakfast?
- Yes, a little porridge.
- Did you sleep well last night?
- Woke up a couple of times. My knee was aching.Low recognition confidence
- That sounds uncomfortable. Is there anything you need today?
- Tell my daughter to give me a call.
- I’ll pass that on to your caregiver.
Event log
- Scheduled check-in started
- Conversation ended · user responded
- Summary created · transcript attached
- Notified 1 authorized caregiver
Review statusNot yet reviewed
Optional camera
Optional home camera
Follow-up goalThe camera is an optional accessory, not a requirement. Its aim is to send a limited number of photos so a caregiver can see how the user is doing when everyday check-ins are difficult. We will explore it as an additional development and integration step.
Design direction
- Installed on the valid consent of the person receiving care or a lawful representative
- Location, times, frequency, and recipients agreed in advance
- Limited still photos considered before continuous video
- Photos are not sent to conversational AI APIs by default
- No automated analysis of condition, emotion, or illness in photos
- Delivered to approved recipients over a separate secure path
- Access can be changed and consent withdrawn
- Storage, delivery, and viewing of photos logged separately
We are considering end-to-end encryption so the relay server cannot view original photos; it is not implemented yet. A camera in the home can also capture family members, visitors, and care workers, so their privacy is considered separately.
Voice & consent
Principles for voice and consent
We keep clear whose voice is speaking, who wrote the words, and who consented. These principles are design requirements for the next product; consent and notice procedures will be in place before the service is offered.
Three kinds of voice
| Voice type | How it is spoken | Conditions |
|---|---|---|
| Messages written or approved by a guardian | Personalized TTS synthesized from that guardian’s voice | Explicit consent of the guardian who owns the voice, message approval, and notice that the voice is synthetic |
| Replies generated by the conversational AI agent | A separate, neutral AI voice | Notice that the reply is AI-generated, and user consent |
| Speech from the person receiving care | Speech recognition (STT) and conversation handling within the scope of consent | Only necessary information is processed, with restricted access |
- Replies generated by the AI agent are never played in a guardian’s voice as if the guardian had said them.
- The voice of the person receiving care is never cloned or used as a personalized TTS voice.
Consent and access
- A care relationship alone does not mean every record is shared. Consent is collected separately for AI conversations, report sharing, guardian voice use, camera capture, and keeping original audio.
- Age or illness alone does not transfer decision-making authority to a guardian. Where a legal representative or adult guardian is needed, we confirm the actual scope and validity of that authority.
- Government agencies and care or medical institutions do not automatically receive the access a family caregiver has; each needs a confirmed legal basis and separate approval.
- Deletion and consent withdrawal are handled according to legal obligations and the actual retention policy.
What the service does not do
- No guaranteed emergency detection or response.
- No medical diagnosis or treatment instructions, and no replacement for professional care workers.
- No replacement for certified detectors such as smoke alarms, or for emergency services.
- Final judgment and follow-up rest with authorized caregivers after reviewing the original records.
Roadmap
Where we are, and what comes next
We do not present the TTS MVP evaluated in 2024 as the same kind of achievement as the hardware and agent features we are now planning.
| Scope | Status | Notes |
|---|---|---|
| Personalized TTS from a guardian’s voice | MVP built & evaluated (2024) | MVP developed with Pre-Startup Package support; final evaluation and demo in 2024. |
| Claude via Claude Code and OpenRouter | Used in development & testing | Used for development and feature testing. Never offered as a service. |
| Direct Claude Console (API) integration | Planned for next prototype | Planned as the conversation and summary agent in the next prototype. |
| Smart speaker | Development goal | Microphone, speaker, physical mute, and status light |
| Scheduled AI check-ins and caregiver summaries | In development | Korean-language check-ins at set times or on request |
| Summaries with original transcripts | In development | Summary lines linked to statements and events |
| On-device sound detection with agent check | Follow-up goal | Follow-up check after a predefined sound candidate |
| Optional home camera | Follow-up goal | Limited photos over a separate, consented, secure path |
| Institutional connections | After legal & technical review | Phased in only after legal basis and technical requirements are confirmed. |
Team
Why we started MemoryThread
Our founder’s grandmother lives in a care home, where her health has limited family visits. Through that, we saw first-hand how little contact families and the people they care for can keep.
Our founder’s aunt works as a certified care worker and has long shared how demanding care work is on the ground.
MemoryThread starts from both sides: families who cannot always be there, and care workers who are stretched thin.
- Founder
- Founder & CEO
- Background
- Statistics, data, and mathematics
How we prepared
- University, years 1–4
Learned to develop and refine ideas over four years in a university startup club supported by KISED under the Ministry of SMEs and Startups.
- University, years 1–3
In a patent strategy competition supported by the Korean Intellectual Property Office and a local government: eliminated in the preliminaries in year one, Excellence Award in year two, Grand Prize in year three. Also joined projects run with a patent firm.
- During university
Selected for a Ministry of SMEs and Startups startup internship program and learned how a startup runs by working inside one.
- 2023
Selected for the Pre-Startup Package, began building the personalized TTS MVP, and founded AI VoiceMatch Service (에이아이보이스매치서비스) in June 2023.
- 2024
Completed the final evaluation and demo of the personalized TTS MVP built with Pre-Startup Package support.
Technology
What we build
Developer Systems
We build the systems that let AI agents and developer tools work with files, processes, models, and execution environments.
We build applications and the systems behind them.
- 01
Explore
We implement and validate real problems and new ideas.
- 02
Engineer
We design boundaries for execution, recovery, validation, and operation, beyond the prototype.
- 03
Evolve
We develop validated work into an independent product or a reusable system.
Open source
Open development
Building MemoryThread depends on software foundations: connecting to AI models, a workspace for development, and control over the resources that work uses. We build these ourselves and publish the general-purpose parts as open source.
Open-source foundation
Agent Response Gateway
Extensible gateway software that maps different model APIs onto a shared Responses-style interface. Applications keep tool execution, approval, and conversation history.
In our workA common layer for connecting our services to different AI model APIs.
Open-source foundation
CodeSpace
A workspace and execution layer that lets a coding agent inspect files, apply changes, and run commands. The agent plans the work. This project checks permissions and keeps execution state. It does not call a model or run an agent loop.
In our workThe workspace where coding agents help build our software, with permission checks on every change and command.
Open-source foundation
DevGuard
Foundation software for resource admission and execution policy on development workloads. The public work so far is the contract and authority core. It does not yet install a daemon, launch commands, or control operating-system resources.
In our workGroundwork for running our development workloads under clear resource policies.
Company
Company
AI VoiceMatch Service (에이아이보이스매치서비스) is a software business founded in June 2023 as a sole proprietorship in Pyeongtaek, South Korea. We build MemoryThread (memorythread.app), a smart-speaker-based AI care communication service, along with the applied software and developer tools around it.
- Company
- AI VoiceMatch Service (에이아이보이스매치서비스)
- Product
- MemoryThread memorythread.app
- Operated by
- 에이아이보이스매치서비스(AI VoiceMatch Service)
- Business
- SaaS and software development
- Focus
- Care communication technology
- Applied software
- Developer tools
- Location
- Pyeongtaek, South Korea
- Contact
- service@memorythread.app
Contact
Interested in what we’re building?
Questions about our technology or a possible collaboration can be sent by email.