A Avaliação do Amazon Bedrock AgentCore Transforma Regressões de Agentes em Pull Requests Reprovados

A Amazon incorporou a avaliação do Amazon Bedrock AgentCore a uma barreira de qualidade funcional no GitHub Actions, substituindo verificações subjetivas de agentes por quatro testes pontuados.

O pipeline de referência implanta um agente de IA e um servidor Model Context Protocol protegido por OAuth, depois aciona o agente com prompts representativos. Ele pontua os rastros resultantes e reprova o pull request quando qualquer métrica obrigatória fica abaixo de um limite configurado.

Isso muda o debate sobre testes de agentes. A disputa imediata não é entre a AWS e outro provedor de nuvem. É entre avaliação automatizada e repetível e as verificações manuais pontuais que muitas equipes de desenvolvimento ainda usam antes de integrar alterações em agentes.

A Amazon publicou a implementação em 8 de setembro de 2026. O pipeline de avaliação conecta AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK e GitHub Actions.

O resultado importante não é mais um painel de testes. Uma resposta reprovada agora pode resultar em uma compilação de software reprovada, antes que o comportamento modificado do agente chegue a um ambiente compartilhado ou à produção.

A Avaliação do Amazon Bedrock AgentCore se Torna uma Barreira de Integração

A AWS transformou a qualidade de agentes de uma opinião durante a revisão em uma condição para pull requests.

O fluxo de trabalho de referência é executado quando um pull request direcionado à ramificação principal altera o código do agente, o código do servidor MCP, a infraestrutura ou os scripts de avaliação. Ele cria uma pilha temporária de desenvolvimento contendo dois runtimes do AgentCore.

Um runtime hospeda um agente baseado em Strands. O outro hospeda um servidor MCP, que expõe ferramentas por meio de um protocolo padrão para conectar aplicações de IA a capacidades externas.

Um pool de usuários compartilhado do Amazon Cognito protege ambos os runtimes. O fluxo de trabalho implanta essa infraestrutura por meio do AWS Cloud Development Kit e, em seguida, lê os identificadores de runtime e os endpoints de autenticação nas saídas da implantação.

O GitHub Actions obtém credenciais temporárias da AWS por meio da federação OpenID Connect. O OIDC permite que o GitHub troque um token de identidade de curta duração por uma função da AWS, evitando uma chave de acesso permanente da AWS nos segredos do repositório.

O fluxo de trabalho ainda armazena o ARN da função da AWS como um segredo do GitHub. No entanto, as credenciais da AWS resultantes são temporárias e limitadas pelas políticas de confiança e permissão da função. O GitHub documenta esse modelo de segurança do OIDC.

Após a implantação, o pipeline aguarda até que ambos os runtimes estejam prontos. Essa pausa é operacionalmente relevante porque um runtime recém-criado não pode aceitar solicitações imediatamente.

A AWS afirma que uma invocação antecipada retorna uma resposta 424 Failed Dependency. O fluxo de trabalho fornecido consulta o serviço de controle do AgentCore e aquece o servidor MCP antes de iniciar sua execução de testes.

Em seguida, o pipeline recupera um token de acesso OAuth e envia prompts de teste ao endpoint HTTPS do agente. Cada prompt recebe um identificador de sessão distinto, permitindo que o processo de avaliação associe os rastros emitidos à interação correta.

O conjunto de dados de exemplo abrange diversos tipos de comportamento. Ele pede que o agente calcule uma soma simples, retorne a hora UTC atual, encontre o preço de uma ação da Apple e obtenha uma contagem de funcionários.

Esses exemplos avaliam mais do que a redação das respostas. Eles testam capacidades integradas, ferramentas MCP públicas, ferramentas empresariais protegidas, seleção de ferramentas e os parâmetros enviados a cada ferramenta selecionada.

O script de avaliação aplica quatro avaliadores integrados:

• GoalSuccessRate pergunta se a sessão cumpriu o objetivo do usuário.

• Correctness compara a resposta com expectativas ou contexto disponíveis.

• ToolSelectionAccuracy verifica se o agente escolheu uma ferramenta adequada.

• ToolParameterAccuracy verifica se o agente forneceu argumentos apropriados.

A configuração de referência usa 0,8 em uma escala de zero a um como limite de aceitação. Se uma pontuação obrigatória ficar abaixo desse valor, o script é encerrado sem sucesso e o GitHub marca a tarefa como reprovada.

