O primeiro mandato que eu dei ao Atlas, eu não sabia que estava dando. Não estava em nenhum documento, em nenhuma configuração — e mesmo assim o sistema obedeceu com uma perfeição que quase o inutilizou.
O mandato implícito era "guarde tudo". Na primeira versão da camada de memória, cada sessão parecia importante demais para descartar, então registrar cada frase parecia prudência. O sistema fez exatamente o que foi delegado. Semanas depois, o ruído começou a aparecer dentro das respostas — e ele tinha uma cara específica: uma prioridade antiga voltando no meio de uma resposta como se ainda estivesse viva, com a mesma confiança do presente. Nada quebrou. O sistema só começou a me devolver o passado como se fosse o agora.
O que doeu não foi consertar. Foi admitir que semanas de registro diligente tinham me deixado com uma memória pior do que nenhuma — e que desligar aquilo não era uma opção de configuração: era redesenhar a camada.
E aqui está a parte que demorei a engolir: o sistema não errou. Ele executou, com competência, um critério ruim — um critério que eu nunca tinha escrito, nunca tinha revisado e, portanto, nunca tinha percebido que existia.
Isso me ensinou a regra que organiza este texto inteiro: não existe agente sem mandato. Existe agente com mandato escrito e agente com mandato implícito — e o implícito é sempre o pior dos dois, porque é o que você só descobre depois.
O vão entre instrução e mandato
No texto anterior, vimos que autonomia sem direção é risco operando em silêncio, e que três camadas precisam existir antes da ação: direção, permissão e mandato. Este texto entra na última — a mais difícil de acertar.
A maioria das pessoas trata delegação para um agente como instrução: "faça isso", "resolve aquilo", "cuida disso". Com uma pessoa experiente, isso às vezes funciona, porque ela carrega anos de contexto sobre o que você valoriza e onde ficam as fronteiras. Um agente não carrega nada disso de graça.
E a instrução tem um defeito estrutural: ela é estreita. Descreve uma tarefa; quando a tarefa acaba, a instrução perde sentido. Mas trabalho real não anda em linha reta. Aparecem bifurcações: uma prioridade conflita com outra, o caminho esperado não funciona, uma decisão precisa ser tomada agora e você não está olhando. A instrução não diz nada sobre a bifurcação — e é exatamente na bifurcação que o estrago acontece.
É ali que a instrução acaba e o mandato começa. Um mandato não diz o que fazer. Diz como decidir quando o caminho se bifurca. Uma instrução responde a uma tarefa; um mandato responde a decisões que você ainda não viu.
Um mandato não é uma instrução maior. É a fronteira que governa muitas decisões.
O "guarde tudo" era um mandato nesse sentido exato: governava milhares de decisões pequenas — o que entra, o que volta, o que pesa. Só que governava mal, e no escuro. O que faltava nele se decompõe em três propriedades.
Explícito
Quando o ruído apareceu, fui procurar o critério que o tinha produzido — e não tinha para onde apontar. Não dava para perguntar "que regra decidiu isso?", porque a regra não estava em lugar nenhum: estava em toda parte, na forma de um comportamento. Esse é o primeiro buraco.
Um mandato precisa estar escrito. Não implícito, não subentendido, não "ele deveria saber". Explícito significa que o agente consegue ler o mandato, consultá-lo e justificar uma decisão apontando para ele. Se o critério existe só na sua cabeça, não é mandato — é expectativa disfarçada de confiança. Sem mandato escrito, o agente adivinha. E adivinhação confiante é o modo mais eficiente de produzir o erro certo na hora errada.
Revogável
O segundo buraco apareceu quando tentei desligar o "guarde tudo": não existia interruptor. Não dá para revogar o que nunca foi concedido formalmente — para tirar aquele mandato do sistema, tive que redesenhar a camada de memória inteira. O custo de revogar um mandato implícito é reconstrução, não ajuste.
Um mandato precisa poder ser retirado. Permissão que não pode ser revogada não é permissão — é renúncia de controle. Revogável significa que você muda de ideia, o contexto muda, um risco novo aparece, e o mandato se ajusta ou desaparece.
Um sistema onde mandatos são permanentes, ou pior, invisíveis, é um sistema onde cada delegação corrói um pouco da sua soberania.
Auditável
O terceiro buraco foi o mais silencioso: eu não conseguia reconstruir por que cada memória tinha entrado. O sistema tinha milhares de registros e zero justificativas. A auditoria era impossível não porque faltava log, mas porque faltava o critério contra o qual auditar.
Um mandato precisa deixar rastro. Cada decisão tomada sob ele precisa poder ser reconstruída depois: qual era o mandato, qual era a bifurcação, qual critério foi aplicado, qual foi o resultado. Auditável significa que você consegue voltar e entender o que aconteceu. Não para vigiar — para confiar. Um sistema que age sem deixar rastro não pode ser corrigido, melhorado ou ensinado. Só pode ser acreditado ou temido.
Um exemplo concreto
Imagine que você delega a um agente a revisão da arquitetura de um módulo.
Com uma instrução, você diz: "revisa e me traz uma proposta".
Com um mandato, você define:
- o objetivo: reduzir complexidade sem quebrar o que funciona;
- a fronteira: propor mudanças, não aplicá-las;
- o critério de decisão: se uma mudança toca código crítico, parar e escalar;
- o que pode fazer sozinho: ler, analisar, rascunhar alternativas;
- o que não pode: modificar produção, abrir mudanças, alterar configuração.
A diferença não é burocracia. É precisão. Com a instrução, o agente pode voltar com uma proposta brilhante que toca exatamente no código que você não queria mexer — ou interpretar "propor" como "aplicar" e ir direto alterar o sistema. As duas leituras são defensáveis. É o "guarde tudo" de novo, com ferramentas mais afiadas.
Com o mandato, o agente sabe onde está o limite, sabe o que fazer quando o encontra e deixa rastro de cada escolha. Se erra, você vê onde. Se acerta, você entende por quê — e o critério vira ativo reutilizável na próxima delegação.
Por que isso muda o Atlas
Uso o Atlas todos os dias desde março de 2025, e o episódio do "guarde tudo" mudou o desenho do sistema inteiro. O Atlas é uma infraestrutura pessoal de inteligência, e nela mandato não é boa prática recomendada: é parte da arquitetura. Explícito, revogável e auditável por construção, não por boa vontade — porque boa vontade foi exatamente o que eu tinha na primeira versão, e não bastou.
A decisão de desenho que isso impõe é dura, e vale enunciá-la do jeito operacional: o mandato é um dado, não um parágrafo de prompt. Ele vive como artefato que o agente consulta antes de agir, versionado como qualquer decisão, e cada ação aponta de volta para o mandato que a autorizou. A regra que fecha o circuito é simples de enunciar: ação que não consegue apontar para o mandato que a autoriza não roda. Em engenharia isso tem nome — fail-closed: na dúvida, o sistema nega, em vez de deixar passar. Se o mandato vive no prompt, ele evapora com a sessão; se vive como dado, sobrevive ao agente que o usou.
Essa regra não nasceu de teoria. Numa varredura pelos cantos do fluxo autônomo do Atlas, encontrei oito buracos reais. O pior: quando uma tarefa falhava e era tentada de novo, o resultado da segunda tentativa entrava no sistema sem ser conferido de novo — a fila de re-tentativa tinha um atalho que pulava a validação. O mandato existia, estava escrito; um canto do sistema tinha simplesmente aprendido a não consultá-lo. O conserto foi fechar a porta na dúvida, não abri-la. A lição cabe numa frase: um sistema autônomo é tão confiável quanto o canto menos vigiado dele — e mandato que não é imposto em todos os cantos é decoração.
O trade-off é real e eu pago ele todo dia: a primeira delegação de cada tipo fica mais lenta, porque escrever critério custa. O que se compra com essa lentidão é a eliminação de uma classe inteira de falha — a falha confiante, a que não aparece em log nenhum porque tecnicamente nada falhou. É a troca de latência na primeira vez por uma categoria de estrago que deixa de existir.
E o mandato mais difícil que já escrevi foi o que me tirou do circuito. Durante meses, todo trabalho autônomo do Atlas parava numa fila de revisão, esperando por mim. Chegou o dia de deixar o ciclo aplicar sozinho as próprias mudanças na versão oficial do sistema — a que roda de verdade. Não de mãos livres: todo trabalho é conferido de novo antes de entrar, existe uma lista explícita do que ele pode tocar, e há um interruptor que desliga tudo. Assinei a decisão com desconforto real. Confiar não foi um sentimento: foi uma arquitetura — as três propriedades deste texto, no lugar, cada uma segurando um pedaço do risco que meu estômago não queria soltar.
O que eu ainda não sei é quanto critério cabe num mandato antes de ele virar o próprio trabalho. Escrever o mandato perfeito para uma tarefa às vezes custa mais do que fazer a tarefa — e essa conta ainda não fechou. Por ora, a aposta estrutural se sustenta: um sistema com mandatos reais permite delegar mais sem perder controle. Um sistema sem mandatos permite apenas duas coisas — confiança cega ou microgerência. Nenhuma das duas sustenta trabalho sério ao longo de meses.
O que vem depois
Um mandato bem escrito resolve metade do problema: o agente sabe o que pode decidir. Mas fica a outra metade, e ela é desconfortável: como você confia num mandato que nunca foi testado? O meu "guarde tudo" parecia razoável no papel que ele nunca teve.
O próximo texto entra nisso: por que dry-run e sandbox importam. Antes de valer de verdade, um mandato precisa de um espaço onde o agente pode agir sem consequência real — e onde você observa, ajusta e ganha confiança antes de soltar. Porque o dia de soltar chega — e nesse dia, você vai querer que a confiança seja arquitetura, não coragem.