O CordisBench coloca uma pergunta estreita, mas muito prática, às equipas que constroem infraestruturas dinâmicas para agentes: quando um agente altera os componentes à sua volta, consegue o modelo prever com fiabilidade o estado que essas alterações deixam para trás? O novo benchmark mostra que os modelos conseguem muitas vezes identificar os componentes afetados, mas tornam-se bastante menos fiáveis ao prever o estado final, raciocinar sobre diferentes ordens de limpeza ou escolher uma reconfiguração mínima à medida que aumentam as interações.
O resultado de engenharia mais importante não é apenas a existência de erros. O CordisBench também define uma semântica de referência finita que coincide com a execução do Cordis em todas as observações e resultados de ações usados para avaliar 528 perguntas executáveis. Para esta classe restrita de alterações ao ciclo de vida, a consequência mecânica pode ser calculada de forma exata. Parte da governação da estrutura do agente deixa assim de ser um problema de instruções ao modelo e passa a ser um problema de verificação.
O benchmark isola o raciocínio sobre o ciclo de vida
O CordisBench foi submetido ao arXiv a 1 de setembro e publica tanto o código como um conjunto de dados congelado. Inclui 1 200 perguntas estruturadas geradas a partir de 240 sistemas. As tarefas abrangem a identificação dos componentes afetados, a previsão do estado final para uma determinada ordem de encerramento, condições que se mantêm em todas ou apenas em algumas ordens permitidas e ações de reconfiguração que são efetivamente executadas.
O benchmark utiliza dois contextos. Um contexto formal compacto torna explícitas as dependências e as transições de estado. Um contexto nativo do Cordis compila padrões semelhantes em extensões executáveis com Cordis 4.0.0-rc.7. Os autores fazem variar o número de interações relevantes entre 2 e 32, mantendo a forma da pergunta e a regra de avaliação constantes dentro de cada tarefa.
Os modelos avaliados são Gemini 3.7 Flash, GPT-5.6 Luna e DeepSeek V4 Flash com baixo esforço de raciocínio. É um conjunto limitado, mas o desenho tem utilidade prática: as respostas são avaliadas de forma determinística e os planos de reconfiguração são executados em vez de serem julgados apenas pelo texto.
Saber o que muda é mais fácil do que prever o que fica
O padrão mais claro é a separação entre localização e previsão das consequências. O GPT-5.6 Luna, por exemplo, permanece perto do máximo quando identifica componentes afetados, enquanto a sua pontuação em condições alcançáveis no contexto formal desce de 91,7% para 14,1% à medida que cresce o número de interações. No contexto nativo do Cordis, o sucesso das reconfigurações executadas desce de 62,5% para 25,0%.
Parte da degradação tem causas identificáveis. Vinte e nove respostas do Gemini atingiram o limite inicial de 8 192 tokens de saída, e o aumento desse limite melhora de forma material vários resultados nas instâncias maiores. Os autores também usam um diagnóstico com número fixo de ordens de encerramento para evitar confundir uma estrutura de dependências maior com a simples existência de mais ordens possíveis.
Mais raciocínio consegue recuperar parte do desempenho. Num subconjunto equilibrado com 16 interações, a precisão de previsão do GPT-5.6 Luna no Cordis sobe de 31,2% sem raciocínio para 85,4% com esforço médio, enquanto o sucesso das reconfigurações executadas sobe de 0% para 50%. O custo é de cerca de 2 967 tokens de raciocínio por pergunta, em média, nesse nível.
Algumas decisões de ciclo de vida não devem consumir raciocínio do modelo
O resultado de sistemas mais forte é a coincidência total entre a semântica de referência finita e a execução do Cordis nas 528 perguntas executáveis, para todas as observações e resultados de ações usados na avaliação. Dentro do modelo restrito do benchmark, está a ser gasto raciocínio probabilístico em consequências que o software consegue calcular exatamente.
Esta distinção é relevante em produção. Um modelo é útil para escolher objetivos, interpretar intenção ambígua e decidir entre políticas quando o ambiente não pode ser formalizado por completo. A retirada de dependências, a ordem de limpeza e a reposição de estado explicitamente representado pertencem a outra categoria. Quando esses mecanismos são conhecidos, pedir ao modelo que os preveja introduz uma superfície de erro e um custo de inferência evitáveis.
O princípio de arquitetura é colocar as consequências determinísticas abaixo da fronteira do modelo. O agente pode propor uma alteração à estrutura, mas um verificador de execução deve calcular as dependências afetadas, as ordens de limpeza permitidas, as restrições sobre o estado final e se a reconfiguração pedida satisfaz essas condições antes de a executar.
A evolução da estrutura precisa de dois critérios de promoção
O CordisBench surge poucas horas depois do HarnessDev, outro preprint de 1 de setembro já coberto pela Aipolix. O HarnessDev mostrou um problema mais amplo: melhorias escolhidas a partir de informação visível nem sempre se transferem para tarefas ocultas ou para outro modelo executor. O CordisBench acrescenta uma camada complementar.
Os dois resultados não devem ser resumidos como um aviso genérico sobre agentes autónomos. Apontam para dois mecanismos de garantia diferentes. Alterações semânticas à estrutura do agente continuam a precisar de testes empíricos de promoção, porque o seu efeito sobre o desempenho das tarefas não é geralmente calculável. Alterações mecânicas ao ciclo de vida devem, adicionalmente, passar por verificação determinística sempre que as dependências e os efeitos de limpeza estejam suficientemente explícitos.
Isto cria uma arquitetura de lançamento mais precisa. Primeiro, deve validar-se se a nova versão melhora realmente a carga de trabalho pretendida em tarefas ocultas e com os modelos executores de produção. Depois, deve verificar-se separadamente que essa versão não pode deixar o ambiente de execução num estado inválido quando componentes são adicionados, removidos ou encerrados segundo diferentes ordens legais.
O resultado é útil, mas deliberadamente limitado
O CordisBench é um preprint e não constitui evidência replicada de taxas de falha em produção. Os casos com 24 e 32 interações são testes de esforço, não estimativas de configurações típicas. As tarefas nativas do Cordis usam um conjunto controlado de ordens de encerramento e concentram-se na remoção orientada por dependências e na reposição de estado durante a limpeza. Não modelam ações externas irreversíveis, falhas, substituição dinâmica completa de módulos ou todos os ciclos de retorno disponíveis a um agente real.
A avaliação de três modelos também deixa em aberto o comportamento de modelos mais fortes, acesso a ferramentas, retorno da execução e novas tentativas. O Gemini fica perto do máximo em várias tarefas nativas e alguns resultados de grande dimensão são sensíveis ao limite de saída.
Estas limitações tornam a conclusão mais precisa. O CordisBench não demonstra que modelos de linguagem são incapazes de gerir estruturas dinâmicas. Mostra que as equipas devem primeiro perguntar quais as partes dessa gestão que exigem raciocínio probabilístico. Quando uma transição de estado pode ser derivada mecanicamente, a arquitetura mais segura e económica é calculá-la ou verificá-la e reservar o modelo para as decisões verdadeiramente incertas.