TrustKaki

AI-powered check-ins through familiar messaging apps help care teams spot changes in seniors’ wellbeing, remember personal context, and prioritise human follow-up.

Comment

Inspiration: small changes are easy to miss

“My knee hurts.”

“Not hungry today.”

“Don’t feel like going downstairs.”

Individually, these messages may seem ordinary. Across several days, they may suggest that someone needs a check-in.

As Singapore’s population ages, care organisations face a growing challenge: maintaining personal, consistent contact with seniors while managing limited staff time. Important context can become scattered across conversations and staff handovers.

I built TrustKaki for Active Ageing Centres (AACs): a system that turns everyday senior conversations into clearer, evidence-backed human follow-up.

What TrustKaki does

Senior messages → contextual understanding → patterns across days → care-team follow-up.

Seniors interact through familiar messaging channels. Staff use a care workspace that answers three questions:

  1. Who needs attention?
  2. What changed, and what evidence supports it?
  3. What should a human do next?

Follow one senior’s journey

Mr Tan mentions knee discomfort and skipping breakfast. TrustKaki interprets the message as care-related observations and responds using relevant personal context.

If he prefers quiet, one-to-one conversations, retrieved memory can help the response suggest a suitable form of support instead of a generic group activity.

Later observations, such as avoiding downstairs trips, missing meals or withdrawing from usual activities can contribute to a pattern across days. Staff receive a surfaced case with the supporting timeline and a suggested follow-up, such as calling to ask whether discomfort is affecting meals and movement.

The staff member decides what to do and records the outcome. TrustKaki supports that decision, it does not diagnose the senior.

Help with everyday risks, too

An outdoor plan can trigger a weather and air-quality check without the senior explicitly asking about the weather. Advice uses available data.gov.sg/NEA readings and respects their freshness and geographic limits.

A suspicious payment request can trigger the Digital Safety specialist, which encourages verification before transferring money or sharing information.

The environmental feature had a personal inspiration: haze made me think that before encouraging a senior to head outside, we should check the air first.

How the AI works

TrustKaki gives different components distinct responsibilities:

  • Triage: interprets the current message and proposes care or safety signals.
  • Personal-memory retrieval: supplies relevant saved facts and preferences for the selected senior.
  • Specialist routing: Jev selects relevant specialist work, such as digital safety or outdoor context.
  • Application policy: validates outputs and controls safety decisions and permitted actions.
  • Pattern detection: checks saved observations across days for supported combinations.
  • Care briefing: summarises the evidence and suggests a practical human follow-up.

Conversation history helps the system understand “there” or “okay, thanks.” Personal memory supplies longer-lived preferences. Care records retain observations and staff actions. These serve different purposes and are handled separately.

In the judge workspace, reviewers can send fictional messages and inspect the retrieved memory, specialist execution, policy result and save outcome. This makes the system’s behaviour visible beyond the final reply.

Technology choices and why

Next.js, TypeScript and Vercel

Next.js provides the web interface and server-side endpoints in one application. TypeScript helps keep the structured data passed between components consistent. Vercel hosts the deployed application and connects releases to GitHub.

OpenAI models: understanding everyday language

Seniors should not need to phrase messages as forms or commands. OpenAI models interpret informal language and prepare contextual responses and care briefings.

Model outputs are validated before they influence system actions. Language understanding remains flexible while application policy retains control.

Jev: selecting relevant specialist work

Jev helps decide which specialist is relevant to the current message, rather than invoking every specialist for every conversation.

Its role is routing, it will not be replacing the conversational model or determining final safety policy. This makes specialist selection a separate, inspectable step. Routing benefits depend on the workload, I do not have suffiecient evidence to claim a universal speed or accuracy advantage over a general-purpose LLM.

Supabase: authentication and care records

Supabase supports authenticated staff access and persistent care data, including senior profiles, observations and follow-up records.

This lets the prototype support multiple seniors and authorised care-team users, with retained history beyond an individual chat session.

Neon: relevant personal memory

Neon supports the personal-memory retrieval layer. Relevant stored preferences can be supplied to the AI instead of expecting it to remember everything from a long conversation.

Separating personal memory from care records also makes their different roles explicit: a conversational preference is not the same thing as an authoritative care observation.

Telegram, WhatsApp and data.gov.sg/NEA

Messaging adapters connect senior conversations to the shared processing flow. Telegram is demonstrated in the product video; the WhatsApp integration is implemented, with live availability dependent on external business verification.

Official environmental data grounds outdoor advice in external readings rather than the model’s general knowledge. Current readings are not presented as guarantees about future conditions.

Safety is part of the workflow

A care system needs more than a reassuring tone.

  • Human oversight: surfaced cases support staff review, not automated diagnosis.
  • Validated memory: candidate memories pass checks before storage; saying “I’ll remember” is not proof of a successful save.
  • Prompt boundaries: messages and retrieved text are context, not authority to override system instructions.
  • Grounded advice: weather and air-quality responses are bounded by available location, freshness and forecast coverage.
  • Access control: live AI testing requires authentication; the public walkthrough uses fictional browser-only state.
  • Inspectable outcomes: the judge workspace shows what was retrieved, executed and saved.

The demonstration uses fictional senior profiles and care records.

Challenges and what I learned

The hardest part was making a multi-component system behave like one coherent conversation.

Early tests exposed lost messaging history, repeated environmental advice and responses that sounded like system notices. I revised history handling, current-message routing and response safeguards, then checked the specific failure scenarios.

I learned that testing individual prompts is insufficient. A system must also handle acknowledgements, corrections, changing plans and follow-up questions without losing context or repeatedly invoking the same specialist.

I also learned to distinguish a convincing reply from a correct system outcome: retrieval, validation, persistence and human follow-up each need their own evidence.

What I’m proud of

TrustKaki brings together what I learned at AI Lodge: AI agents, system prompt design and retrieval-augmented generation (RAG) in a working system for senior care coordination.

I applied those lessons to give agents clear responsibilities, design prompts with safety boundaries, and retrieve relevant personal context for more thoughtful replies.

I also independently explored Neon, a PostgreSQL platform I had not used before, and learned how to use it with pgvector to support personal-memory retrieval.

I’m proud of connecting these pieces into a workflow that helps care teams understand changes and make informed follow-ups.

What’s next

A supervised AAC pilot would evaluate:

  • Accuracy and usefulness of surfaced cases.
  • Relevance of retrieved personal context.
  • Staff review time and time to human response.
  • Missed concerns, unnecessary alerts and completed follow-ups.

Scheduled Telegram outreach requires an authorised recurring worker invocation. WhatsApp live delivery remains dependent on external business verification.

The repository contains architecture diagrams, prompt-design explanations, setup instructions and validation details for reviewers who want to explore further.

Built With

Share this project:

Updates

Submission history