O fluxo de trabalho também pode publicar os resultados da avaliação no pull request. Os revisores veem a falha medida ao lado da alteração de código, em vez de reconstruir o comportamento do agente a partir de logs ou conversas locais.

Por fim, a etapa de limpeza é executada mesmo quando a avaliação falha. Ela destrói a pilha temporária do CDK para que pull requests reprovados não deixem runtimes de desenvolvimento em execução indefinidamente.

Essa sequência cria a tensão central. Os testes manuais podem revelar um problema evidente, mas raramente fornecem uma regra reproduzível que todo pull request relevante deve satisfazer.

Por Que os Testes Manuais de Agentes Estão Sob Pressão

O pipeline pressiona equipes que tratam uma resposta de agente como algo a ser inspecionado, em vez de um artefato que a entrega de software precisa validar.

Os testes tradicionais de aplicações têm saídas claras. Uma função retorna o valor esperado, uma API corresponde a um esquema ou uma operação de banco de dados preserva uma invariante.

Agentes de IA complicam esse modelo. Suas respostas podem variar, e uma frase final correta não prova que o agente seguiu um caminho aceitável.

Um agente que usa ferramentas pode selecionar o serviço errado, divulgar um resultado não autorizado ou enviar parâmetros malformados. Ele também pode chegar a uma resposta plausível por meio de uma sequência de chamadas cara ou insegura.

Alterações em prompts criam outro problema. Um pequeno ajuste nas instruções do sistema pode modificar a escolha de ferramentas, o comportamento de recusa, o nível de detalhe das respostas ou a conclusão de tarefas em cenários não relacionados.

Atualizações de modelos e alterações de dependências introduzem riscos semelhantes. Testes unitários convencionais podem confirmar que a aplicação funciona, mas deixar passar uma queda relevante no comportamento.

As equipes frequentemente compensam isso com conjuntos manuais de prompts. Um desenvolvedor insere várias perguntas conhecidas, lê as respostas e integra a alteração quando nada parece evidentemente errado.

Esse método tem cobertura fraca e julgamento inconsistente. Ele também produz pouca evidência sobre qual comportamento mudou entre duas revisões.

O pipeline da AWS adiciona um caminho comum de avaliação a cada pull request relevante. Ele implanta o código proposto, exercita esse código, coleta telemetria e aplica os mesmos avaliadores.

O AgentCore trabalha com spans do OpenTelemetry, que são registros estruturados de chamadas de modelo, atividade de ferramentas e outras operações dentro de uma interação. O AgentCore Observability envia esses rastros ao CloudWatch.

Para avaliação sob demanda, o pipeline seleciona spans de uma sessão específica e os passa ao serviço de avaliação. Os modos de avaliação também incluem monitoramento online e análise assíncrona em lote.

Essa distinção é importante para equipes de entrega. A avaliação sob demanda se encaixa em um pull request porque visa um conjunto pequeno e controlado de interações e retorna pontuações detalhadas.

A avaliação online atende a outro propósito. Ela coleta amostras do tráfego implantado e acompanha o comportamento após o lançamento, quando usuários reais produzem solicitações que um conjunto de dados de teste não antecipou.

A avaliação em lote processa coleções maiores de sessões. Ela é mais adequada para comparações de referência, auditorias periódicas e análises antes e depois de alterações.

A barreira de pull requests não substitui esses modos. Ela desloca o primeiro ponto de verificação mensurável para mais perto da alteração de código.

Essa abordagem também muda quem precisa reagir a uma regressão. Sem uma barreira, equipes de qualidade ou usuários frequentemente encontram o problema após a implantação.

Com uma verificação obrigatória do GitHub, o autor precisa corrigir o comportamento reprovado antes da integração. O feedback chega enquanto as decisões relevantes de código e prompt ainda estão recentes.

Isso é especialmente útil para equipes que mantêm agentes compartilhados. Uma alteração de resposta que parece aceitável para um desenvolvedor pode quebrar um fluxo de ferramentas pertencente a outro grupo.

Um conjunto de dados de avaliação cuidadosamente selecionado pode preservar essas expectativas. Ele se torna um registro executável das tarefas que o agente deve continuar realizando.

