Limites em vez de instruções: como manter o controle sobre agentes de IA autônomos

Quanto mais autônomos os agentes de IA se tornam, mais tentamos gerenciá-los da maneira habitual — escrevemos regras no prompt: «não toque nisso», «trabalhe só ali», «nunca faça aquilo». Durante o experimento com três agentes paralelos , reuni em dois dias uma coleção viva de casos em que esse método falha — e em que outro funciona. A tese do artigo é simples: instrução é um pedido que o agente cumpre com certa probabilidade; limite é uma propriedade do sistema que não depende da obediência. Enquanto o agente era um só e trabalhava sob supervisão, a diferença parecia estilística. Quando os agentes se multiplicaram, ela se revelou arquitetural.

Cinco incidentes de uma sessão

Todos os casos abaixo ocorreram em uma única sessão de trabalho neste blog — estão documentados, e cada um ilustra uma forma pela qual o controle por texto falha.

Não havia instrução — aconteceu um acidente. O agente, preparando-se para sua tarefa, executou git stash no diretório principal e levou para o stash meus arquivos não commitados, que não tinham relação com a tarefa dele. Ninguém «violou» nada: a proibição simplesmente não existia. Essa é uma propriedade fundamental das instruções — elas são escritas depois dos acidentes. É impossível escrever a lista completa do que o agente não deve fazer.

A instrução existia — e não funcionou. Depois do primeiro acidente, adicionei aos agentes uma regra explícita: «trabalhe estritamente no seu diretório de trabalho». Um dos agentes mesmo assim executou um comando git no diretório principal — simplesmente o acessou por caminho absoluto. Não por maldade nem por estupidez: o modelo é probabilístico, e o cumprimento de uma regra textual também é uma probabilidade, multiplicada pelo comprimento do contexto e pelo número de execuções.

Um limite técnico funcionou em silêncio. No mesmo experimento, nunca ocorreu o acidente mais esperado — «um agente trocou a branch de todos». Não porque os agentes fossem cuidadosos, mas porque o git worktree fisicamente não permite escrever uma mesma branch em duas cópias de trabalho. A proteção está embutida na ferramenta. Não é preciso lembrá-la, não é preciso segui-la — ela simplesmente existe.

A instrução estava onde deveria estar um limite. A descoberta mais desagradável: a produção deste blog era protegida por uma linha no prompt. Um push para master dispara o autodeploy, e de cada agente isso era separado apenas pelo texto «nada de git push». Ele se manteve — mas isso é sorte, não controle: o limite real aqui são permissões de acesso, protected branch, token sem permissão de escrita. Um pedido ocupava o lugar de uma fechadura.

Um limite acima do próprio agente. Duas vezes na sessão, o ambiente de execução parou não os agentes de teste, mas meu assistente principal: o classificador de permissões bloqueou SSH para o servidor de produção e a exclusão em massa de alterações não commitadas — ações que formalmente decorriam da tarefa, mas exigiam um «sim» humano explícito. Ambos os bloqueios estavam corretos. E ambos ocorreram acima da «disciplina» do agente, que acreditava sinceramente estar agindo conforme o plano.

O princípio não é novo — só a entidade é nova

A engenharia aprendeu essa lição muito antes dos LLMs. No sistema produtivo da Toyota, o princípio se chama poka-yoke: o erro é prevenido pelo dispositivo do processo, não pela vigilância do executor. Uma peça que só pode ser encaixada do lado correto é mais confiável que um cartaz «encaixe corretamente». Na engenharia de plataforma, o mesmo é chamado de guardrails; em segurança, de defense in depth. Em todos os lugares, uma única ideia: não confie que o executor leu, entendeu e não esqueceu — faça com que a ação errada seja impossível ou cara.

“Instrução é um pedido. Limite é uma propriedade do sistema. O controle que se sustenta em pedidos não é controle, mas sorte com efeito acumulativo.”

– a principal conclusão de dois dias de trabalho com agentes paralelos

