Natera usa Amazon Bedrock AgentCore para cortar tempo de resposta de laboratório de 17 horas para 8 minutos

A Natera é uma empresa de genômica conhecida pelos testes de DNA livre de células (cfDNA), usados em diagnóstico pré-natal e oncológico. Manter os instrumentos de laboratório funcionando é crítico: cada parada de equipamento atrasa o processamento de amostras e, no fim da cadeia, o laudo do paciente. Em um caso publicado no AWS Machine Learning Blog, a equipe de engenharia de laboratório da Natera, liderada por Ariel Jirau, descreve como construiu o SWARM (Systematic Workflow Analytics and Resolutions Manager) sobre o Amazon Bedrock AgentCore para resolver esse problema.

O texto interessa a quem já opera (ou está prestes a operar) agentes do Bedrock em produção, porque o material não é um anúncio de produto: é um desenho de arquitetura testado ao longo de um período de avaliação de 90 dias, com números de acurácia, confiança e cobertura por família de instrumento.

O problema

A infraestrutura de laboratório da Natera cobre várias famílias de instrumentos de precisão, cada uma com seus próprios modos de falha, manuais de fornecedor e padrões de resolução. O time de engenharia de serviço que cuida dessa infraestrutura era organizado em torno de expertise individual profunda, não de playbooks padronizados. Quando um técnico sênior que passou anos diagnosticando uma família específica de equipamento saiu da empresa, o conhecimento institucional que ele carregava simplesmente se perdeu: não havia sistema para capturar, organizar ou redistribuir essa expertise em escala.

O volume não ajudava. Eram mais de 65 tickets por dia distribuídos em três filas do Jira, com tempo médio de primeira resposta de 17,4 horas. Contratar mais engenheiros não escalava na mesma velocidade da demanda, e cada hora de atraso num diagnóstico significava instrumento parado e amostra represada. O SWARM precisava responder em minutos, cobrir um leque amplo de equipamentos e melhorar continuamente por um loop de avaliação estruturado, não apenas no dia do deploy.

A arquitetura

O fluxo do SWARM, do ticket no Jira até o relatório de diagnóstico na mão do engenheiro, segue este caminho:

1. Um ticket é criado em uma das três filas do Jira; um AWS Lambda em polling, agendado pelo Amazon EventBridge Scheduler, detecta o ticket sem depender de configuração de webhook.
2. O ticket verificado entra em uma fila do Amazon SQS, o que desacopla a execução do agente da disponibilidade do próprio Jira.
3. O Amazon DynamoDB deduplica usando o ID do ticket como chave de partição, com expiração por TTL, e guarda metadados de cada execução (status, custo, consumo de tokens) que alimentam o loop de avaliação.
4. O swarm-agent, rodando no AgentCore Runtime, seleciona a skill apropriada a partir do tipo de equipamento e dos sintomas relatados.
5. O agente consulta a base de conhecimento (Amazon Bedrock Knowledge Bases, com vetores gerados pelo Amazon Titan Text Embeddings) construída a partir de manuais de fornecedor, histórico de tickets e dados operacionais.
6. O swarm-agent gera um relatório HTML estruturado, com hipótese de causa principal, passos de troubleshooting ranqueados e um rótulo de confiança; o relatório vai para o Amazon S3 e é vinculado ao ticket do Jira em minutos.
7. Se o engenheiro precisa ir além do relatório automático, ele abre o swarm-hive: interage em tempo real, envia imagens e explora caminhos alternativos. Entradas livres passam pelo Amazon Bedrock Guardrails antes de chegar ao modelo, e o AgentCore Memory mantém o contexto da conversa por engenheiro entre sessões.
8. Cada invocação é rastreada pelo AWS X-Ray, com tempo e custo por chamada de ferramenta, logada no Amazon CloudWatch, e falhas disparam alerta por Amazon SNS e por um tracker no Slack.
9. O engenheiro registra o que encontrou e corrigiu; um avaliador classifica a resposta como Accurate, Partial ou Wrong por família de instrumento, e o resultado retroalimenta a base de conhecimento.

