A AWS ampliou o Amazon Bedrock AgentCore Evaluations para avaliar agentes criados com OpenAI Agents SDK, LlamaIndex, Google ADK e Claude Agent SDK, além de Strands Agents e LangGraph, já contemplados. O ponto central não é transformar esses frameworks em uma única plataforma. É usar telemetria padronizada para reconstruir sessões, chamadas de modelo e uso de ferramentas antes de aplicar os mesmos avaliadores. A promessa reduz fragmentação, mas depende de instrumentação correta e de dados suficientes chegando ao CloudWatch.
Capa: ilustração editorial original do Bastidores da IA. Não é captura de tela, interface real nem material oficial da AWS.
Quando isso aconteceu
A expansão aparece nas notas de versão de agosto de 2026 do AgentCore e foi detalhada pela AWS em um artigo técnico publicado em 26 de agosto de 2026. A documentação atual lista seis frameworks com tratamento dedicado: Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK e Claude Agent SDK.
O AgentCore Evaluations não nasceu nesta semana. O serviço chegou à disponibilidade geral em março de 2026 com avaliações sob demanda e online. A novidade agora é ampliar a cobertura dos frameworks e criar um caminho genérico para bibliotecas que emitam telemetria segundo as convenções esperadas de OpenTelemetry ou OpenInference.
O que mudou para quem constrói agentes
Equipes costumam escolher frameworks diferentes para orquestração, recuperação de dados, coordenação entre agentes ou integração com um fornecedor de modelos. O problema aparece na hora de comparar qualidade: cada biblioteca registra prompts, respostas, ferramentas e sessões de um jeito diferente.
A AWS passou a tratar a telemetria como contrato comum. Em vez de exigir que todos os agentes sejam reescritos no mesmo SDK, o serviço tenta identificar os spans relevantes, extrair os campos necessários e converter a execução para uma representação que os avaliadores entendam. Isso permite aplicar critérios como sucesso do objetivo, correção, utilidade e avaliações personalizadas a agentes construídos com pilhas distintas.
Essa compatibilidade não significa que qualquer trace será interpretado automaticamente. O framework precisa emitir scopes e atributos reconhecidos, e o conteúdo da conversa precisa estar nos locais previstos pela convenção ou pelo tratamento específico da biblioteca.
OpenTelemetry é a ponte, não a avaliação
OpenTelemetry padroniza a coleta e o transporte de traces, métricas e logs. No fluxo descrito pela AWS, ele funciona como a linguagem usada para registrar o que ocorreu durante a execução. A nota de qualidade vem depois, quando o AgentCore reconstrói a sessão e entrega os dados aos avaliadores.
Essa separação é importante. Ter traces completos não prova que um agente é correto, seguro ou útil. A telemetria torna o comportamento observável. A avaliação ainda depende de critérios, exemplos de referência, rubricas e, em alguns casos, de outro modelo usado como juiz.
Da mesma forma, uma pontuação alta em um conjunto pequeno de testes não substitui validação no contexto real. O avanço anunciado facilita comparar agentes, mas não elimina a necessidade de definir o que conta como sucesso para cada processo.
Os três papéis de span que sustentam a reconstrução
O artigo técnico da AWS destaca três papéis que o serviço precisa reconhecer:
- Invocação do agente: representa o ciclo principal de uma interação, com a solicitação do usuário e a resposta final.
- Inferência: registra uma chamada ao modelo, incluindo o histórico enviado e a resposta recebida.
- Execução de ferramenta: registra o nome da ferramenta, parâmetros e resultado.
Outros spans, como recuperação, reranqueamento, memória e guardrails, podem enriquecer o contexto. Segundo a AWS, eles não são obrigatórios para os avaliadores descritos no anúncio. O serviço classifica o que reconhece e ignora papéis que não precisa usar.
Na prática, um trace com apenas chamadas HTTP ou métricas de infraestrutura pode existir e ainda ser insuficiente para avaliação. É necessário capturar o nível do agente, do modelo e das ferramentas com os atributos esperados.
Seis frameworks têm tratamento dedicado
A lista atual cobre Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK e Claude Agent SDK. Cada integração depende de uma biblioteca de instrumentação OpenTelemetry ou OpenInference, e a documentação da AWS registra os scopes e versões testadas.
No caso do OpenAI Agents SDK, por exemplo, a AWS documenta dois caminhos: opentelemetry-instrumentation-openai-agents e openinference-instrumentation-openai-agents. Quando o agente roda no AgentCore Runtime com AWS Distro for OpenTelemetry, adicionar a biblioteca de instrumentação às dependências pode ser suficiente para a descoberta automática. Ainda assim, observabilidade e exportação precisam estar configuradas.
O Bastidores da IA comparou recentemente as escolhas de arquitetura entre OpenAI Agents SDK e Google ADK. A atualização da AWS não apaga essas diferenças. Ela oferece uma camada comum para medir o comportamento resultante.
Frameworks fora da lista entram por uma rota genérica
Para bibliotecas sem tratamento dedicado, o AgentCore oferece suporte genérico de melhor esforço. O scope precisa começar com opentelemetry.instrumentation. ou openinference.instrumentation., e os spans devem usar atributos padronizados para identificar operações de agente, inferência e ferramenta.
A limitação está no formato. Sem um parser específico para o framework, o serviço converte conteúdos proprietários em texto. Se o prompt, a resposta ou os argumentos estiverem dentro de um envelope próprio, o avaliador poderá receber essa estrutura serializada em vez de campos limpos.
Scopes desconhecidos e spans sem atributos reconhecidos podem ser ignorados. A própria documentação classifica o caminho genérico como fallback de melhor esforço. Portanto, a afirmação correta é que há uma rota para frameworks compatíveis com as convenções, não suporte automático a qualquer biblioteca existente.
O detalhe operacional que pode fazer a avaliação sumir
O exemplo da AWS chama atenção para o envio dos buffers de telemetria. O AgentCore Runtime pode suspender o ambiente depois que o handler retorna, enquanto o SDK de OpenTelemetry ainda mantém spans ou registros de evento em memória. Se o código não força o envio ao final da invocação, parte do trace pode não chegar ao CloudWatch.
A recomendação do exemplo é descarregar tanto o provedor de traces quanto o provedor de logs. Os dois usam processadores separados. Fazer flush de apenas um deles pode deixar prompts, respostas ou eventos de ferramenta para trás.
Esse é um limite menos chamativo que a lista de frameworks, mas decisivo para uso real. Uma avaliação vazia ou incompleta pode ser problema de instrumentação, não sinal de que o agente não executou a tarefa.
Avaliação sob demanda e avaliação online resolvem problemas diferentes
O modo sob demanda combina melhor com regressão e integração contínua. A equipe executa casos controlados, fornece respostas esperadas, trajetórias de ferramentas ou afirmações de comportamento e compara a nova versão com uma referência. Esse fluxo ajuda a impedir que uma mudança de prompt, modelo ou ferramenta reduza a qualidade sem ser percebida.
A avaliação online acompanha uma amostra de sessões reais. Ela é útil para detectar variações em produção, mas não tem uma resposta esperada para cada conversa. Por isso, avaliadores personalizados que dependem de ground truth não se aplicam automaticamente ao tráfego online.
Os dois modos podem usar critérios semelhantes, mas respondem a perguntas distintas. Um mede se uma versão passou por casos conhecidos. O outro procura sinais de qualidade no uso real. Misturar os resultados sem considerar essa diferença produz conclusões frágeis.
Telemetria também cria uma obrigação de segurança
Para reconstruir a execução, traces podem conter prompts, respostas, nomes de ferramentas, argumentos e resultados. Dependendo do agente, isso pode incluir dados pessoais, segredos operacionais ou informações de clientes. A capacidade de avaliar mais frameworks aumenta a importância de revisar o que é coletado e quem pode consultar os registros.
Antes de ativar captura ampla, a equipe deve mapear dados sensíveis, aplicar minimização, definir retenção, limitar permissões no CloudWatch e verificar requisitos de residência. A documentação regional da AWS mostra que o AgentCore Evaluations está disponível em várias regiões, inclusive South America, São Paulo, mas recursos de inferência entre regiões precisam ser avaliados conforme o modo selecionado e as exigências de conformidade.
Observabilidade útil não exige registrar tudo sem filtro. O objetivo é preservar evidência suficiente para reproduzir falhas sem transformar o sistema de avaliação em uma nova fonte de exposição.
O que ainda precisa ser validado por cada equipe
A AWS demonstra que os mesmos avaliadores podem receber traces de frameworks diferentes. Isso não garante equivalência perfeita entre as instrumentações. Uma biblioteca pode capturar a mensagem final com precisão e omitir detalhes intermediários. Outra pode registrar ferramentas em uma estrutura mais rica. Comparações justas exigem conferir a cobertura antes de comparar notas.
Também é necessário validar o avaliador. Métricas baseadas em modelo como juiz podem variar com instruções, modelo avaliador e exemplos usados. Para decisões importantes, convém manter uma amostra revisada por humanos e medir concordância.
O guia Como testar um prompt antes de adotá-lo no trabalho apresenta uma abordagem pequena e repetível. O mesmo princípio vale aqui: começar com casos representativos, registrar a versão e investigar divergências antes de ampliar o painel.
Fatos confirmados e análise editorial
Fato confirmado: as notas de versão da AWS registram suporte expandido para OpenAI Agents, LlamaIndex, Google ADK e Claude Agent SDK, somando esses frameworks a Strands Agents e LangGraph.
Fato confirmado: a rota genérica depende de scopes e atributos compatíveis com OpenTelemetry ou OpenInference e pode serializar estruturas proprietárias sem interpretação específica.
Análise editorial: a mudança reduz o custo de manter uma suíte de avaliação para cada framework, desde que a organização trate a instrumentação como parte testável do sistema. Sem esse cuidado, uma camada comum pode apenas padronizar resultados incompletos.
Não demonstrado: o anúncio não prova que avaliações entre frameworks serão idênticas em todos os cenários, nem que avaliadores automáticos substituem revisão humana para riscos de alto impacto.
Por que isso ainda importa
Equipes estão combinando agentes de fornecedores e frameworks diferentes no mesmo ambiente. Sem um contrato de telemetria, cada migração exige refazer painéis, parsers e testes. A abordagem da AWS sugere um caminho mais portátil: padronizar a evidência da execução e manter os critérios de qualidade separados da biblioteca escolhida.
O ganho prático aparece quando uma organização consegue testar um agente em OpenAI Agents SDK e outro em Google ADK com a mesma definição de sucesso, sem fingir que as implementações são iguais. Isso ajuda a comparar comportamento, não apenas popularidade ou preferência de arquitetura.
A leitura cautelosa é simples: compatibilidade de avaliação começa na telemetria, não termina nela. O próximo passo para quem pretende adotar a novidade é executar um caso conhecido, confirmar que prompts, respostas e ferramentas foram reconstruídos corretamente e só então confiar nas pontuações.