Os desenvolvedores ainda precisam de acesso ao contexto de apoio por trás dessas expectativas. Uma base de conhecimento de engenharia pode ajudar as equipes a conectar casos de avaliação a especificações, incidentes e decisões de design.

A mudança maior é organizacional. A qualidade do agente se torna parte da definição de uma alteração que pode ser integrada, em vez de uma revisão opcional realizada quando alguém tem tempo suficiente.

OAuth Torna os Testes de Ponta a Ponta Mais Difíceis do Que a Pontuação

A parte difícil não é solicitar uma pontuação de avaliação. É reproduzir o caminho completo de ferramentas de um agente protegido dentro de um executor de CI sem interface gráfica.

A arquitetura de referência coloca tanto o agente quanto o servidor MCP atrás do Cognito. Usuários interativos se autenticam por meio de um fluxo de código de autorização e recebem tokens que contêm escopos e declarações personalizadas de função.

Essas funções determinam quais ferramentas MCP um usuário pode acessar. Um usuário de finanças e um usuário de RH não devem receber automaticamente as mesmas capacidades empresariais.

O GitHub Actions não tem um usuário interativo. Ele não pode abrir uma tela de consentimento, concluir um login no navegador e transportar o contexto de função de uma pessoa durante o teste.

A AWS apresenta três formas de lidar com essa incompatibilidade. Cada uma valida uma parte diferente do sistema.

A primeira abordagem avalia rastros armazenados. Um processo de staging invoca o agente antecipadamente, captura telemetria representativa e salva esses rastros como fixtures de teste.

As tarefas de pull request avaliam os fixtures sem chamar um agente ativo ou servidor MCP. Essa abordagem é previsível e evita o problema de autenticação no CI.

Ela também tem uma limitação séria. As pontuações descrevem comportamentos capturados anteriormente, e não necessariamente o código do agente no pull request atual.

Rastros armazenados podem validar alterações nos avaliadores ou preservar uma linha de base histórica. Eles não podem provar que o código de runtime recém-alterado ainda produz a trajetória esperada.

A segunda abordagem usa uma conta de serviço dedicada. Um operador conclui a autorização interativa uma vez e armazena seu token de atualização em um gerenciador de segredos.

O CI pode então atuar como um usuário conhecido com funções definidas. Isso torna possível testar limites de autorização e acesso a ferramentas para uma identidade específica.

Tokens de atualização expiram ou se tornam inválidos. As equipes precisam de rotação, nova autorização e controle cuidadoso sobre os privilégios da conta.

A implementação da AWS escolhe uma terceira rota: autenticação máquina a máquina. O Cognito emite um token por meio da concessão OAuth client_credentials.

O script de avaliação envia o ID do cliente, o segredo do cliente e o escopo solicitado ao endpoint de token do Cognito. Em seguida, ele invoca o AgentCore Runtime por HTTPS com o token bearer retornado.

O middleware MCP diferencia esses tokens de tokens de usuários. Tokens de máquina têm escopos, mas não declarações personalizadas de função; portanto, o exemplo permite que eles alcancem todas as ferramentas.

Os tokens interativos continuam carregando funções, e o servidor MCP impõe restrições no nível da ferramenta para esses usuários. Assim, o mesmo pool do Cognito oferece suporte tanto ao acesso de CI quanto à autorização humana.

Esse design permite testes ativos de ponta a ponta do código no pull request. O agente pode chamar o servidor MCP implantado e produzir novos rastros para avaliação.

No entanto, ele não testa a aplicação de funções. A identidade de CI ignora essas verificações de função por definição.

Esse limite é a ressalva mais importante da arquitetura. Um pipeline aprovado mostra que a identidade de máquina consegue concluir as tarefas avaliadas. Não mostra que FinanceUser e HRUser recebem resultados autorizados diferentes.

As equipes que precisam das duas formas de garantia devem adicionar testes de autorização separados. Elas podem usar contas de serviço com funções específicas ou testes diretos contra o middleware MCP.

A credencial de máquina também se torna um ativo sensível. A AWS afirma que apenas o pipeline de CI e o runtime do agente devem conseguir obtê-la.

Essa afirmação depende de detalhes de implementação. Permissões do repositório, aprovações de workflow, políticas de IAM, exposição de segredos, comportamento de forks e redação de logs influenciam o limite real de segurança.

