A primeira decisão de arquitetura num agente para análise de pedidos não é qual LLM usar. É onde ele não pode rodar, e o que ele não pode tocar sem deixar trilha.
Essa inversão de premissa virou consenso técnico nas últimas semanas. Em 13 de maio, a Anthropic publicou o guia oficial de Claude Managed Agents executados em sandbox controlado pelo cliente, conectados a servidores MCP privados. O blueprint não é só desenho academico. É o que falta no piloto da maioria das operadoras que estão testando copiloto de análise de pedidos.
Para tornar concreto. O líder de plataforma de uma operadora abriu o Slack numa quinta de tarde, em conversa recente, e mandou uma pergunta simples para o time de IA. "Se o agente recusasse um procedimento por engano e o beneficiário judicializasse, vocês conseguem mostrar, comando por comando, o que ele leu antes de decidir?". A resposta honesta era não. O copiloto funcionava em piloto, gerava recomendação ao regulador médico, mas o que ficava registrado era a saída do modelo. Não a sequência de ferramentas que ele acessou. Não o estado do banco no instante da leitura. Não o contexto da conversa interna que disparou aquele chamado de função. Sem essa trilha, o agente era útil para engenheiro e inadequado para o resto do ciclo.
Esse texto é para o time técnico que está estruturando essa frente em saúde suplementar. Não é manual de implementação. É a leitura que fizemos depois do anúncio dos Managed Agents, cruzada com o que vimos em provas de conceito de copiloto de regulação em operadoras de 50 a 150 mil vidas.
Perímetro antes do modelo
Existe um padrão que confunde times de plataforma. Quando o problema é "agente analisa pedido", a discussão começa em qual modelo usar, qual stack de orquestração, qual prompt template. Esses temas importam, mas não são onde a arquitetura morre quando o pedido vem do jurídico ou da ANS.
O perímetro vem antes. Em operadora regulada, o agente toca dado clínico de beneficiário, código TUSS, laudo, prescrição, histórico de uso. A pergunta arquitetural é dupla. Onde esse dado pode residir enquanto o agente raciocina, e o que sai do perímetro do ambiente da operadora durante o raciocínio.
Modelo monolítico hospedado num provedor genérico de LLM falha aqui em dois pontos. Primeiro, parte do contexto clínico vai compor o prompt e atravessa a fronteira do tenant. Segundo, o vendor lock impede que a operadora defenda, frente a regulador ou em juízo, o controle sobre onde o dado esteve em cada etapa.
A leitura que fizemos do anúncio de Managed Agents é que a indústria começou a tratar isso. O agente roda em sandbox controlado pelo cliente, em vez de no provedor do modelo. O isolamento de processo é decisão do tenant, não do fornecedor. Isso muda o desenho.
Sandbox controlado pelo cliente: o que o Claude Agent SDK desbloqueia
O Claude Agent SDK, na configuração de sandbox gerenciado, executa o loop do agente em ambiente computacional cujo perfil é definido pelo cliente. Limite de CPU, limite de memória, lista de processos permitidos, sistema de arquivos efêmero, política de rede de saída. O agente vive ali enquanto o ciclo de análise dura, e o ambiente é destruído depois.
Para análise autônoma de pedidos em operadora, isso resolve três problemas que o copiloto de PoC normalmente arrasta. O primeiro é o de provisionamento de credencial. Como o sandbox tem perfil definido pela operadora, o token que o agente carrega é tão estreito quanto o passo que ele executa. Não é a chave que abre o EHR inteiro. É a chave que abre o registro do beneficiário X, naquela janela, para a operação Y.
O segundo é containment de exfiltração. Se o agente fosse persuadido por prompt injection a tentar chamada externa não prevista, a política de rede do sandbox barra na saída. O ataque que funcionaria contra um agente hospedado livremente não passa do firewall do tenant.
O terceiro é separabilidade entre tenants. Operadora X não compartilha sandbox com operadora Y. Não é só promessa contratual de tenancy lógica. É isolamento computacional.
Vale dizer onde isso ainda não é bala de prata. Sandbox controlado pelo cliente adiciona latência. Cada cold start do ambiente custa segundos, e em pedidos urgentes esse custo vira problema clínico. A engenharia precisa decidir entre warm pools com sandbox de longa duração, que reduzem latência mas degradam o argumento de isolamento, e sandbox de curta duração com cold start, que preserva o isolamento mas pesa no SLA. Nossa preferência em casos de uso clínico-críticos tem sido warm pools com TTL agressivo, mas é uma escolha contextual.
MCP privado e a substituição do RAG ingênuo
O segundo eixo é como o agente acessa dado. A primeira geração de copilotos em saúde usava RAG sobre embeddings clínicos, o que coloca dado em representação vetorial num índice externo. Funciona para certos casos, mas inverte o controle. O dado clínico fica em formato que o time de governança não consegue auditar com a mesma rigidez de uma tabela em base relacional.
Servidor MCP privado muda esse contrato. O Model Context Protocol expõe ferramentas tipadas ao agente, e essas ferramentas podem ser implementadas como chamadas a fontes canônicas dentro do perímetro da operadora. Em vez do agente buscar "informação semelhante a X", ele invoca get_beneficiary_history(beneficiary_id, period) e recebe resposta estruturada, paginada, com timestamp. Cada chamada deixa registro auditável no servidor MCP, que está dentro do tenant.
Para análise de pedidos isso é estruturalmente diferente. A ferramenta validate_tuss_code(code, claim_id) é método auditável. Quem o chamou. Quando. Com que argumentos. Que retorno. O regulador que pede a trilha decisória recebe a mesma estrutura que um log de transação de qualquer outro sistema crítico da operadora.
E porque o servidor MCP é privado, o catálogo de ferramentas é definido pela operadora. Nem todo agente vê o mesmo conjunto. O agente de regulação clínica tem acesso a ferramentas diferentes do agente de auditoria de conta médica. Quem desenha o agente desenha o que ele pode fazer, no nível de API.
A admissão honesta nesse ponto é que servidores MCP privados ainda exigem maturidade de engenharia de plataforma que poucas operadoras têm hoje. Definir os contratos, versionar as ferramentas, manter compatibilidade entre agente e servidor, instrumentar observabilidade. É trabalho de plataforma, não de prompt engineering. Operadoras que tentam pular essa camada terminam com agente promissor que para de funcionar a cada release do modelo.
A trilha auditável virou o entregável
Junte os dois eixos. Agente roda em sandbox do tenant. Acessa dado via servidor MCP privado. Cada chamada deixa registro estruturado. O que sai dessa combinação é a coisa que faltava no piloto da operadora que abriu este texto.
A trilha auditável de uma decisão do agente passa a ter formato semelhante à trilha de uma decisão de um sistema convencional. Quem disparou. Que ferramentas foram chamadas. Com que parâmetros. Que retornos. Que conclusão foi gerada. Pode ser reconstruída comando por comando, em juízo, frente à ANS, em comitê interno.
Esse é o pré-requisito que torna o agente autônomo defensável em saúde suplementar regulada. Não é a sofisticação do modelo. É a sofisticação do registro.
Onde a arquitetura ainda decepciona
Vale dizer onde isso ainda falha. Três pontos que vemos consistentemente no campo.
A latência composta de sandbox cold start, chamada MCP e raciocínio do modelo, somada, pode passar de oito segundos por iteração. Para análise de pedidos rotineira, ok. Para fluxo de pré-autorização emergencial, é problema. Operadoras precisam escolher entre rotas dedicadas para casos urgentes, sem agente, ou aceitar a latência e dimensionar a fila.
A versão privada do MCP ainda é território de stack maduro. Os SDKs evoluíram desde o último trimestre, mas a curva de estabilização não é trivial. Empresas com time de plataforma pequeno vão sentir.
Custo computacional escala não-linear com o tamanho do agente. Cada loop com cinco chamadas de ferramenta custa muito mais que uma chamada única ao LLM. Isso muda a economia do projeto, e quem não modela esse custo no business case toma susto no segundo trimestre de operação.
Esse blueprint, na nossa leitura, é o piso do que torna defensável um agente para análise de pedidos em operadora regulada. AI.AGENTS é a frente em que materializamos isso para clientes de saúde suplementar. O agente roda em sandbox controlado pelo tenant, com perfil de execução definido pela operadora. O acesso a dado clínico é mediado por servidor MCP que vive dentro do perímetro, com catálogo de ferramentas auditável. Cada chamada de ferramenta produz registro estruturado, indexado pela decisão do agente, recuperável por trilha de auditoria.
Para times técnicos que estão dimensionando esse projeto, a avaliação prática do AI.AGENTS é a forma direta de testar a arquitetura. Em duas a três semanas, rodamos o agente sobre amostra de pedidos reais do prospect, em sandbox do cliente, com servidor MCP apontando para fontes selecionadas do ambiente da operadora. A saída tem dois pedaços. A trilha auditável de cada decisão, comparada com o que o regulador médico decidiu no mesmo período. E o relatório de onde o agente convergiu com o humano, onde divergiu, e por qual motivo. É a base concreta para decidir se a arquitetura entra em produção.
Sozinhos, combatemos uma fraude. Unidos, eliminamos o problema.