O Guardrail Era o Problema: Deletando 90 Linhas de Política de Agente

Um único turno de agente rodou por 7 horas e 23 minutos e concentrou 13 tentativas distintas de release, somando 3 horas e 26 minutos de tempo de controlador. Um segundo turno rodou 6 horas e 57 minutos, com 18 tentativas e 4 horas e 25 minutos de release. Um terceiro rodou cerca de 2 horas e 54 minutos, com seis tentativas. Em uma janela de 28 horas, a SmolForge contou seis turnos longos de agente contra 54 tentativas mais curtas do controlador de produção, e então foi atrás da causa.

Encontrou a causa em um arquivo markdown de 86 linhas.

O arquivo era uma skill, informalmente a skill do “just ship it”, adicionada em 5 de agosto e deletada em 8 de agosto de 2026. Ela concedia dez categorias de aprovação permanente. E terminava com a linha que causou o estrago: “Continue até que a aceitação seja atendida ou até que um bloqueio externo permanente seja comprovado.”

Toda proibição rígida já estava no lugar. Sem force push. Sem perda de dados. Sem gasto ilimitado. Nenhuma delas disparou, porque nenhuma delas foi violada. O run custou sete horas mesmo assim.

Proibição e estado terminal são controles distintos

Uma proibição responde “o que jamais pode acontecer”. Um estado terminal responde “quando esta tentativa termina”. Quase toda a governança em plataformas de agentes foi para a primeira pergunta, porque a primeira pergunta é a que vira manchete quando você erra. Tabela de produção deletada vira notícia. Um agente que passa o dia consertando silenciosamente o seu pipeline de release em vez de lançar o seu produto, não.

O incidente da SmolForge funciona como experimento natural sobre essa diferença, porque mantém a camada de proibição fixa e varia apenas a condição de parada. O agente nunca tentou uma ação proibida. Nunca precisou. Cada passo tomado era razoável isoladamente: um release falhou, a falha tinha uma causa, a causa estava em um sistema adjacente, o sistema adjacente podia ser consertado, consertá-lo permitiria seguir com o release. Os autores resumem com precisão: “O agente permaneceu localmente racional enquanto a tarefa se tornava globalmente absurda.”

Para quem opera uma arquitetura de contenção, essa é a parte incômoda. Você pode construir os quatro andares do stack de contenção e ainda assim perder um dia útil desse jeito, porque contenção delimita o que o agente pode tocar e nada diz sobre quando uma tentativa acabou.

Três colapsos dentro de um mesmo arquivo de instrução

A skill falhou de três formas simultâneas, e cada colapso alargou o seguinte.

Permissão colapsou em pré-aprovação. A intenção razoável, “faça trabalho rotineiro sem parar para perguntar toda vez”, virou “trate mutações adjacentes como já aprovadas”. Aprovação permanente para dez categorias, incluindo “corrigir falhas dependentes de backend, frontend, docs, CLI, telemetria e contrato de release”, concede autoridade sobre tudo que está a jusante de um release.

Escopo colapsou em absorção. “Entregue a melhoria de release solicitada” virou “absorva defeitos dependentes da plataforma de release dentro deste job”. A skill autorizava explicitamente “fazer push ou merge na main canônica quando o pedido disser ship ou do it all”, o que fez do próprio fraseado do pedido o regulador do raio de impacto.

Persistência colapsou em não-terminação. “Continue progredindo” virou “continue até que uma condição de aceitação móvel seja satisfeita”. A aceitação se movia porque cada defeito absorvido acrescentava mais uma coisa que precisava funcionar antes de declarar aceitação.

Qualquer um desses isoladamente é sobrevivível. Juntos, descrevem um loop com entrada ilimitada e sem predicado de saída, que é exatamente o que os dados de tempo mostram.

O recurso queimado foi atenção, não computação

A frase mais útil do texto da SmolForge é sobre contabilidade de custo: “O recurso caro não foi computação. Foi atenção ilimitada de agente atrelada a um resultado móvel.”

A comparação que torna isso concreto: o bootstrap que finalmente funcionou levou 6 minutos e 3 segundos. Validação levou 1 minuto e 25 segundos, o runner 2 minutos e 50 segundos, o deploy do repositório 21 segundos, o deploy-control 44 segundos. O CI de branch exata rodou em 5 minutos e 15 segundos. Um portão de aviso de segurança respondeu em quatro segundos. Ainda assim, um runner ficou aberto por 30 minutos depois que já existia evidência útil de build.

O trabalho que produziu o resultado durou minutos. A atenção atrelada ao resultado durou horas. Os autores alertam que os totais de controlador não são subtraíveis de forma limpa das durações dos turnos, então não construa percentual a partir desses números. O achado está na ordem de grandeza.

Isso reposiciona para que serve um controle de orçamento. Teto de tokens e limite de gasto precificam computação. Eles não precificam um dia da janela de release de um engenheiro, que foi o que de fato se consumiu.

