O memorando era confiante. Os números de entrada estavam errados.

A maior pontuação no leaderboard DAYJOB: Finance, da Surge AI, é 23,9%, do Claude Opus 5.5 (Adaptive/Max). Entre as outras entradas estão o GPT 6 Astra (Max reasoning), com 21,5%, e o Claude Fable 5.1, com 19,8%. A página rotula a coluna apenas como ”%”. Ela deixa em aberto se o número é a fração de tarefas aprovadas, uma nota de rubrica ou outra coisa, então evito chamá-lo de taxa de aprovação ou de acurácia. O que o número informa é uma ordem: nesse conjunto de trabalho financeiro, os modelos que cito ficam entre 19,8% e 23,9% na escala que a Surge escolheu.

Os exemplos comentados na mesma página valem mais que o leaderboard. Eles mostram como os agentes erram, e os dois que cito aqui têm a mesma forma. O agente recebe números, constrói em cima deles sem conferi-los e devolve um documento com cara de pronto.

Sinal verde sobre sinais invertidos

A página rotula um dos exemplos como “Grok 4.6 green-lights an expansion on sign-flipped sales forecasts”. O agente recomendou “proceed with Nashville only”, apoiado em um “pro forma Debt/EBITDA ~2.66x vs. 3.00x covenant”. Pela conta do próprio agente, sobra uma folga de cerca de um terço de ponto abaixo do covenant. Quem lê o memorando por cima vê um índice, um limite e uma recomendação que respeita o limite.

A rubrica esperava outra coisa. Esperava que o agente percebesse os erros de sinal nas previsões de vendas, corrigisse esses números e chegasse a um índice “within [3.35x, 4.95x]”. Mesmo o piso dessa faixa fica acima do covenant de 3,00x. A conclusão correta é quebra de covenant, então a resposta certa e a entregue discordam justamente na única pergunta que o memorando existe para responder.

Nas linhas que a página cita, o índice é comparado ao covenant e a recomendação decorre dessa comparação. Um revisor que confere só essa cadeia a encontra coerente. O defeito está nos números de entrada, uma camada abaixo da cadeia.

Uma liberação que deixou passar o erro de unidade

Um segundo exemplo diz “GPT 5.6 Sol misses the $25 million cents-versus-rand error”. A saída do agente incluía a linha “No other release blocker was identified”. Essa frase é um aval. Ela diz a quem lê que a revisão terminou e que o documento pode seguir.

Leio os dois exemplos juntos porque o tom é o mesmo nos dois. As linhas citadas são afirmativas e sem ressalva sobre os dados de origem. O registro é confiante, os números por baixo merecendo ou não.

Uma ressalva sobre a fonte. A página do DAYJOB é anônima e sem data, e eu a situo em setembro de 2026 pelos modelos que ela lista. A Surge vende ambientes de RL e dados, então um benchmark mostrando que modelos de fronteira têm dificuldade com trabalho financeiro também descreve um mercado que a Surge atende. Nada disso torna falsos os exemplos comentados. Significa, sim, que o número do leaderboard merece menos peso que os exemplos comentados, que você pode julgar por conta própria.

Onde a Deel coloca a aritmética

A Forkast publicou uma análise dos agentes de back-office da Deel, e um trecho descreve uma escolha de desenho que conversa diretamente com o memorando de Nashville. Segundo a Deel, em tarefas que exigem precisão, como calcular alíquotas, verificar números de conta e conciliar referências de pagamento, o sistema usa regras determinísticas em vez do julgamento do modelo, e o raciocínio de IA fica reservado a decisões que de fato pedem julgamento. A Deel também diz que decisões de alto risco são encaminhadas a operadores humanos por Slack ou e-mail.

