Um agente recebe uma tarefa enquanto a fila de atendimento continua mudando. Ele compara alternativas, monta uma boa resposta e só então tenta agir. Nesse intervalo, a prioridade mudou. A decisão pode estar bem fundamentada e ainda assim chegar tarde demais para ser útil.

O Realtime-Bench, apresentado em preprint em 15 de outubro, coloca esse problema no centro da avaliação de agentes. O estudo reúne 50 tarefas, entre aplicações web e jogos, nas quais o momento da ação influencia o resultado. A pergunta interessa a quem constrói automações que precisam acompanhar um ambiente em movimento.

Três relógios, três perguntas

A documentação de avaliação descreve três maneiras de contar o tempo:

  • Wall Clock: o tempo real da execução conta, incluindo rede, inferência e ações.
  • Paused Clock: a geração ocorre com o ambiente pausado, como referência idealizada.
  • Token Clock: a quantidade de tokens gerados determina o avanço do tempo simulado.

Na leitura da MnzAI Labs, a utilidade dessa separação aparece antes de qualquer ranking. Se a tarefa falha apenas quando o relógio real entra em cena, investigar a infraestrutura pode ser tão importante quanto trocar o modelo. Se continua falhando com o ambiente pausado, há outros problemas a resolver.

Os autores relatam que aumentar o esforço de raciocínio ajudou os seis modelos dessa comparação com o ambiente pausado, mas teve efeitos mistos sob pressão temporal. Isso não dá uma regra pronta para reduzir o raciocínio de toda aplicação. Mostra por que a configuração precisa ser testada junto do prazo disponível para agir.

O prazo útil de uma decisão pertence ao problema que a aplicação resolve.

A configuração faz parte do resultado

Há uma diferença relevante para quem pretende reproduzir os testes. O repositório público da versão 1.0 disponibiliza 20 tarefas e mantém um conjunto reservado para avaliação oficial. Rodar a parte pública não equivale a reproduzir integralmente a avaliação do paper. O ambiente documentado requer Linux, uv e Apptainer com fakeroot.

Também convém ler o protocolo com cuidado. O paper oferece marcações auxiliares da interface para os modelos e descreve uma simplificação no tratamento da latência das ações gráficas. Já a documentação atual do repositório inclui essa latência no Wall Clock. Paper e implementação precisam ser identificados pela versão usada, antes de comparar resultados.

Esses limites ajudam a formular a decisão de adoção. Uma taxa de sucesso obtida num ambiente preparado não permite prometer que uma automação vai acompanhar uma tela de atendimento, um processo de aprovação ou um painel operacional. Cada contexto tem um custo diferente para agir com informação desatualizada.

Medir o tempo útil da decisão

Para uma equipe, o próximo passo pode ser um teste pequeno com casos autorizados do próprio processo. A análise da MnzAI Labs é começar registrando quando a informação foi observada, quando a decisão ficou pronta e se a ação ainda fazia sentido naquele instante. Assim, uma falha deixa de aparecer apenas como “o agente errou”.

Essa observação permite decisões concretas de arquitetura. Uma alteração irrelevante pode esperar pela resposta em andamento. Uma mudança que invalida a ação exige nova leitura do estado. A equipe precisa definir esse critério e o que fazer quando o tempo acaba, inclusive devolver o controle à pessoa responsável.

O Realtime-Bench oferece um instrumento para investigar essa tensão. Não reproduzimos seus experimentos. Seu valor para o trabalho de engenharia está em tornar verificável uma pergunta que avaliações estáticas deixam passar: a aplicação consegue reconhecer que uma boa resposta já perdeu a hora de ser executada?