Em resumo: são dois runtimes compartilhando uma única biblioteca de skills, um otimizado para throughput em segundo plano (swarm-agent) e outro para profundidade interativa (swarm-hive). "O sistema não substitui os engenheiros, ele dá a eles acesso a toda a profundidade do conhecimento institucional no momento em que o ticket chega", disse Jirau.

Os serviços envolvidos

A integração com GitLab CI usa OpenID Connect: os runners apresentam um token OIDC a um identity provider do IAM, e o AWS STS troca esse token por credenciais de curta duração restritas ao papel de deploy. Um trecho da política de confiança do IAM, segundo a Natera, segue este formato:

{
 "Version": "2012-10-17",
 "Statement": [{
 "Effect": "Allow",
 "Principal": {"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/gitlab.com"},
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {"StringEquals": {"gitlab.com:sub": "project_path:YOUR_PROJECT:ref_type:branch:ref:main"}}
 }]
}

Não há chave de acesso de longa duração em lugar nenhum do pipeline.

Trade-offs

O primeiro trade-off é de segurança: a Natera optou por um modelo de deploy sem chaves fixas (OIDC + STS gerando credenciais temporárias por deploy), IAM com privilégio mínimo por componente, VPC com subnets privadas e endpoints, e rotação automática de segredos a cada 30 dias no Secrets Manager. Isso custa esforço de configuração inicial maior do que usar access keys estáticas, mas é obrigatório num ambiente clínico sob BAA de HIPAA, onde nenhuma informação identificável de paciente toca o índice vetorial ou o modelo (os tickets carregam só metadados de equipamento e fluxo).

O segundo trade-off é de excelência operacional: embutir lógica direto no prompt do agente é mais rápido de prototipar, mas a Natera escolheu construir uma biblioteca de skills versionada e tratada como software de produção, auditável e testável individualmente. "Quando um diagnóstico está errado, precisamos apontar para uma skill específica, não debugar o sistema inteiro", disse Jirau sobre a decisão. A biblioteca reúne 33 skills, 24 específicas de instrumento e 9 transversais de workflow, com uma divisão clara: Python para tarefas determinísticas (parsing de campos do Jira, formatação de HTML) e skills de LLM para raciocínio sobre sintomas e documentação de fornecedor.

O terceiro trade-off é de confiabilidade: o padrão EventBridge-para-SQS desacopla o runtime do agente da disponibilidade do próprio Jira, ao custo de uma camada extra de infraestrutura e de uma deduplicação explícita via DynamoDB com TTL.

O quarto trade-off é de eficiência de desempenho: separar swarm-agent (processamento em lote, assíncrono) de swarm-hive (interação em tempo real) evita que os requisitos de latência de um puxem a arquitetura do outro para baixo, mas dobra a superfície de deploy e observabilidade.

Vale registrar uma limitação que a própria Natera assume nos números: os tickets com confiança Moderate e Low hoje empatam em 65% de acurácia (78 e 37 casos avaliados, respectivamente), contra 74% nos de confiança High (154 casos). A amostra de 37 casos Low é pequena demais para conclusão estatística, e a equipe espera que os dois níveis se separem conforme o conjunto de avaliação cresce. Isso é um lembrete prático de confiabilidade: rótulo de confiança de um agente autorregulado precisa de amostra grande antes de virar sinal operacional confiável.

Custo estimado

A Natera não publica valor em dólares por ticket, por token ou por mês de operação do SWARM. O que o material deixa claro é a estrutura de custo que o time rastreia internamente: o AWS X-Ray grava tempo e custo por chamada de ferramenta, e o DynamoDB guarda, por execução, o consumo de tokens e o custo associado, exatamente para permitir essa análise sem adivinhação.