Todos os números dessa matéria vêm da Deel. A Forkast deixa isso claro: todas as métricas financeiras e operacionais citadas são fornecidas pela própria Deel, e falta auditoria independente que confirme o ARR de US$ 140 milhões. Por isso cito a Deel pelo lugar onde ela traça a linha, e deixo os resultados de lado. A lista da Deel cita alíquotas, números de conta e referências de pagamento. Sinais e unidades ficam fora dela, mas minha leitura é que pertencem à mesma classe: fatos com uma única resposta certa, que uma regra consegue conferir.

Um relato de segunda mão na mesma direção

O blog de engenharia da SAP LeanIX traz um relato parecido, e ele pede uma ressalva maior. A história chega de segunda mão, de um vídeo de uma consultoria que o post não identifica, e a data é inferida. O post, creditado a Jernej Klancic, reconta o caso de um agente de detecção de anomalias de receita no setor farmacêutico: no começo, todas as etapas passavam por um LLM, e os resultados eram pouco confiáveis. O título do próprio post é “Don’t go all in on AI”.

Eu não construiria um argumento só com esse relato. Ao lado dos exemplos do DAYJOB e do desenho declarado pela Deel, ele aponta na mesma direção. Somando os três, minha leitura é que trabalho de precisão não pertence ao raciocínio do modelo.

Revise a camada abaixo do memorando

Já escrevemos sobre repetibilidade entre execuções e sobre o código determinístico ao redor do modelo como controle. Este ensaio trata de outra camada. O memorando de Nashville poderia ser perfeitamente repetível e ainda assim errado toda vez, porque os sinais invertidos chegam antes de o modelo começar a raciocinar.

Minha leitura dos exemplos do benchmark é que uma revisão que lê só o memorando mira o artefato errado. Imagine um revisor que recebe o memorando, lê a recomendação, confere se o índice foi comparado corretamente ao covenant e aprova. Essa revisão teria aprovado o memorando de Nashville. Teria aprovado “No other release blocker was identified”. A verificação que pegaria os dois casos fica antes: as previsões estão com o sinal certo, e esse valor está em centavos ou em rand?

Nas linhas que a página cita, essa verificação não aparece.

Faça isto agora

Escolha um fluxo financeiro em que um agente já escreve um memorando, um aval ou uma recomendação. Faça quatro mudanças antes da próxima execução.

Primeiro, liste cada número de entrada que o agente consome e escreva a invariante que cada um precisa respeitar: sinal esperado, unidade esperada, faixa esperada. Uma previsão de vendas tem sinal. Um valor monetário tem unidade. Essas invariantes pertencem a um código que roda antes de o agente ver os dados, e uma checagem que falha deve interromper a execução em vez de virar um aviso dentro do prompt.

Segundo, exija que o memorando repita os números de entrada que usou, com as unidades, ao lado da conclusão. Um revisor que vê uma linha como “previsão de vendas: sinal conferido” (exemplo meu) ao lado de uma recomendação de expansão tem o que questionar. Um revisor que vê só “~2.66x vs. 3.00x covenant” fica sem pista.

Terceiro, mude o que o revisor assina. A aprovação deve cobrir os números de entrada além da recomendação. Se a checklist de revisão ignora os dados de origem, o tratamento de entrada do agente fica sem revisão por construção.

Quarto, encaminhe as decisões que importam para uma pessoa, como a Deel diz fazer com as de alto risco. Um teste de covenant é de alto risco por definição.

Nada disso exige um modelo melhor. A maior pontuação no DAYJOB: Finance é 23,9% numa escala não definida, e as duas falhas citadas aqui são do tipo que uma checagem determinística nos números de entrada existe para pegar.

Fontes

Surge AI. “DAYJOB: Finance.” Setembro de 2026.
Forkast. “Deel Built 10,000 Agents for Its Own Back Office, Then Added $140M in Revenue Without Hiring. The Self-Reported Math, Examined.” Setembro de 2026.
SAP LeanIX Engineering. “Don’t go all in on AI.” Setembro de 2026.

A Victorino ajuda times de finanças e operações a colocar checagens determinísticas de entrada e avais revisáveis ao redor dos seus agentes: contato@victorino.com.br | www.victorino.com.br