VolundOS

Como um agente executa

O que acontece entre você mandar a mensagem e o agente entregar: onde ele roda, por que trabalho longo não estoura, e o que acontece quando você manda parar.

Atualizado em 25 de agosto de 2026

Como um agente executa

Quando você manda uma mensagem, o agente não responde de dentro do site. Ele ganha uma máquina só dele — um computador de verdade, com terminal, navegador e disco — e trabalha ali até terminar. Esta página conta o que acontece nesse meio-tempo, porque parte disso você vê acontecer.

Por que trabalho longo não estoura

O jeito óbvio de fazer isso seria o site abrir a máquina, ficar esperando o agente terminar e só então responder. Foi assim no começo, e tinha um teto: pouco mais de treze minutos. Trabalho que passasse disso simplesmente não cabia — e trabalho de verdade passa disso o tempo todo.

Hoje o site só prepara e larga: ele monta a máquina, dispara o trabalho e sai. Quem conduz dali em diante é um processo que vive dentro da máquina do agente, acompanhando tudo do lado de dentro e mandando o resultado de volta conforme sai.

A razão de ele morar lá dentro não é elegância: a saída do agente não é reconectável de fora. Quem larga a conversa no meio não consegue voltar a ouvi-la — quem escuta precisa estar dentro.

O efeito prático é o que interessa: você pode fechar a aba. O trabalho continua, e o que ele produzir aparece na conversa quando você voltar.

Uma execução por conversa, sempre

Antes de começar, a conversa é marcada como ocupada. Isso impede que duas execuções da mesma conversa rodem ao mesmo tempo — o que aconteceria, por exemplo, se você respondesse a um pedido de aprovação enquanto outra coisa ainda estava em andamento. Duas execuções sobre o mesmo histórico produzem resultado imprevisível: uma escreve por cima do que a outra acabou de decidir.

Se algo falha no meio do preparo, o que foi criado é desfeito, e a mensagem de erro diz qual passo quebrou — não uma falha genérica.

O agente nunca vê a credencial que o move

A chave que permite gravar na conversa fica no processo que conduz a execução. O agente em si é iniciado num ambiente onde essa chave não existe.

Isso é deliberado, e vale entender por quê: o agente tem poder total dentro da própria máquina — ele abre terminal, lê arquivo, roda comando. Proteger a chave com permissão de arquivo não adiantaria nada. A defesa é a ausência: a chave nunca entra num arquivo nem no ambiente que o agente enxerga.

Quando você manda parar

O pedido chega por dois caminhos ao mesmo tempo: um imediato, e uma verificação periódica que roda a cada poucos segundos e serve de rede se o primeiro falhar.

E o que é interrompido não é só o programa principal: é toda a árvore de processos que ele abriu. Um comando que o agente disparou não sobrevive à parada. Há ainda um freio no navegador, para uma página que estava carregando não seguir sozinha depois que tudo parou.

A conversa que "parou de responder", e por que ela se cura

Entre um turno e outro a máquina do agente hiberna em vez de morrer — é o que faz o turno seguinte começar rápido, aproveitando o que já estava carregado.

O efeito colateral é conhecido: se um turno morre no meio — você mandou parar, deu erro, algo caiu — o que ficou carregado pode ficar num estado inconsistente, com um trabalho pendente que nunca terminou. O turno seguinte herda essa bagunça e o agente entra em looping: responde vazio. Do lado de fora, parece que "o agente parou de responder, e nem erro deu".

A saída é automática. Uma conversa nesse estado é marcada para começar do zero no próximo turno, descartando o que estava carregado. E começar do zero não perde o assunto: o histórico inteiro vai no pedido de qualquer jeito. A marca vale uma vez só — a conversa se cura em um turno.

Quando um turno termina sem produzir nada, você recebe uma mensagem dizendo que a sessão foi reiniciada e que pode mandar de novo. É melhor do que o silêncio que existia antes dela.

As diretrizes do seu projeto entram na conversa

Um repositório costuma trazer as próprias regras escritas — como o código deve ser escrito, o que nunca fazer, como a interface deve parecer. O agente não descobriria esses arquivos sozinho: eles não estão na pasta em que ele trabalha por padrão.

Então a plataforma lê essas regras e as coloca no pedido, junto das instruções do agente. Elas entram por último, depois de tudo que é estável — de propósito: são a parte que mais muda (o próprio agente edita esses arquivos), e no meio do pedido invalidariam o aproveitamento de tudo que vem antes a cada edição.

Uma correção que vale contar, porque explica um comportamento que dava para observar: até 19/08/2026 essa leitura acontecia antes de o esqueleto de um App novo existir no repositório. Num App recém-criado o repositório ainda está vazio nesse instante — então o pedido saía sem diretriz nenhuma, justamente na volta em que o agente decide a arquitetura e a aparência do sistema. O sintoma era visível: perguntado na primeira volta, o agente dizia não ter recebido diretriz de design; na volta seguinte, com o mesmo repositório, citava o documento inteiro. Desde 20/08/2026 a leitura acontece depois que o esqueleto existe.

Aprovar sem matar o turno

Quando uma ferramenta precisa de aprovação humana, o agente espera pela decisão em vez de morrer e ser retomado depois. Antes disso, pedir aprovação encerrava o turno, e a retomada era outra execução — com todo o custo de recomeçar.

Isso vale também para as perguntas que o agente faz a você no meio do trabalho: ele pergunta, espera, e segue com a resposta no mesmo turno.

Sobre a memória se enchendo

A janela de contexto de uma conversa tem limite, e quando ela enche é preciso resumir o que passou para continuar. Até 12/08/2026 a plataforma fazia isso sozinha ao atingir uma marca fixa — e descobriu-se que ela agia cedo demais, jogando fora contexto ainda útil antes que o mecanismo nativo, que sabe esperar até bem mais tarde, tivesse a chance de agir. O gatilho da plataforma foi desligado; quem resume agora é o mecanismo nativo, no momento certo.

O que resta depois que termina

Toda execução deixa um rastro gravado enquanto acontece, em pedaços fechados de tempos em tempos. É o que permite descobrir o que houve num trabalho que morreu no meio, sem aviso — o pedaço fechado sobrevive à morte da máquina. A perda máxima, numa parada violenta, é o último trecho: menos de um minuto.

On this page