CUGA e Hermes: o modelo não explica o agente inteiro

O harness assume o trabalho quando o modelo entrega uma ação: apresenta ferramentas, prepara contexto, executa a solicitação e devolve resultados ou falhas. A comparação publicada pela IBM Research em 3 de novembro de 2026 mantém o modelo e troca esse sistema de execução. Eu trataria essa passagem como parte da arquitetura a examinar diante de uma tarefa que o agente não concluiu.

No experimento descrito pela equipe do CUGA, CUGA, Hermes e Deep Agents usaram GLM-5.3-flash em tarefas do AppWorld. A escolha é importante porque elimina uma explicação fácil para a diferença de resultados: não se trata simplesmente de comparar modelos distintos. Ela não elimina, porém, diferenças de configuração e adequação entre os sistemas.

O que a IBM mediu

O AppWorld apresenta tarefas que exigem ações encadeadas em aplicativos, como consultar informações e modificar estados. A IBM o trata como uma aproximação de certas capacidades necessárias à automação empresarial. Isso é diferente de demonstrar que o agente opera uma empresa real, com permissões, exceções, dados históricos e consequências comerciais.

Segundo o artigo, cada harness recebeu os mesmos 90 problemas, distribuídos em 30 cenários, com uma tentativa por tarefa. A avaliação usou Harbor. A taxa de conclusão relatada foi de 81.1% para CUGA, 46.7% para Hermes e 30.0% para Deep Agents. Esses números pertencem ao experimento da IBM; não são resultados de testes realizados por nós nem uma classificação geral dos projetos.

Há uma diferença relevante entre acertar tarefas isoladas e resolver consistentemente variações de um cenário. O artigo também apresenta essa segunda leitura. Para quem está escolhendo uma automação, a ideia é útil mesmo sem transformar a tabela em previsão: um sistema pode funcionar no exemplo conhecido e falhar quando muda a combinação de aplicativos ou o caminho necessário.

Mesmo modelo não significa mesma configuração

O CUGA foi configurado com decomposição de tarefas, verificação antes da execução e reflexão automática. Hermes usou a configuração padrão da integração com Harbor, com ferramentas disponibilizadas por MCP. Deep Agents recebeu ferramentas por MCP e componentes adicionais para seleção de ferramentas, resumo de contexto, tarefas e novas tentativas. Portanto, a comparação reúne sistemas completos com escolhas diferentes.

A própria IBM reconhece limites: a amostra pertence a um benchmark, os ambientes de execução não eram idênticos e as rodadas não avaliaram aplicação de políticas. Além disso, a análise é publicada pela equipe de um dos participantes. Isso não invalida o trabalho, mas torna indispensável manter atribuição e escopo junto de qualquer número citado.

A interpretação editorial mais forte é restrita: organizar o trabalho pode alterar muito o resultado obtido com um modelo. A interpretação fraca seria dizer que o CUGA vence qualquer agente em qualquer contexto. O experimento não sustenta essa generalização, nem mede todas as razões pelas quais alguém adotaria Hermes.

Produtos que resolvem problemas diferentes

O repositório do Hermes descreve um assistente com memória, aprendizado de procedimentos e acesso por diferentes canais. Essas capacidades dizem respeito à continuidade de uso. Uma tarefa fechada de benchmark não representa integralmente essa experiência, assim como a presença de memória não comprova melhor execução em operações entre aplicativos.

Já o LangGraph é apresentado como uma base de orquestração para agentes com estado e execução prolongada. Ele permite combinar etapas determinísticas e decisões de modelo. Comparar essa base diretamente com um assistente pronto exige cuidado: parte do comportamento depende do que a equipe constrói sobre ela. Deep Agents acrescenta um harness, enquanto LangGraph oferece uma camada mais fundamental.

Para uma decisão prática, comece pela operação desejada. Um assistente pessoal persistente, um fluxo empresarial entre APIs e uma estrutura para desenvolver agentes próprios podem compartilhar tecnologia e ainda pedir produtos distintos. A ferramenta adequada precisa ser julgada pelas ações que realmente terá de executar.

Como transformar a comparação em uma escolha

Nossa recomendação é selecionar tarefas representativas, manter o modelo constante quando possível e registrar a configuração completa. Inclua casos em que uma ferramenta retorna informação incompleta, uma autorização falta ou o agente precisa confirmar o estado antes de modificar algo. São sugestões de avaliação, não testes já executados aqui.

O estado final registra a conclusão da tarefa, mas não demonstra que cada regra de autorização foi respeitada. A IBM deixou a aplicação de políticas fora da avaliação. O estudo permite examinar decisões do harness junto da resposta do modelo. A escolha operacional continua sendo qual execução e recuperação atendem ao trabalho e como esse sistema aplicará as políticas que a comparação não testou.