Respostas
Regra de agente de IA não deveria ser travada no código, em vez de escrita como memória?
Parte delas, sim — e essas nunca deveriam ter sido instrução. Regra que vale enquanto o sistema for construído do jeito que é, como um deploy por vez, mora numa trava que o agente não consegue pular. Só que a trava sabe impor a regra enquanto ela vale; ela não tem como dizer que a regra deixou de valer, quem decidiu isso ou o que entrou no lugar. A maior parte das regras que um time passa aos agentes é desse segundo tipo: decisão que alguém tomou e alguém vai rever — o que pode ir para o cliente, qual branch sobe, quanto custa um plano. É isso que a Arroway guarda. Cada regra carrega a condição que a encerra, a substituta aponta para a que aposenta, e só uma pessoa torna uma regra vigente. O invariante vai para o código e a decisão vai para a memória; regra que é as duas coisas ganha a trava e o registro de por que a trava existe.
Última atualização 24 de setembro de 2026
Para regra que nunca muda, a trava é a resposta certa
A objeção parte de algo verdadeiro. Instrução é texto que o agente lê e pesa contra tudo o mais que está na frente dele, e sob pressão às vezes ela perde. Quando dois builds colidem porque uma regra escrita dizia para não rodá-los juntos, transformar a frase num mutex é o conserto certo: a colisão deixa de ser desaconselhada e passa a ser impossível. O que dá para tornar mecanicamente impossível deve ser, e uma memória que pedisse para guardar esse tipo de regra em prosa estaria pedindo uma garantia mais fraca sem dar nada em troca.
A trava não tem campo para “isto deixou de valer”
O problema começa no dia em que o motivo da trava vai embora e a trava fica. Código impõe com a mesma força no último dia e no primeiro, e nada nele diz o que o encerraria. Aí acontece uma de duas coisas: a trava continua barrando trabalho que agora está certo e as pessoas passam a contorná-la, ou alguém a apaga — e o histórico mostra uma linha alterada, não a decisão, quem tinha autoridade para tomá-la, nem se ela era para ser permanente. Na Arroway o fim faz parte da regra: toda memória diz o que a aposentaria, e quando uma decisão nova substitui a antiga, a antiga sai da leitura com o motivo e o nome de quem decidiu.
Separe as regras pelo jeito como morrem, não pelo rigor
A pergunta útil não é se a regra importa o bastante para ser imposta, e sim o que faria ela deixar de ser verdade. Se só uma mudança na forma como o sistema é construído a encerra, ela é invariante e mora no código. Se ela acaba quando alguém decide o contrário — o cliente muda o contrato, a política é revista, o experimento termina —, ela é decisão, e precisa de dono, de fim e de um jeito de ser substituída sem ninguém sair caçando cópia. Muita regra é as duas coisas. Aí a trava impõe, e a memória carrega o que a trava não carrega: por que ela está ali, quem a pôs, e quando ela deve sair.
Como isso aparece na prática
Um time roda vários agentes contra um único ambiente de staging. Dois deploys chegam ao mesmo tempo e um corrompe o outro, então o time troca a regra escrita — nunca fazer deploy enquanto outro estiver rodando — por uma trava. Funciona, e ninguém pensa mais nisso. Quatro meses depois o staging vira um ambiente por branch. Deploys não colidem mais, mas a trava continua enfileirando todos, e os agentes esperam quarenta minutos atrás de trabalho que não tem nada a ver com o deles. O engenheiro que criou a trava mudou de time. A mensagem do commit diz “add deploy lock”. Ninguém sabe se é seguro tirá-la, então ninguém tira. Se a regra também existisse como decisão — imposta pela trava, registrada com “acaba quando o staging deixar de ser compartilhado” —, essa condição estaria ao lado da regra em toda leitura, e no dia em que o staging foi dividido, aposentar as duas seria uma linha para uma pessoa aprovar.
Perguntas que as pessoas fazem sobre isso
- Então devemos tirar as regras do código?
- Não. O que dá para tornar mecanicamente impossível deve continuar impossível, e a memória não compete com isso. O que sai do código é a parte que ele nunca guardou bem: o motivo, o dono e o fim. Trava com uma decisão registrada por trás é mais forte do que qualquer uma das duas sozinha — com a trava não se discute, e o registro diz quando ela perdeu a razão de existir.
- Não bastaria um comentário ao lado da trava dizendo quando removê-la?
- Bastaria em parte, e é melhor que nada. Mas comentário é um fim sobre o qual ninguém é consultado: só lê quem abrir aquele arquivo, ele não sabe dizer se continua certo, e mudá-lo exige o mesmo acesso que mudar o código. Na Arroway o fim viaja com a regra para toda leitura do projeto, feita por qualquer assistente em qualquer ferramenta conectada, e substituir a decisão é um ato visível, com nome e data — não um diff que alguém precisa ir procurar.
- Agente ignora instrução. Por que respeitaria uma regra só porque ela está na memória?
- Memória não é imposição, e não deve fingir que é. O que ela muda é se o agente teve a regra em mãos. A leitura de abertura é um primeiro passo obrigatório imposto pelas ferramentas, e não deixado a critério do agente, então a regra chega antes de o trabalho começar em vez de depender de algum arquivo ter sido carregado. Para as regras que nunca podem ser quebradas, isso sozinho não basta — e é exatamente por isso que essas também moram no código.
Onde isto se confere
Documentação do produto neste site (Como funciona, Instalar), as respostas sobre memória sem política de escrita, sobre memória desatualizada e sobre regra que escorrega algumas mensagens depois, e as regras de condição de fim, substituição e sanção da especificação sancionada do produto. A linha entre invariante e decisão é o argumento desta página, não um recurso do produto. Tudo o que está descrito aqui é comportamento que as ferramentas aplicam hoje, não roadmap.
https://www.arroway.app/pt-BR/answers/guardrails-in-code-dont-expire-sanctioned-rules-do