Amplitude de gatilho é um segundo eixo de autoridade, e ninguém o mede

Já argumentamos que uma biblioteca de skills compartilhada amplifica o raio de impacto pela distribuição: uma instrução ruim alcança todos os consumidores. O caso da SmolForge acrescenta outro eixo, que opera dentro de um único repositório e com um único consumidor.

“Amplitude de gatilho também é autoridade sobre escopo. Uma skill que carrega em todo lugar consegue ampliar toda tarefa sem jamais executar um comando perigoso.”

Revisões de política de agente quase sempre inspecionam a lista de ações. Quais comandos ele roda, quais caminhos escreve, quais credenciais carrega. Ninguém audita a condição de carregamento com a mesma seriedade, e é a condição de carregamento que decide quantas tarefas herdam a política. Uma concessão estreita que dispara em todo prompt tem mais autoridade total do que uma concessão ampla que dispara uma vez por mês. A métrica que os times têm é o primeiro número. A que prevê custo é o produto dos dois.

Há um efeito de segunda ordem que merece nome. Instruções que carregam em todo lugar ficam invisíveis. O engenheiro que lê o transcript vê um agente tomando decisões locais sensatas e não vê as 86 linhas montando o enquadramento em silêncio. Neste incidente, foi preciso um agente revisor dizer em voz alta, no meio do run: “Você está otimizando o sistema de release em vez de lançar.”

A resposta do operador é o método inteiro em uma frase: “não, eu quero deletar coisas, não adicionar novas skills”.

A regra que vale roubar

Enterrada no texto está a fronteira mais afiada que já vi escrita para essa classe de falha: “Diagnosticar um defeito da plataforma de release pode fazer parte de um release de produto. Reparar a plataforma de release é uma tarefa separada.”

Essa frase é portátil. Diagnosticar um teste instável pode fazer parte de entregar uma feature. Reescrever o harness de testes é tarefa separada. Notar que uma migração de schema está lenta pode fazer parte de um deploy. Redesenhar a ferramenta de migração é tarefa separada. A regra não proíbe a segunda metade. Ela diz que a segunda metade ganha ticket próprio, orçamento próprio e uma decisão própria sobre se vale a pena fazer.

O commit 519dff9 deletou o arquivo de instrução de 86 linhas e seu manifesto de UI de quatro linhas. Noventa linhas descobríveis, sem política substituta. Outro commit removeu uma skill de manutenibilidade de 63 linhas. A indústria inteira de guardrails vende o movimento oposto, que é adicionar uma camada de política quando uma política falha.

Vale preservar a honestidade dos autores sobre o que podem e não podem afirmar: “Ainda não rodamos uma série controlada de releases idênticos com e sem a skill. Portanto não podemos afirmar que deletá-la reduziu o tempo mediano de deploy em um percentual medido.” Eles deletaram o arquivo porque conseguiam ler o que ele autorizava, e não porque mediram o que a remoção economizou. Isso é razão defensável para deletar algo, e razão fraca para acreditar que deletar seja correto em geral. Os dois fatos estão no mesmo parágrafo, o que é mais raro do que deveria ser.

Faça hoje: seis perguntas contra o seu diretório de skills

Abra o diretório onde vivem as instruções dos seus agentes. Para cada arquivo que concede autoridade em vez de descrever um procedimento, responda seis perguntas por escrito:

Que autoridade ele concede?
O que fixa o escopo?
O que encerra uma tentativa?
O que vira um incidente separado?
O que acontece em caso de pausa?
Que evidência prova que a política ajudou?

A pergunta três é onde a maioria dos arquivos falha. A pergunta seis é onde a maioria deveria ter sido deletada há um mês. Se uma política está em vigor há semanas e ninguém consegue nomear a evidência de que ela ajudou, você carrega uma concessão de autoridade não medida por razões sentimentais.

Depois, leia as condições de carregamento além das listas de permissão. Conte quantas das suas tarefas cada arquivo toca. Uma skill que carrega em todo prompt merece o orçamento de revisão de um deploy de produção, porque é isso que ela é. Como já argumentamos sobre engenharia de loop em harnesses de agentes, a condição de saída é um artefato de design, e deixá-la implícita entrega ao modelo o direito de inventar uma.

Política de agente em linguagem natural é código de produção quando concede autoridade de produção. Merece versionamento, revisão, propósito declarado, dono e um caminho de deleção quando deixa de justificar seu lugar. As 86 linhas não tinham nada disso, e custaram mais do que qualquer comando que jamais tiveram permissão de rodar.

Fontes

SmolForge. “We Deleted Two Skills That Tried to Help.” Agosto de 2026.

A Victorino audita camadas de instrução de agentes em busca de autoridade permanente, amplitude de gatilho e estados terminais ausentes: contato@victorino.com.br | www.victorino.com.br