A conta de um runtime paralelo
Por que a escolha de base do runtime deixa de ser preferência e vira custo de infraestrutura quando o volume chega. E por que ela não deixa a execução mais rápida.
Time de engenharia da Tessera · 14 set 2026 · 7 min
A pergunta certa não é velocidade
Quando se fala de performance de agentes, a primeira pergunta costuma ser quanto tempo leva uma execução. É a pergunta errada, e vale explicar por quê antes de qualquer outra coisa.
A maior parte do tempo de parede de uma execução de agente é espera. Espera pela resposta do modelo, espera pelo sistema que foi consultado, espera pela ferramenta que foi chamada. Nenhum runtime acelera isso, porque nenhum runtime controla o que está do outro lado.
A pergunta certa é quantas execuções simultâneas a mesma máquina sustenta. Essa sim é decidida pelo runtime, e é ela que aparece na fatura.
O que muda com volume
Um agente em produção é um processo que passa a maior parte da vida esperando e, nos intervalos, faz trabalho curto.
Com dez execuções simultâneas, qualquer arquitetura funciona. Com dez mil, a questão passa a ser quanto custa manter dez mil coisas esperando ao mesmo tempo.
Se cada execução ocupa uma unidade cara de execução enquanto espera, a conta cresce com o número de execuções e não com o trabalho feito. Você paga para esperar. É esse o ponto em que a escolha de base deixa de ser preferência de time e vira linha de custo.
Actor Model, e o que ele resolve
O Tessera Runtime é escrito em Java 25, com Actor Model. Duas escolhas, e a segunda importa mais que a primeira.
No Actor Model, cada execução é uma unidade isolada com estado próprio, que se comunica por mensagem e não por memória compartilhada. Isso produz três consequências práticas.
Isolamento por construção. Uma execução que trava não trava as vizinhas, porque não há estado comum entre elas. Num sistema com milhares de agentes de times diferentes, isso deixa de ser elegância e vira requisito: o agente mal escrito de um departamento não pode derrubar a operação de outro.
Paralelismo sem trava compartilhada. O gargalo clássico de concorrência é a disputa por recurso comum. Sem memória compartilhada, não há disputa, e a escala deixa de depender de quão bem alguém ajustou um pool.
Densidade. Uma unidade de execução do modelo de atores é barata, e milhares delas esperando custam pouco. É daqui que sai a diferença de quanta máquina a mesma carga exige.
Por que Java, e não a escolha óbvia
A maior parte do ecossistema de agentes é Python, e para construir e experimentar isso é vantagem real: as bibliotecas estão lá e o ciclo de iteração é curto.
Em produção com volume a conta muda, e por uma razão específica: a plataforma fica no caminho crítico de toda execução. Não é um serviço que responde uma requisição e sai. É a camada por onde passa cada chamada de cada agente da organização, o tempo todo.
Nessa posição, sustentar concorrência alta com uso previsível de recurso deixa de ser detalhe. E é também a base em que já rodam os sistemas críticos que a maior parte dessas empresas opera há anos, o que significa que a operação sabe monitorar, ajustar e diagnosticar o que está embaixo.
Sobre o número
O site publica uma medição interna de execução completa de agente abaixo de 46 milissegundos, com a ressalva de que resultados de performance dependem da carga, do hardware, da configuração e da metodologia.
A ressalva não é formalidade. É a diferença entre publicar um sinal de engenharia e publicar um claim, e a Tessera prefere o primeiro. Qualquer número de performance que apareça sem a condição de medição ao lado deve ser lido com desconfiança, inclusive quando for nosso.
O que o runtime não resolve
Ele não deixa o modelo mais rápido. Se a chamada ao modelo leva dois segundos, ela vai levar dois segundos. O ganho do runtime está na densidade e na concorrência, não na latência de uma execução isolada.
Ele não conserta agente mal desenhado. Um agente que faz onze buscas onde bastava uma vai fazer onze buscas mais rápido. Desenho ruim não é problema de infraestrutura, e é por isso que observabilidade importa tanto quanto runtime.
E ele não é o argumento de compra. É o que sustenta o argumento: a governança só é viável se a camada que a aplica não virar gargalo. Performance aqui é condição, não proposta. Conheça o Runtime.
