Care Agent na Experity

Agente de LLM para pacientes de urgent care nos EUA

Next.jsTypeScriptPythonMCPAWS Bedrock AgentCore

>Contexto

O Care Agent é o produto de engajamento de pacientes e telessaúde com LLM da Experity, que tem metade do mercado de telemedicina dos EUA. Ele atende pacientes de urgent care nos EUA: o paciente conversa com o agente para marcar ou remarcar uma consulta, e o produto dá acesso sob demanda aos documentos clínicos, com cada visualização registrada. Roda na AWS, com fluxos de dados integrados ao EMR, sob HIPAA.

Um LLM entende bem o que o paciente quer e é ruim como a única coisa entre um loop de retry e uma consulta marcada duas vezes. Quando quem marca é o modelo, um erro vira consulta na hora errada. E num produto de saúde, a telemetria que mostra onde as sessões quebram não pode carregar PHI.

Desde maio de 2026 sou Tech Lead do time nearshore do Care Agent, por contrato. Trabalho no stack inteiro da plataforma: o app web em Next.js e TypeScript, o orquestrador do agente em Python, os servidores de skill MCP e a infraestrutura serverless na AWS.

>Arquitetura (HLD)

O Care Agent roda na AWS. O orquestrador do agente, em Python, roda no AWS Bedrock AgentCore. O app web do paciente é em Next.js e TypeScript. O navegador fala com o app por uma rota estável, que segue funcionando durante o deploy, e o app leva a conversa ao orquestrador. O modelo lê a intenção do paciente e escreve a resposta. As skills chamam os servidores de skill MCP, que falam com o backend de agendamento da clínica.

A consulta fica no sistema da clínica. Na marcação, o horário que o paciente toca viaja como uma referência canônica, o servidor confere essa referência contra os horários que ofereceu e o código marca a consulta, não o LLM. O assíncrono fica na telemetria e no monitoramento: o app e o orquestrador emitem eventos de ciclo de vida da sessão com um motivo de fim, um teste impede PHI em qualquer evento, um kill switch fail-closed desliga a emissão e uma Lambda agendada fecha as sessões abandonadas. Um canário chama o runtime do agente a cada 5 minutos e pega queda mesmo com o runtime ocioso. O alarme do SLO de 99,99% e mais 6 alarmes do CloudWatch cobrem os caminhos críticos do paciente.

Trabalho em 8 repositórios do Care Agent no GitHub. Tornei convenção em todos eles um gate de segurança e arquitetura antes do deploy.

Passe o mouse ou foque uma peça: ela acende com as ligações.

11 peças12 ligações5 áreas

Componentes

App web do paciente :: Next.js e TypeScript: recebe o paciente por uma rota estável, que segue funcionando durante o deploy, e leva a conversa ao orquestrador.
Orquestrador do agente :: Python no AWS Bedrock AgentCore: o modelo lê a intenção e escreve a resposta, e as skills fazem em código as ações que precisam ser exatas.
Servidores de skill MCP :: A camada de ferramentas do agente: falam com o backend de agendamento da clínica para buscar horários e marcar.
Marcação em código :: O horário escolhido viaja como referência canônica, o servidor confere contra os horários que ofereceu e o código marca a consulta no sistema da clínica, sem o LLM.
Telemetria de sessão :: Eventos de ciclo de vida com motivo de fim, emitidos pelo app e pelo orquestrador, com um teste que impede PHI e um kill switch fail-closed.
Fechamento de sessões :: Uma Lambda agendada na AWS que fecha as sessões abandonadas, para o funil contar quem desiste.
Monitoramento :: Alarme do SLO de 99,99% nos runtimes do agente, canário a cada 5 minutos e mais 6 alarmes do CloudWatch nos caminhos críticos do paciente.
Repositórios e deploy :: 8 repositórios no GitHub, todos com um gate de segurança e arquitetura antes do deploy.

>Trade-offs

O horário escolhido viaja como referência canônica; o servidor confere contra os horários que ofereceu e o código marca a consulta.

Alternativa descartada: Deixar o LLM ler o horário escolhido e marcar a consulta.

Por quê: Com a marcação passando pelo LLM, havia marcações em hora errada e loops de seleção. Com a referência conferida no servidor e o código marcando, esses erros acabaram.

Um canário que chama o runtime do agente a cada 5 minutos.

Alternativa descartada: Alarmar só nas métricas do tráfego de pacientes.

Por quê: Runtime ocioso não tem tráfego, e uma queda nesse período passaria em silêncio. O canário pega a queda mesmo com o runtime ocioso.

Trocar as server actions do cliente por um route handler estável.

Alternativa descartada: Manter as server actions no transporte do chat.

Por quê: Os ids das server actions do Next.js mudam a cada build, e os deploys quebravam os chats abertos. Com a rota estável, os chats seguem funcionando durante o deploy.

>Destaques

>172 pull requests, 157 mergeados, em 8 repositórios, de 28/05 a 20/10/2026
>14 ADRs de minha autoria e 51 PRs revisados de 7 colegas
>SLO de 99,99% de disponibilidade nos runtimes do agente, com canário a cada 5 minutos e mais 6 alarmes do CloudWatch
>Marcação em código, conferida contra os horários oferecidos: acabaram as marcações em hora errada e os loops de seleção
>Telemetria de sessão com um teste que impede PHI em todo evento
>Gate de segurança e arquitetura pré-deploy virou convenção em todos os repositórios do Care Agent

>Curiosidades

*Meu primeiro ADR sobre a marcação de horário foi substituído por outro ADR meu no dia seguinte.
*A marcação de horário levou 11 PRs, de 17/06 a 01/07/2026, até eu achar a causa única que gerava todos aqueles bugs.
*O agente já respondeu "que horas são?" com o horário da consulta: sem relógio no contexto, o modelo usou o único horário que via.