Inspiration
Millions of adult children manage a parent's medications from a different city. The parent sees multiple doctors who rarely coordinate with each other, and the adult child usually finds out about a missed dose or an overdue refill only after something has already gone wrong. This isn't rare, it's the default state for a lot of families managing elderly care remotely, especially across India where families are increasingly split across cities.
The Agents for Humans brief asked for an agent that runs quietly in the background and only surfaces when there's a real decision to make. That framing matched the problem exactly, so I built CareCue to fit it.
What it does
CareCue is a Strands-powered agent that manages an elderly parent's medications end to end, not just tracking them.
- A refill tracker flags medications that are overdue or due soon, based on each prescription's own refill cycle.
- A conflict checker cross-references prescriptions across different doctors, catching the same generic drug prescribed under two brand names, or two medications from the same therapeutic class prescribed by specialists who never spoke to each other. This runs against a curated drug class reference cross-checked against WHO ATC classification and NIH RxClass, scoped to medications common in Indian elderly care.
- A dose adherence checker looks at a rolling 30-day window and flags concerning patterns like consecutive missed doses.
- A refill drafter takes the safe, unambiguous action on its own, drafting a refill request when nothing needs a judgment call.
- A notifier sends the caregiver one consolidated email when something actually needs attention, not a separate alert for every small thing.
- A dose reminder sender messages the patient directly on Telegram at each scheduled dose time. The patient just replies YES or NO. No app, no login, nothing new to learn.
If a patient doesn't respond to a reminder within a set window, CareCue escalates quietly to the caregiver instead of staying silent. The agent keeps state across runs, so it never re-alerts on something it already flagged.
How I built it
The core is a single Strands agent orchestrating six tools, backed by a SQLite data layer with a repository pattern, a FastAPI backend, and a vanilla JS frontend. Locally the agent runs on an OpenRouter-hosted model; I also deployed the same agent to Amazon Bedrock AgentCore Runtime on Claude Haiku, with zero changes to the tool logic itself, just a thin entrypoint wrapper.
For patient-side dose confirmation, I initially built this on Twilio's WhatsApp Sandbox, but the per-recipient opt-in requirement and sandbox limitations made it a poor fit for something meant to look production-real. I switched to the Telegram Bot API instead: no approval queue, no sandbox ceremony, real inbound and outbound messaging from day one.
Challenges I ran into
The most instructive bug wasn't in the tool logic, it was in how the agent talked about its own actions. After deploying to AgentCore on Claude Haiku, the daily check summary would sometimes claim an alert email had failed, with a specific, plausible-sounding reason, even though the email had actually arrived. The tool itself returned a clean success. The model was generating a failure explanation that had no basis in what actually happened.
I tried fixing it with stricter system prompt instructions telling the agent to only report what the tools returned. That helped, but the hallucination came back later with different wording. That was the real signal: a prompt is a suggestion, not a guarantee, especially for a smaller, faster model narrating a real-world side effect freely in prose.
The actual fix was architectural. I stopped letting the LLM generate the alert-delivery status at all. The agent still writes its own summary of the clinical findings, since that's genuinely its job. But the line reporting whether an email or Telegram message actually sent is now built directly from the real tool result in code, not from the model's imagination.
What I learned
For anything where an agent is reporting on a real-world side effect, especially in a caregiving context where a false "it's handled" could matter, the safest design is to let the agent reason and decide, but never let it be the one making claims about what actually happened. Deterministic code should own that report, not free-text generation.
I also learned that "production-ready" and "hackathon-ready" aren't the same target, and chasing the former for every feature (like a fully approved WhatsApp Business number) can cost you more than it's worth against a fixed deadline. Naming a limitation clearly is often a stronger signal of engineering judgment than quietly working around it.
What's next
Expanding the drug class reference further, exploring a real drug interaction API integration, and pursuing WhatsApp Business approval for production-realistic patient messaging in India.
Built With
- aws-agentcore
- aws-bedrock
- css
- fastapi
- html
- javascript
- openrouter
- python
- sqlite
- strands-agents
- telegram-bot-api
Log in or sign up for Devpost to join the conversation.