Inspiration
Clinical trials don't usually fail because the science is wrong. They stall because of people logistics. Participants miss visits, stop filling in diaries, and quietly drop out. Side effects often surface only at the next site visit, days or weeks after they started. Clinical research coordinators spend hours on reminder calls, rescheduling, and chasing missing data instead of caring for participants.
Meanwhile, the participants are already on WhatsApp every day, and study staff live in their inbox. We asked: what if one agent sat between those two channels, so participants never had to install a new app and staff never had to open a new dashboard?
That question became TrialTalk.
What it does
TrialTalk is an AI agent that runs participant communication for a clinical trial:
- Participants talk to it on WhatsApp, using buttons, list menus, photos, location pins, and their own language.
- Study staff receive and act on its reports by email, through structured reports, daily digests, and replies the agent can parse and carry out.
It covers the full participant journey: recruitment and pre-screening, consent-form Q&A (it never takes consent), visit reminders that only offer reschedules inside the protocol window, daily symptom diaries, medication adherence, dropout-risk check-ins, and site/sponsor reporting.
The centerpiece is the adverse event loop:
- Maria reports a rash near her injection site during her daily WhatsApp check-in.
- The agent asks follow-up questions, collects a photo, gives emergency guidance, and emails the PI and coordinator a structured adverse event report.
- The PI simply replies to the email: "Apply hydrocortisone, come in Thursday."
- Amazon SES receives the reply, the agent parses it, relays the instruction to Maria on WhatsApp, and books Thursday's visit.
An email reply drives a WhatsApp action, and the PI never leaves their inbox.
How we built it
TrialTalk is one Amazon Bedrock AgentCore agent connecting two channels, built serverless and event-driven:
| Layer | Service | Role |
|---|---|---|
| Participant channel | AWS End User Messaging Social | Two-way WhatsApp: buttons, lists, media, templates |
| Staff channel | Amazon SES | Outbound reports and digests, inbound reply parsing |
| Agent | Bedrock AgentCore Runtime + Memory | Triage, scheduling, escalation; resumes each conversation where it left off |
| Grounding | Bedrock Knowledge Base | Answers grounded in the protocol and consent form |
| Tools | AWS Lambda | Scheduling, alerts, pharmacy notices |
| State | Amazon DynamoDB | Participants and an append-only audit log |
| Timing | Amazon EventBridge | 72h/24h visit reminders, daily check-ins, digests |
Scheduling inside the protocol window. Every visit has a target day $d^*$ and an allowed window $\pm w$. The reschedule tool only offers slots $d$ that satisfy
$$ |d - d^*| \le w $$
and anything outside that range becomes an email to the coordinator instead of a WhatsApp option.
Dropout-risk score. The agent tracks engagement signals for each participant $i$: reply latency $\Delta t_i$, missed diaries $m_i$, and repeated reschedules $s_i$. These are combined into a risk score
$$ r_i = \sigma!\left(\beta_0 + \beta_1 \Delta t_i + \beta_2 m_i + \beta_3 s_i\right), \qquad \sigma(x) = \frac{1}{1 + e^{-x}} $$
When $r_i$ crosses a threshold, the participant gets a gentle check-in on WhatsApp and the coordinator gets an email naming the participant and the likely reason.
Alert matrix. Every trigger has a defined channel and a human owner. Urgent keywords (chest pain, breathing trouble, hospitalization) produce immediate 911 guidance to the participant and an immediate PI email. A possible adverse event produces a structured report to the coordinator and PI. A serious adverse event produces a draft sponsor notice that is sent only after PI approval. Nothing the agent hears is left without a person responsible for it.
Challenges we ran into
- Turning free-form email into safe actions. PIs don't write in a fixed format. Parsing "Apply hydrocortisone, come in Thursday" into a relayed instruction plus a booked visit, without inventing anything clinical, meant constraining the agent to relay the PI's words and only execute actions it could match to a known tool.
- WhatsApp's messaging rules. Business-initiated messages outside the customer-service window must use pre-approved templates. We had to design reminders and check-ins as templates up front, with free-form conversation only after the participant replies.
- Drawing the line on medical advice. The agent must be helpful without becoming a clinician. We limited responses to protocol-approved content and routed anything clinical to the PI, while still giving clear emergency guidance for urgent symptoms.
- Protecting health information across two channels. We split the data deliberately: WhatsApp messages use participant IDs and avoid diagnoses, while detailed reports travel by email to staff.
- Auditability. Every message, classification, and escalation is written to an audit log, with FDA 21 CFR Part 11 expectations for electronic records in mind.
What we learned
- The best interface is the one people already use. Meeting participants on WhatsApp and staff in email removed more friction than any new dashboard could.
- Agents need human owners. Designing the alert matrix first, before writing prompts, made the system safer and easier to reason about.
- Grounding matters more than fluency. For consent questions, citing the exact section of the consent form built more trust than a polished but unsourced answer.
- Email is an underrated agent interface. It's asynchronous, auditable, and already approved at every trial site, and it turned out to be a natural command channel.
Responsible use
The demo uses a fictional trial and synthetic participants. In production, every participant-facing template and email would be reviewed by the ethics board (IRB), participants opt in to WhatsApp contact at enrollment and can opt out at any time, and each AWS service would be confirmed against AWS's HIPAA-eligible services list.
What's next
- Piloting with a real site under IRB review
- Calibrating the dropout-risk weights $\beta$ on real (de-identified) engagement data
- Expanding multilingual support to widen enrollment diversity
- Adding sponsor-facing analytics on which consent sections cause the most confusion
Built With
- agentic
- ai
- javascript
- python
- react
