Care Agent is Experity's LLM patient engagement and telehealth product, and Experity holds half of the US telemedicine market. It serves US urgent care patients: a patient talks to the agent to book or reschedule an appointment, and the product gives on-demand access to clinical documents, with every view tracked. It runs on AWS, with EMR-integrated data flows, under HIPAA.
An LLM is good at understanding what a patient wants and bad at being the only thing between a retry loop and a double booking. When the model books, a mistake becomes an appointment at the wrong hour. And in a healthcare product, the telemetry that shows where sessions break cannot carry PHI.
Since May 2026 I have been Tech Lead of the nearshore team on Care Agent, on contract. I work across the full stack of the platform: the Next.js and TypeScript web app, the Python agent orchestrator, the MCP skill servers and the serverless AWS infrastructure.
>High-level design
Care Agent runs on AWS. The Python agent orchestrator runs on AWS Bedrock AgentCore. The patient web app is in Next.js and TypeScript. The browser talks to the app through a stable route that keeps working during a deploy, and the app carries the conversation to the orchestrator. The model reads what the patient wants and writes the reply. Skills call the MCP skill servers, which talk to the clinic's scheduling backend.
The appointment lives in the clinic's system. For booking, the slot the patient taps travels as a canonical reference, the server checks it against the slots it offered, and code books the appointment, not the LLM. The asynchronous parts are telemetry and monitoring: the app and the orchestrator emit session lifecycle events with an end reason, a test keeps PHI out of every event, a fail-closed kill switch turns emission off, and a scheduled Lambda closes abandoned sessions. A canary calls the agent runtime every 5 minutes and catches outages even while the runtime is idle. The 99.99% SLO alarm and 6 more CloudWatch alarms cover critical patient paths.
I work across 8 Care Agent repositories on GitHub. I made a pre-deploy security and architecture gate the convention for every one of them.
Hover or focus a piece: it lights up with its links.
11 pieces12 links5 areas
Components
Patient web app :: Next.js and TypeScript: takes the patient in through a stable route that keeps working during a deploy, and carries the conversation to the orchestrator.
Agent orchestrator :: Python on AWS Bedrock AgentCore: the model reads intent and writes the reply, and skills keep the actions that must be exact in code.
MCP skill servers :: The agent's tool layer: they talk to the clinic's scheduling backend to fetch slots and book.
Booking in code :: The selected slot travels as a canonical reference, the server checks it against the slots it offered, and code books the appointment in the clinic's system, without the LLM.
Session telemetry :: Lifecycle events with an end reason, emitted by the app and the orchestrator, with a test that keeps PHI out and a fail-closed kill switch.
Session closer :: A scheduled Lambda on AWS that closes abandoned sessions, so the funnel counts the patients who give up.
Monitoring :: The 99.99% SLO alarm on the agent runtimes, a canary every 5 minutes and 6 more CloudWatch alarms on critical patient paths.
Repositories and deploy :: 8 repositories on GitHub, each with a security and architecture gate before deploy.
>Trade-offs
The selected slot travels as a canonical reference; the server checks it against the slots it offered, and code books it.
Alternative rejected: Letting the LLM read the selected slot and book the appointment.
Why: With booking going through the LLM, there were wrong-hour bookings and selection loops. With the reference checked on the server and code booking it, those errors ended.
A canary that calls the agent runtime every 5 minutes.
Alternative rejected: Alarming on patient traffic metrics alone.
Why: An idle runtime has no traffic, so an outage during that time would go unnoticed. The canary catches outages even while the runtime is idle.
Move client server actions to a stable route handler.
Alternative rejected: Keeping server actions as the chat transport.
Why: Next.js server action ids change on every build, and deploys broke open chats. With the stable route, chats keep working through a deploy.
>Highlights
>172 pull requests, 157 merged, across 8 repositories, from 28 May to 20 October 2026
>14 ADRs I authored and 51 PRs reviewed from 7 teammates
>99.99% availability SLO on the agent runtimes, with a canary every 5 minutes and 6 more CloudWatch alarms
>Booking in code, checked against the offered slots: wrong-hour bookings and selection loops ended
>Session telemetry with a test that keeps PHI out of every event
>A pre-deploy security and architecture gate became the convention for every Care Agent repo
>Fun facts
*My first ADR on appointment booking was superseded by another ADR of mine the next day.
*Booking took 11 PRs, from 17 June to 1 July 2026, before I found the single cause behind all of those bugs.
*The agent once answered "what time is it?" with the appointment time: with no clock in its context, the model used the only time it could see.
Care Agent at Experity | The Broad Way | Kinho.dev