Os componentes que geram custo variável são: chamadas ao Amazon Titan Text Embeddings para indexar documentos em lotes de 100 (tamanho escolhido para equilibrar throughput de indexação contra limites de taxa da API), chamadas de inferência ao modelo via Bedrock a cada diagnóstico gerado, e o consumo do AgentCore Runtime, que é cobrado por uso. DynamoDB, SQS e Lambda, nesse desenho, tendem a ficar na faixa de custo baixo e previsível de workloads serverless de baixo volume (65 tickets por dia é um volume modesto para esses serviços).

Para quem quer estimar antes de construir algo parecido, o caminho é pegar o preço por milhão de tokens do modelo Bedrock escolhido, multiplicar pelo volume esperado de diagnósticos e somar o custo de embeddings do volume de documentos da própria base de conhecimento. A fonte cita que Amazon Bedrock, Amazon Titan Text Embeddings e Amazon Bedrock AgentCore estão disponíveis em múltiplas regiões, mas não confirma cobertura em São Paulo (sa-east-1): antes de replicar esse desenho por aqui, vale checar as páginas de regiões suportadas do Bedrock e do AgentCore.

Como adaptar

Três decisões da Natera valem a pena copiar em outro domínio de operações, mesmo fora de laboratório clínico.

Tratar chunk_size e chunk_overlap como parâmetros ajustáveis, não como configuração padrão fixa. A Natera usa o tokenizador tiktoken com o encoding cl100k_base para medir limites de chunk:

# Configuração de chunking de documentos
chunk_size = 1000 # tokens
chunk_overlap = 150 # tokens
encoding = tiktoken.get_encoding("cl100k_base")
batch_size = 100 # documentos por chamada de embedding

"Acurácia diagnóstica é, antes de tudo, um problema de qualidade de dado", disse Jirau. "Adicionar os manuais de fornecedor que faltavam para a família de instrumento com pior pontuação elevou a acurácia de 71% para 75%, sem nenhuma mudança de modelo." A lição prática: quando a acurácia estaciona, checar cobertura de dado antes de mexer em modelo, porque lacuna de documentação de fornecedor é a causa mais comum de diagnóstico perdido.

Construir rastreabilidade na biblioteca de skills desde o início, em vez de deixar lógica solta em prompt. Isso é o que permite apontar para uma skill específica quando um diagnóstico sai errado, em vez de depurar o sistema inteiro. Para deduplicação de eventos, o esquema do DynamoDB da Natera é minimalista:

dynamodb.create_table(
 TableName='swarm-deduplication',
 KeySchema=[{'AttributeName': 'ticket_id', 'KeyType': 'HASH'}],
 AttributeDefinitions=[{'AttributeName': 'ticket_id', 'AttributeType': 'S'}],
 TimeToLiveSpecification={'Enabled': True, 'AttributeName': 'ttl'}
)

Se a carga de trabalho mistura processamento em lote com consulta interativa, separar em runtimes distintos desde o começo, em vez de tentar fazer um único agente atender aos dois perfis de latência. Para quem quer reproduzir o padrão, a Natera aponta o repositório de exemplos do AgentCore, o guia "Building Agentic systems on AWS" e o "Getting Started with Amazon Bedrock AgentCore" como pontos de partida para deploy seguro em escala.

O resultado que a Natera mediu em 524 tickets avaliados ao longo de 90 dias de produção: tempo médio de primeira resposta caiu de 17,4 horas para cerca de 8 minutos (cerca de 130 vezes mais rápido), com 96,2% dos tickets recebendo resposta automática antes de qualquer engenheiro iniciar o diagnóstico manualmente. Desses 524, 269 tinham rótulo de confiança e resolução verificada por engenheiro disponível para comparação, base sobre a qual os números de acurácia por nível de confiança foram calculados.

Fonte: AWS Machine Learning Blog