Teste Como o Computador do Seu Agente Falha Antes de Comprá-lo

Em 30 dias, proxies fornecidos pelos clientes falharam ao estabelecer um túnel em cerca de 9,0% das vezes. Os proxies gerenciados pela Steel, fornecedora de infraestrutura de navegador, falharam em cerca de 0,4%. Nikola Balić publicou os números em um ensaio para a Steel com o título “Build the agent. Don’t build its computer.” Ele mesmo faz a ressalva: os números cobrem apenas o estabelecimento do túnel.

Leia o número junto com a origem. Ele vem da frota da própria Steel, a Steel vende a opção gerenciada, e a página declara isso. Um fornecedor que relata falhar menos que a alternativa faz uma afirmação a ser verificada, e o ensaio tem valor justamente porque explica como verificá-la. O argumento de Balić: times de agentes devem escrever o que o computador do agente precisa fazer, testar como ele se recupera de falhas em cargas reais e começar com infraestrutura gerenciada, salvo quando ser dono dela traz uma vantagem que se consiga nomear.

Nossa leitura vai um passo além. A pergunta de compra para um runtime de agente é de quais falhas ele se recupera e quem responde por cada uma. Uma lista de funcionalidades não responde a isso. Falhas injetadas respondem.

Pausar e retomar é o caso fácil

O post da Perplexity sobre a abertura do código do SPACE, a plataforma de sandbox por trás do produto Computer, traz uma descrição clara de como é um recurso de recuperação. Segundo o post, o SPACE permite que o agente pause para alguém revisar um rascunho e depois retome com arquivos e estado de execução preservados, e que snapshots frequentes de arquivos e checkpoints do ambiente inteiro em execução preservam o progresso entre interrupções. A Perplexity também relata que, desde julho, o SPACE roda todas as sessões do Computer e processa milhões de criações de sandbox por dia. O post não tem autor nem data na página.

O exemplo de pausar e retomar descreve o caminho cooperativo, em que a plataforma sabe que a interrupção vem aí. Os recursos citados acima não dizem como os checkpoints se comportam quando um host cai de forma abrupta. Balić, em outro ensaio, traça a linha em uma frase: uma pausa e retomada limpas não provam recuperação de uma falha abrupta do host.

Essa distinção decide a compra. Uma demonstração vai mostrar uma pausa limpa. A produção vai entregar um worker que some no meio da tarefa. Também vai expirar um cookie de sessão durante uma execução longa, ou deixar uma aprovação aberta enquanto o aprovador fecha o notebook. Para cada caso, pergunte se a execução retoma de forma limpa ou corrompe alguma coisa no caminho de volta.

Uma nota sobre nosso próprio registro. Em julho escrevemos que o SPACE destrói cada sandbox ao fim da tarefa. O post atual da Perplexity dá destaque a pausa, retomada e checkpoints do estado em execução, então aquele enquadramento de julho precisa de ressalva.

Quatro falhas para injetar

Balić lista testes de aceitação construídos sobre falhas deliberadas. Cada um vem com critérios de aprovação e uma coluna para quem é responsável. Os nomes dos quatro testes e a coluna de responsabilidade são dele. As perguntas em cada um são nossas:

Trocar o worker no meio da execução. Derrube a máquina que o agente está usando e deixe a plataforma subir outra. A execução retoma de um ponto conhecido ou começa do zero?
Expirar o login. Deixe a sessão autenticada vencer enquanto o agente trabalha. O agente detecta e se autentica de novo por um caminho aprovado, ou segue agindo sobre uma página deslogada?
Perder a resposta de um post no Slack. O agente envia uma mensagem e nunca recebe retorno. Ele não sabe se o post chegou. Uma nova tentativa sem checagem de idempotência publica duas vezes.
Desconectar a pessoa durante a transferência. O agente para esperando aprovação e a pessoa sai. Que estado se mantém, por quanto tempo, e o que acontece quando ela volta?

A coluna de responsabilidade é a parte mais fácil de pular. Para cada falha, alguém responde pela recuperação: a plataforma do fornecedor, o código do seu agente ou uma pessoa. Quando ninguém está nomeado, a falha cai em quem estiver de plantão naquela noite.

O terceiro teste merece atenção extra porque expõe uma propriedade de design que nenhum runtime entrega sozinho. Repetir um efeito colateral com segurança exige que as ações do agente sejam idempotentes, ou que ele cheque o estado antes de agir de novo. Um sandbox pode preservar arquivos com perfeição e ainda assim deixar o agente mandar a mesma mensagem duas vezes para um cliente.