A conexão OIDC do GitHub protege o lado da AWS contra credenciais de repositório de longa duração. Ela não elimina todos os segredos, pois o cliente OAuth ainda usa um segredo de cliente.

A função de IAM também deve seguir o princípio do menor privilégio. Um acesso amplo de implantação a Cognito, ECR, recursos CDK, Bedrock e AgentCore pode conceder mais autoridade do que um job rotineiro de pull request precisa.

As proteções de ambiente podem reduzir o risco. As equipes podem restringir quais branches e workflows assumem a função, exigir aprovação para mudanças não confiáveis e separar funções de implantação de identidades de avaliação.

Portanto, a arquitetura testa juntos o comportamento do agente e a integração de CI. A correção da autorização continua sendo um objetivo de aceitação separado.

O Portão de Qualidade Avalia Rastros, Não Apenas Respostas

A avaliação do Amazon Bedrock AgentCore importa porque pode julgar o percurso do agente em uma tarefa, não apenas seu texto final.

O script de avaliação usa o kit inicial do AgentCore para reunir os rastros relevantes do CloudWatch. Em seguida, aplica avaliadores à sessão selecionada.

A API Evaluate bruta aceita sessionSpans, uma coleção de spans de telemetria pertencentes a uma sessão. A AWS alerta que misturar spans de várias sessões produz um erro de validação.

Esse limite de sessão permite que o avaliador reconstrua uma interação. Ele pode inspecionar a entrada do usuário, a saída do modelo, as ferramentas selecionadas, os parâmetros das ferramentas e a resposta resultante.

GoalSuccessRate opera no nível da sessão. Ele pergunta se a interação completa alcançou o que o usuário solicitou.

Correctness examina a resposta no nível do rastro. Pode usar uma resposta esperada quando o teste fornece uma.

ToolSelectionAccuracy e ToolParameterAccuracy funcionam no nível da chamada de ferramenta. Elas distinguem escolher a operação correta de chamar essa operação corretamente.

Essa separação produziu um resultado instrutivo no teste deliberado de regressão da AWS. Os autores alteraram o prompt do sistema para que o agente sempre retornasse uma recusa inútil.

GoalSuccessRate caiu para 0.0. Correctness também recebeu 0.0, e ToolParameterAccuracy recebeu 0.0.

ToolSelectionAccuracy ainda recebeu 1.0. Aparentemente, o agente conseguia identificar uma ferramenta apropriada mesmo falhando na solicitação geral.

É por isso que uma única medida agregada pode ocultar problemas. Diferentes avaliadores capturam dimensões independentes, e uma pontuação aprovada não pode compensar todos os comportamentos reprovados.

Depois que os autores restauraram o prompt de sistema pretendido, GoalSuccessRate voltou a 1.0. Correctness chegou a 0.9, enquanto ambas as métricas de ferramenta chegaram a 1.0.

As quatro ultrapassaram então o limite de exemplo de 0.8. O GitHub liberou o pull request.

O AgentCore também aceita entradas de referência para testes que exigem comportamento esperado. Essas entradas podem incluir uma resposta esperada, afirmações em linguagem natural ou uma trajetória esperada de ferramentas.

Uma trajetória descreve a sequência de ferramentas que um agente deve chamar. A AWS oferece avaliadores de ordem exata, em ordem e em qualquer ordem para diferentes restrições de workflow.

Um teste de ordem exata é adequado para um processo em que cada etapa depende da anterior. Um teste em qualquer ordem é adequado para operações de recuperação independentes cuja sequência não afeta a correção.

O serviço também oferece suporte a avaliadores personalizados. As equipes podem definir suas próprias instruções, modelo julgador e escala de pontuação para requisitos específicos de domínio.

Avaliadores baseados em código oferecem uma opção mais determinística. Eles invocam uma função AWS Lambda que pode verificar esquemas, padrões, palavras-chave ou regras de negócio.

Essa combinação importa porque nem todo requisito precisa de um juiz de modelo. Validade de JSON, campos proibidos, contagens máximas de chamadas e identificadores exatos muitas vezes podem usar código comum.

De acordo com o guia de avaliadores personalizados, os avaliadores podem operar no nível de sessão, rastro ou chamada de ferramenta. A lógica personalizada pode usar um modelo ou uma função Lambda.

Um portão prático deve associar o tipo de avaliador ao requisito. A pontuação baseada em modelo é adequada para qualidades semânticas como relevância, sucesso da tarefa ou fidelidade.