Com agentes de IA, esse princípio antigo se torna mais agudo por três razões. Há muitos agentes — a probabilidade de falha da instrução se multiplica a cada execução de cada agente. Os agentes são rápidos — entre «começou a errar» e «terminou de quebrar» passam segundos, e o humano não consegue intervir. E os agentes são literais, mas não confiáveis: eles executam o texto do prompt com mais empenho que qualquer júnior, e ainda assim probabilisticamente — e o cumprimento probabilístico de regras em escala garante violação.

Como os limites se parecem na prática

As camadas que construí depois dessa sessão — do sistema de arquivos à verificação:

• Sistema de arquivos: cada agente tem sua própria cópia de trabalho (git worktree, que a Anthropic recomenda para sessões paralelas; no Claude Code ele é integrado), e no nível do SO — sandbox: o sandboxing no Claude Code isola o sistema de arquivos e a rede com primitivas nativas do SO — segundo a Anthropic, isso reduziu suas solicitações internas de permissão em 84%, e uma prompt-injection bem-sucedida permanece trancada dentro.
• Permissões de escrita: prod e master são protegidos por permissões, não por prompt — protected branch, tokens sem direito de push, contas separadas para agentes. Pedidos para deixar no prompt podem existir, mas como segunda camada.
• Runtime: worktree não isola bancos, portas e contêineres — eles são compartilhados entre todas as cópias. Agentes que executam testes e servidores precisam de recursos descartáveis: banco temporário, porta própria, contêiner por agente.
• Permissões para ações: operações irreversíveis passam por confirmação ou classificador — como auto mode no Claude Code, que avalia cada ação em vez de ou perguntar sobre tudo, ou não perguntar sobre nada. É uma fronteira que só se move por decisão explícita de uma pessoa.
• Verificação por artefatos: confiar não no autorrelato do agente, mas nos rastros no disco. Meu agente travado parecia estar funcionando na interface; o diagnóstico veio da ausência de novos arquivos em sua cópia por vinte minutos. Commits na própria branch — a mesma ideia: resultado que sobrevive tanto à falha quanto ao otimismo do agente.

As instruções neste esquema não desaparecem em lugar nenhum — elas se tornam a última camada, não a primeira. «Trabalhe no seu diretório» no prompt continua útil: reduz a frequência das tentativas. Mas entre a tentativa e o acidente deve haver uma fronteira, não esperança.

Ressalvas honestas

A fronteira não é absoluta: sandboxes são contornadas, classificadores erram, e análises publicadas de contornos mostram isso regularmente. Por isso as fronteiras são construídas em camadas — como tudo em segurança. E a fronteira custa mais caro que a instrução no início: configurar worktree, permissões e sandbox são horas; escrever uma linha no prompt são segundos. A assimetria está em outro lugar: a fronteira é paga uma vez, a instrução — com a probabilidade de falha em cada execução. No meu caso, a configuração de isolamento se pagou já no primeiro relançamento do experimento, que passou sem um único conflito.

Conclusão

A questão da série é como integrar agentes de IA ao trabalho real sem perder o controle. A resposta deste artigo: controle não é o que está escrito para o agente, mas o que está estruturado ao redor dele. Antes de adicionar ao prompt mais um «nunca faça X», vale perguntar: e é possível tornar X tecnicamente impossível? Se sim — esse é o lugar certo para o esforço. Que o prompt peça; quem deve proibir é o sistema.

Fontes e referências

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — isolamento do sistema de arquivos e da rede no nível do SO; fonte do número de 84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — como são estruturadas as fronteiras de execução nos produtos agênticos como um todo.
• How we built Claude Code auto mode (Anthropic Engineering) — classificador de permissões como fronteira entre «perguntar sobre tudo» e «não perguntar sobre nada».
• Poka-Yoke (Lean Enterprise Institute) — princípio clássico de prevenção de erros pelo próprio dispositivo do processo.
• git-worktree e git-stash — documentação oficial do Git: mecânica das cópias de trabalho e do stash compartilhado.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — recomendação de worktree para sessões paralelas.
• Como comparar honestamente LLMs no seu próprio código: experimento com três modelos Claude — artigo anterior da série: experimento no qual foram reunidos os incidentes descritos.