Escreva o inventário de estado antes do contrato

Recuperação precisa de uma lista do que tem que sobreviver. Antes de avaliar qualquer fornecedor, anote cada pedaço de estado de que uma execução depende: arquivos em disco, sessões e cookies do navegador, estado de processos em memória, chamadas de ferramenta pendentes, pedidos de aprovação esperando uma pessoa e credenciais em uso.

Depois confira cada item contra as regras de retenção da plataforma. Balić relata uma dessas regras para os sandboxes hospedados da OpenAI: se a atividade e os keep-alives pararem por uma hora, o sandbox pode ser apagado. É uma política razoável. Ela também significa que uma aprovação humana que leve mais de uma hora, sem keep-alive rodando, pode voltar para uma sala vazia. Se o seu fluxo tem aprovações que atravessam a noite, essa regra entra no plano de testes.

Os checkpoints do ambiente inteiro do SPACE respondem a parte do inventário. A sua lista mostra qual parte, e o que você ainda precisa persistir por conta própria.

Onde ficam as credenciais

Já tratamos de isolamento em detalhe, no padrão de contenção e nas fronteiras desenhadas pela infraestrutura. Balić retoma um ponto que fizemos no post sobre a Docker: o isolamento mantém o agente longe de outras cargas de trabalho, e não limita o que as credenciais dentro do sandbox permitem. O que o teste de recuperação acrescenta é a pergunta sobre o que acontece com essas credenciais entre um checkpoint e uma restauração.

O desenho da Perplexity assume a mesma posição com outras palavras: o SPACE trata o sandbox como não confiável e gerencia o acesso à rede e as credenciais da plataforma fora dele.

Para os testes de falha, isso muda o sentido de “expirar o login”. Se as credenciais ficam dentro do sandbox, um checkpoint pode capturá-las e uma sessão restaurada pode carregar um token que deveria ter morrido. Se a plataforma as guarda do lado de fora, a nova autenticação vira responsabilidade da plataforma, que você consegue testar e atribuir. Pergunte ao fornecedor qual modelo ele usa e rode o teste de expiração para ver se a resposta se sustenta.

O argumento para comprar, vindo de quem construiu

Balić é franco sobre o custo de construir. Nos últimos seis meses, segundo ele, a equipe começou três reconstruções dessa infraestrutura e trocou as primitivas a cada vez, e interrompeu uma delas antes de chegar à produção. Pese isso contra o interesse comercial. Quem descreve as próprias reconstruções também está descrevendo por que esse trabalho é difícil de manter em casa.

A regra de decisão dele é curta: compare o custo por resultado aceito, e deixe de lado o custo por segundo de computação. E “nós conseguiríamos construir” não é motivo.

Custo por resultado aceito embute a falha no preço. Um runtime barato que precisa de várias tentativas por tarefa, ou de resgates humanos frequentes, custa mais do que a tarifa por hora sugere. Esses índices só aparecem quando cargas reais passam pelos testes de falha, e é por isso que os testes vêm antes da compra.

Ser dono do computador do agente ainda faz sentido para alguns times. O teste é conseguir nomear a vantagem em uma frase que o responsável financeiro aceitaria, como uma exigência de residência de dados ou uma carga que nenhum fornecedor atende. Se a frase não vier, o padrão é o gerenciado.

Faça isto agora

Escolha um fluxo de agente em produção e rode esta sequência antes da próxima decisão de runtime:

Escreva o inventário de estado desse fluxo. Cada item ganha uma linha.
Monte os quatro testes de falha da lista de Balić e escreva os critérios de aprovação antes de rodá-los.
Preencha a coluna de responsabilidade com um dono nomeado em cada linha. Nada em branco.
Rode os testes no runtime atual e em cada candidato, com cargas reais.
Calcule o preço de cada opção por resultado aceito, contando novas tentativas e resgates humanos.

Peça a cada fornecedor o equivalente aos 9,0% contra 0,4% da Steel, medido no seu tráfego. Um fornecedor disposto a rodar seus testes de falha em um período de avaliação entrega evidência melhor que qualquer ficha técnica.

Fontes

Steel (Nikola Balić). “Build the agent. Don’t build its computer.” Outubro de 2026. A Steel vende infraestrutura de navegador gerenciada, e os números de falha de proxy vêm da sua própria frota.
Perplexity. “Open-sourcing SPACE, the sandbox platform behind Computer.” Outubro de 2026.

A Victorino ajuda times de engenharia a desenhar testes de falha e mapas de responsabilidade antes de escolher um runtime de agente: contato@victorino.com.br | www.victorino.com.br