Código determinístico é adequado para restrições binárias. Verificações de trajetória de ferramentas são adequadas para a estrutura de workflow esperada.

O melhor sinal vem da combinação desses métodos. Uma resposta pode estar semanticamente correta enquanto viola um esquema, e um esquema válido ainda pode conter uma resposta irrelevante.

A verdade fundamental também merece uso cuidadoso. Nem toda resposta aceitável tem uma formulação exata, especialmente em resumos ou análises abertas.

Asserções podem expressar os fatos ou comportamentos que devem aparecer sem forçar uma única resposta. Trajetórias esperadas podem especificar o comportamento das ferramentas independentemente do estilo da prosa.

Isso transforma o conjunto de testes em mais do que uma coleção de prompts. Cada cenário pode declarar o que significa sucesso nos níveis de resposta, tarefa e ferramenta.

Uma Pontuação Aprovada Ainda Tem Pontos Cegos

O portão detecta regressões definidas, mas sua confiabilidade depende da cobertura dos testes, da estabilidade das pontuações, do desenho de identidade e do tempo operacional.

A AWS afirma que o pipeline completo leva cerca de 10 minutos. A implantação, a inicialização do runtime, a propagação de rastros e a avaliação baseada em modelo explicam essa duração.

Esse tempo é aceitável para muitos pull requests. É lento demais para uma verificação local de pré-commit e pode se tornar caro em repositórios com atualizações frequentes.

A disponibilidade de rastros acrescenta incerteza. A AWS observou atrasos de propagação de 30 a 90 segundos após a invocação do agente.

O script de referência tenta novamente a cada 30 segundos por até 10 minutos. Portanto, consultar o CloudWatch imediatamente pode produzir uma falha aparente antes de o rastro existir.

A arquitetura de runtime cria outro obstáculo de implementação. O AgentCore Runtime exige imagens de contêiner ARM64, enquanto os runners padrão hospedados pelo GitHub usam processadores x86-64.

O workflow usa QEMU e Docker Buildx para a construção de imagens multiplataforma. Esse requisito aumenta o tempo de compilação e introduz outro possível ponto de falha não relacionado à qualidade do agente.

A limitação mais importante vem do julgamento baseado em modelo. Um avaliador de LLM pode atribuir pontuações ligeiramente diferentes ao avaliar o mesmo rastro mais de uma vez.

Portanto, um limite rígido pode criar pull requests instáveis perto do limiar. Uma execução pode passar com 0.81, enquanto outra falha com 0.79 sem uma diferença significativa no código.

A AWS recomenda deixar margem entre o limite de aceitação e a meta de confiabilidade desejada. As equipes também devem medir a variância do avaliador antes de tornar uma verificação obrigatória.

Execuções repetidas podem estimar essa variância, mas também aumentam o uso de avaliação. O exemplo de referência usa quatro avaliadores em cinco prompts, produzindo 20 chamadas ao modelo julgador para um pull request.

A fonte não atribui um preço a essas chamadas. Ela recomenda que as equipes monitorem o uso do Bedrock à medida que os repositórios e conjuntos de dados crescem.

A cobertura dos testes apresenta um problema conhecido, porém mais acentuado. Um portão de qualidade mede apenas os cenários incluídos em seu conjunto de dados.

Quatro ou cinco prompts convenientes não podem representar toda solicitação de produção, estado de autorização, modo de falha, idioma ou entrada adversarial.

O token de máquina do exemplo pode acessar todas as ferramentas. Como resultado, a execução de ponta a ponta não prova que ferramentas protegidas por função permaneçam protegidas contra usuários comuns.

Uma pontuação ampla também pode ocultar desempenho desigual. Uma média geral pode passar enquanto um cenário crítico falha.

Tarefas de alto risco devem ter requisitos no nível de cenário. Uma ação de folha de pagamento, exclusão de conta ou consulta de dados pessoais não deve obter êxito emprestado de vários prompts fáceis de aritmética.

As métricas também precisam de responsáveis. Os desenvolvedores devem saber quem aprova mudanças de limiar, adiciona novos cenários e investiga divergências entre avaliadores.

Caso contrário, um portão reprovado pode criar pressão para reduzir o limiar. A organização então preserva a velocidade de entrega enfraquecendo a medição.

