Agentes também precisam de fronteiras

Tire o vocabulário e um agente é um loop: observar, decidir, chamar uma ferramenta, repetir até terminar. Isso não é novo. Cron jobs, engines de workflow e loops de retry fazem isso há décadas, e a disciplina que construímos para eles, fronteiras, permissões, timeouts, idempotência, continua valendo. O que é novo é que a etapa de decisão é um modelo de linguagem, o que significa que o loop pode tomar ações que ninguém escreveu de antemão. Isso torna as fronteiras mais importantes, não menos.

Um agente é um loop com permissões

Quando reviso um agente, a primeira coisa que desenho não é o prompt. É a lista de ferramentas e, ao lado de cada uma, o que ela consegue tocar. Ler um documento. Buscar num índice. Enviar um e-mail. Escrever no banco. Chamar uma API de pagamento. Essa lista é a capacidade real do agente, independente do que o prompt diz que ele deveria fazer. Se uma ferramenta pode apagar registros, o agente pode apagar registros, e um input suficientemente estranho vai fazê-lo tentar em algum momento. Prompt é orientação. Ferramenta é permissão. Eu projeto a segunda e torço pela primeira.

O raio de dano de uma ferramenta

A regra que uso: cada ferramenta recebe a permissão mais estreita que permite ao agente fazer o trabalho, e toda ferramenta com efeito colateral é envolvida em algo que o agente não consegue contornar. Um agente de suporte que pode fazer reembolso recebe uma ferramenta de reembolso com teto, rate limit por cliente e log, não acesso ao serviço de billing. Um agente de código recebe uma working tree isolada, não o meu shell. Um agente de pesquisa recebe leitura num corpus, não a internet. Quando o agente se comporta mal, e vai, o dano é limitado pela ferramenta, não pelas boas intenções do modelo.

Fronteiras que coloco em todo agente

• Um orçamento: máximo de passos, máximo de tokens, máximo de tempo de relógio. O loop termina por construção, não por esperança.
• Ferramentas idempotentes com chaves, para que um passo repetido não repita o efeito colateral.
• Um portão humano em qualquer ação irreversível, com a ação proposta renderizada para uma pessoa aprovar.
• Inputs de ferramenta estruturados e validados em código antes da execução, porque o modelo vai produzir uma chamada malformada em algum momento.
• Um trace de cada passo, armazenado, para eu conseguir reproduzir o que ele decidiu e por quê.

Parar é uma feature

O agente mais perigoso que revisei era um que era muito bom em não desistir. Ele tentava de novo, reformulava, tentava outra ferramenta, tentava a primeira de novo com argumentos ligeiramente diferentes, enquanto fosse permitido. Numa tarefa só de leitura isso é simpático. Numa tarefa com efeitos colaterais é uma máquina de produzir duplicatas. Um agente precisa de uma noção clara de pronto, uma noção clara de travado e um caminho que termina perguntando a uma pessoa em vez de insistir. Prefiro um agente que para cedo e reporta a um que termina a qualquer custo.

As mesmas regras, com nomes mais antigos

Nada disso é exótico. Privilégio mínimo, retries limitados, compensação de efeitos colaterais, logs de auditoria, aprovação humana para ações irreversíveis. Aprendemos isso construindo sistemas de pagamento e pipelines de deploy, e aprendemos nos queimando. Agentes só tornam a lição urgente de novo, porque a coisa dentro do loop é criativa e as coisas em volta do loop é melhor que não sejam. Coloque a criatividade no meio e as fronteiras nas bordas, e pode deixar o modelo ser tão esperto quanto quiser.