Nenhum dos dois piores erros da história do Atlas quebrou alguma coisa na hora em que aconteceu. É exatamente isso que os torna os piores.
O primeiro foi meu. Uma memória antiga estava confusa; abri o registro, reescrevi a frase, salvei e segui em frente. O que sumiu não foi a frase — foi tudo em volta dela: o motivo da mudança, a diferença entre a versão original e a que ficou, a evidência de que houve uma revisão. O segundo foi um mandato implícito: o "guarde tudo" da primeira camada de memória, que o sistema executou com perfeição até o dia em que uma prioridade antiga voltou no meio de uma resposta como se ainda estivesse viva — e o ruído ficou impossível de ignorar.
Contei os dois nos textos anteriores. O que não contei é o que eles me ensinaram juntos: se qualquer um dos dois tivesse passado por um ensaio — um passo que mostrasse a intenção antes do efeito —, o estrago teria aparecido preto no branco. "A versão original será destruída." Eu teria parado na hora.
Não parei porque não havia onde parar. A ação ia da intenção direto para a consequência, sem nada no meio.
É esse "nada no meio" que este texto ataca.
O problema que o mandato não resolve
No texto anterior, tratei mandato como um contrato explícito, revogável e auditável. Essa definição é necessária: agente sem mandato adivinha. Mas ela deixa uma pergunta desconfortável em aberto, e eu terminei aquele texto nela: como você confia num mandato que nunca foi testado?
A resposta ingênua é confiar porque o papel parece bom. Foi o que eu fiz com o "guarde tudo" — ele parecia razoável no papel que nunca teve. Um agente pode estar certo no plano e errado no impacto: aplicar o critério certo no objeto errado, ler permissão de leitura como permissão de mudança, ignorar uma dependência que não estava visível, transformar uma instrução estreita numa cadeia de ações que é lógica por dentro e inadequada por fora.
Numa conversa isolada, esse erro morre com a sessão. Num sistema pessoal durável, ele se acumula: contamina memória, ensina o agente com o exemplo errado e muda a trajetória do sistema. O erro não some — vira fundação.
Então a pergunta certa não é "como o agente recebe direção?". É: como o agente prova entendimento antes de agir?
Dry-run não é hesitação
Dry-run é a execução em modo de ensaio. O agente percorre o caminho inteiro que seguiria — mas não aplica o efeito final. Em vez de mudar o sistema, mostra a intenção como um artefato verificável: que ação faria, sobre qual objeto, por qual motivo, com qual resultado esperado.
Um bom dry-run responde a perguntas simples:
- qual mudança seria feita;
- quais partes do contexto seriam tocadas;
- que evidência sustenta a ação;
- que consequência é esperada;
- onde a decisão ainda parece incerta;
- o que exigiria revisão humana ou outro ciclo de teste.
Repare no que isso teria feito pelos meus dois erros. A memória reescrita teria produzido um diff de intenção: "este registro será substituído; a versão anterior deixa de existir". O "guarde tudo" teria produzido um volume de intenção: "esta sessão gera dezenas de registros permanentes". Nenhum dos dois erros era difícil de ver. Eles só eram invisíveis no único momento em que alguém olhava — depois.
Quem faz software vai reconhecer o formato: é o mesmo motivo pelo qual ninguém dá deploy sem pipeline. Mas há uma diferença que muda o alvo do teste. Um pipeline de código testa o artefato; o ensaio de agente testa a interpretação. O bug não está no que o agente fez — está no que ele entendeu que o mandato pedia. É por isso que teste de software não substitui dry-run de agente: o código pode estar perfeito e a leitura do mandato, errada.
Dry-run não é medo de agir. É confiança transformada em dado observável. E não torna o sistema lento por princípio: a primeira execução de uma classe de tarefa merece ensaio exigente; quando o padrão estabiliza, o ensaio encurta ou aparece só quando algo foge do esperado.
Aprendi a versão inversa disso do jeito caro. Um dos executores autônomos do Atlas reportava sucesso em tarefa atrás de tarefa — e o registro de mudanças vinha vazio. Nenhuma linha alterada, nada. O sistema inteiro parecia produtivo, os painéis verdes, e nada mudava de verdade. O conserto não foi punir o executor: foi mudar o contrato para "sucesso = mudança provada", não "sucesso = declaração de sucesso". É o espelho do dry-run: o ensaio mostra a intenção antes do efeito; a prova confirma o efeito depois da ação. Um sistema confiável cerca a ação pelos dois lados.
Sandbox não é brinquedo
Se o dry-run mostra a intenção, a sandbox testa o comportamento.
Uma sandbox é um ambiente onde o agente executa de verdade — sem consequência real. Ele simula a mudança, produz a diferença, roda a verificação e registra o que teria acontecido se a ação tivesse sido liberada.
Isso quebra uma escolha que parecia binária. Sem sandbox, ou você segura o agente perto demais (e ele vira um script caro), ou solta cedo demais (e descobre o erro quando ele já é fundação). Com sandbox, existe a terceira posição: deixar agir num espaço contido, observar e ajustar o mandato antes da ação real.
E há uma assimetria que organiza tudo: erro em sandbox é evidência; erro em produção é dívida. O mesmo erro, no mesmo agente, com o mesmo mandato — o que muda é só onde ele acontece, e isso muda o sinal do valor. Um agente que só aprende causando efeito real transforma cada aprendizado em custo. Um agente que ensaia transforma cada erro em material.
O ensaio não reduz autonomia. Ele transforma autonomia em capacidade confiável.
O fluxo que interessa
A distinção fica mais clara quando a ação deixa de ser um salto e vira uma sequência.
O caminho apressado é curto: mandato, ação, surpresa. Parece eficiente porque remove etapas visíveis — mas só desloca o custo para depois da consequência, que é exatamente o momento mais caro de pagar.
O caminho governado é mais longo no começo: mandato, dry-run, sandbox, evidência, ação. Cada etapa produz material para revisar a próxima. O agente não apenas obedece; mostra que entendeu. O sistema não apenas autoriza; aprende quando autorizar.
Isso também muda o produto. Uma interface de agente não deveria mostrar só a resposta final. Deveria mostrar o que vai acontecer antes de acontecer: plano, alcance, evidência, risco percebido, ponto de reversão. A revisão vira parte da experiência — não uma tela de pânico depois do erro.
O que isso muda no Atlas
No Atlas, que é uma infraestrutura pessoal de inteligência e não um assistente de sessão, dry-run e sandbox viraram o mecanismo pelo qual agentes ganham escopo. A regra que organiza isso cabe numa frase: escopo se ganha por histórico, não por promessa.
Um agente não nasce confiável. Primeiro observa. Depois propõe. Depois ensaia. Depois executa em sandbox. Depois age em classes pequenas de trabalho. Só então, se o rastro provar consistência, recebe mandatos mais amplos. Cada degrau é registrado: em quais contextos acertou, onde falhou, que decisão ainda exige revisão, que parte do mandato precisou ser reescrita. O ensaio de hoje é a credencial de amanhã.
E há um degrau que descobri por omissão. Deixei uma vez um processo autônomo configurado para se manter vivo sozinho — e ele fez exatamente isso: renasceu a noite inteira, consumindo recursos sem produzir nada de valor, porque a condição de parada era mais fraca que a condição de partida. No dia seguinte nasceu o interruptor-mestre: nada autônomo roda no Atlas sem um desligador explícito e simples. A sandbox limita onde o agente age; o interruptor decide se ele continua. Um sistema que ensaia mas não sabe parar não fica seguro — só erra em câmera lenta.
O que eu ainda não sei — e essa conta não fechou — é quando um ensaio pode ser aposentado. Quanto histórico basta para pular o dry-run de uma classe de tarefa? Se eu exijo ensaio para sempre, o sistema fica lento sem ganhar segurança nova. Se aposento cedo demais, reabro a porta pela qual os meus dois piores erros entraram. Hoje o Atlas erra para o lado da exigência, e eu não tenho certeza de que esse é o ponto ótimo.
O que vem depois
Dry-run e sandbox respondem a uma pergunta específica: como um agente prova antes de agir?
Mas provar antes de agir é a última peça conceitual de uma sequência que começou lá atrás — memória, contexto, direção, mandato, ensaio. Com a base no lugar, a pergunta muda de natureza: o que acontece quando essas peças param de ser textos separados e começam a formar um sistema?
O próximo texto fecha esta primeira sequência: como o Atlas está evoluindo — o estado real da construção. Porque a base conceitual, quando vira coisa que roda, começa a fazer perguntas que nenhum destes textos previu — a começar por uma que ainda me incomoda: o que acontece no dia em que o sistema passa a ensaiar, provar e agir mais rápido do que eu consigo revisar?