A falsa confiança é outro risco. Uma verificação verde mostra que a versão testada cumpriu critérios especificados em um determinado momento.

Ela não certifica todas as respostas, elimina a injeção de prompt nem valida a infraestrutura fora da pilha de testes implantada. Também não substitui a revisão de segurança.

A telemetria de produção continua essencial porque os usuários encontrarão combinações que um conjunto de dados selecionado não cobriu. A avaliação online do AgentCore pode amostrar sessões ao vivo e publicar resultados no CloudWatch.

A documentação de resultados afirma que as pontuações online aparecem como métricas do CloudWatch. Eventos detalhados de avaliação são armazenados em grupos de logs dedicados.

A avaliação em lote pode então comparar períodos maiores antes e depois de mudanças no modelo, prompt ou ferramentas. Essa comparação oferece uma linha de base mais forte do que uma execução de pull request.

Um sistema maduro deve conectar essas etapas. Falhas de produção devem se tornar novos cenários de avaliação, e falhas recorrentes de CI devem orientar o desenho do agente.

O portão de qualidade é mais confiável quando seu conjunto de dados evolui com os incidentes. Um benchmark estático acaba recompensando familiaridade com o teste em vez de comportamento confiável.

O Que Observar Após o Primeiro Portão do GitHub Actions

O próximo teste é verificar se as equipes conseguem tornar esses portões estáveis, conscientes de segurança e suficientemente representativos para se tornarem verificações obrigatórias.

O primeiro sinal é a adoção de avaliações de verdade fundamental e determinísticas nos workflows de pull request. As quatro métricas integradas oferecem um ponto de partida útil, mas não expressam todas as regras de negócio.

Observe se as equipes adicionam respostas esperadas, asserções e trajetórias de ferramentas para cenários de alto valor. O uso maior de verificações baseadas em Lambda mostraria que a avaliação de agentes está se tornando uma verificação comum de software.

Esse desenvolvimento fortaleceria o argumento a favor da avaliação do Amazon Bedrock AgentCore. Reduziria a dependência de um único juiz de modelo e tornaria algumas falhas mais fáceis de reproduzir.

O segundo sinal é a cobertura de CI consciente de funções. A AWS identifica abertamente a limitação do token de máquina, já que o fluxo escolhido contorna verificações de função de usuário.

As equipes devem publicar padrões que testem identidades de usuário distintas sem criar operações frágeis de atualização de token. Contas de serviço, testes diretos de autorização e locatários de teste isolados são rotas plausíveis.

Se verificações específicas por função se tornarem comuns, a arquitetura se aproximará de uma garantia completa de ponta a ponta. Se permanecerem separadas ou ausentes, uma pontuação verde do agente dirá pouco sobre a correção da autorização.

O terceiro sinal é a conexão entre portões de pull request e resultados de produção. Um pequeno conjunto de dados de desenvolvimento não pode permanecer representativo sem feedback de sessões reais.

Observe workflows que promovem rastros de produção com baixa pontuação a casos de regressão revisados. O monitoramento online deve descobrir falhas, enquanto testes de CI selecionados impedem que essas falhas retornem.

A ferramenta de avaliação de conjuntos de dados da AWS é outro desenvolvimento relevante. Seus executores de conjuntos de dados podem invocar agentes, aguardar a telemetria e avaliar cenários por meio de um processo coordenado.

Uma adoção mais ampla reduziria a orquestração personalizada atualmente visível no workflow de referência. Também facilitaria a manutenção de conjuntos de avaliação maiores e versionados.

Para os desenvolvedores, a questão prática já não é se as respostas dos agentes devem ser testadas. É quais comportamentos precisam bloquear um merge, quais exigem monitoramento e quais requerem aplicação determinística.

Comece pelas falhas que causariam um rollback, um incidente de segurança ou a interrupção de um fluxo de trabalho empresarial. Dê a cada uma um cenário explícito e um método de avaliação adequado ao seu risco.

Em seguida, quebre deliberadamente o agente e confirme que a barreira falha pelo motivo esperado. Uma verificação só se torna confiável depois que detecta uma regressão conhecida.

A Amazon forneceu um caminho crível dos testes de prompt às verificações obrigatórias de status do GitHub. O próximo passo cabe às equipes de engenharia: definir o comportamento que se recusam a lançar, codificá-lo e manter essa definição atualizada.