Automatizações de Agentes que Você Não Precisa Monitorar

Há alguns meses, eu estava mexendo no OpenClaw em um projeto paralelo descartável, apenas para ver do que ele era capaz. Em algum momento, eu disse a ele, em inglês simples, para fazer uma pequena tarefa recorrente para mim. Ele foi, escreveu um cron job, conectou o conector e foi isso.

Eu fiquei lá por um segundo. A coisa que minha última empresa passou semanas construindo no n8n, o agendamento, as integrações, a cola entre elas, estava ali. Porque o agente já tinha conectores e podia se comunicar com um agendador, toda a camada de integração que tornava uma ferramenta como o n8n valiosa havia evaporado silenciosamente. Você dizia o que queria e ele se configurava.

Então, o segundo pensamento chegou, e era o que importava. Eu nunca deixaria isso executar algo que realmente me importasse. Não sem supervisão, e definitivamente não em um negócio.

Essa lacuna é toda a história. O problema de configuração está quase resolvido. O problema de confiança não está. Este post é sobre a parte que está faltando, que comecei a chamar de supervisor.

O pipeline sem código que não era

Primeiro, um reconhecimento onde é devido. O n8n resolveu um problema real, e ainda é a ferramenta certa para muitos trabalhos. O trabalho recorrente precisa ser executado em um cronograma, sobreviver a reinicializações e continuar quando você não está assistindo. Essa é uma execução durável, e é genuinamente difícil. O n8n tornou isso acessível.

O problema apareceu em ambas as extremidades, a autoria e a execução.

Na minha última empresa, precisávamos automatizar o contato. Extrair prospects do CRM, decidir quem era inbound e quem era outbound, redigir uma mensagem personalizada para cada um, enriquecer com dados da web e enviar o e-mail. No papel, isso seria um pipeline limpo e não técnico que um não engenheiro poderia gerenciar.

Não ficou assim. Precisávamos de código para dividir e remodelar os fluxos de dados. As etapas do LLM estavam fortemente restritas, e os modelos continuavam retornando saídas que não podíamos usar diretamente, então tivemos que definir saídas de ferramentas estruturadas e adicionar etapas de análise apenas para transformar texto de volta em objetos que o pipeline pudesse processar. Além disso, a coisa era instável. A etapa de IA poderia expirar, ou não retornar nada, ou se comportar mal. O que foi vendido como um fluxo de trabalho sem código havia se tornado um processo muito técnico e muito frágil que alguém tinha que ficar cuidando.

A razão pela qual a autoria era dolorosa é a razão pela qual o modelo de fluxo de trabalho visual existe. Você tem que pré-especificar cada ramificação antes, porque não pode confiar que o tempo de execução improvisará. O gráfico fixa um comportamento que você não confia que seja flexível. Um agente capaz remove esse custo. Você descreve a tarefa uma vez, em palavras, e ele resolve os passos.

Mas o problema da execução não desaparece com isso. Essas ferramentas garantem execução durável para passos determinísticos, e uma etapa de LLM não é determinística. No momento em que uma se senta no meio do pipeline, as garantias nas quais você estava se apoiando param de valer, e é por isso que as nossas continuavam expirando e ficando silenciosas. Então, a autoria fica mais fácil e a execução mais difícil, e você fica precisando de um tempo de execução construído para trabalho não determinístico desde o início.

O que os agentes levaram e o que deixaram para trás

Os conectores de agentes levaram a vala do integrador. A parte difícil e defensável das ferramentas antigas era a longa lista de integrações e a fiação entre elas. Um agente com conectores e um agendador faz isso de graça, sob demanda, a partir de uma frase.

O que eles não lhe deram é a capacidade de se afastar.

Um agente local capaz fará um trabalho amplo para você. Mas para executá-lo sem supervisão, você tem duas opções, e ambas são ruins. Você deixa que ele peça permissão em cada passo, o que significa que você ainda está lá, então nada foi realmente descarregado. Ou você deixa que ele execute por conta própria e espera, o que é aceitável para um brinquedo e impensável para qualquer coisa que importe. Esses agentes também nunca foram projetados para rodar na nuvem sob um modelo real de permissões, limitado exatamente ao acesso que um único trabalho precisa.

Então, o gargalo se move. Não é mais a configuração, e não é mais a capacidade. O gargalo é você, assistindo. Execute uma automação e você pode ficar de olho nela. Execute dez ou vinte e ficar atento àquela que quebrou se torna um trabalho em tempo integral. Você se satura, não porque os agentes não podem fazer o trabalho, mas porque você não pode revisar tudo isso.

Essa é a parte que eu queria resolver.

O que é necessário para parar de assistir

A lista de coisas que precisam ser verdadeiras antes que você possa deixar um trabalho sozinho é curta e, na maioria das vezes, entediante. O trabalho precisa ser executado quando deve e falhar de forma barulhenta quando não pode. Ele deve ser limitado exatamente ao acesso que precisa e isolado, para que um trabalho que dá errado não possa vagar por coisas que nunca deveria tocar. E algo precisa observar cada execução e decidir, a cada vez, se deve escalá-la para você ou ficar em silêncio. Com código determinístico, o sucesso é um binário que você pode verificar: o teste passou ou não. Com um agente, não há tal critério rígido, então se uma execução realmente foi bem é um julgamento, não uma verificação. Os dois primeiros são requisitos básicos. O último é todo o jogo. É o que torna a revisão escalável, separando as execuções que você pode ignorar com segurança das poucas que realmente precisam de você.

E esse observador precisa ser separado do trabalhador. Um agente avaliando seu próprio trabalho tende a ser positivo, e é por isso que o recente trabalho de harness da Anthropic emparelha um gerador com um avaliador separado em vez de pedir a um agente para fazer ambos. O trabalhador quer terminar. O verificador precisa querer encontrar o problema.

Então eu construí esse observador

Ele se chama Golemry. É a camada que o agente local nunca teve: infraestrutura para o trabalho recorrente.

Você o adiciona ao agente que já usa como um servidor MCP. Você descreve uma tarefa recorrente em linguagem simples, seu agente configura o trabalho e, a partir de então, o trabalho é executado no Golemry, em um cronograma, limitado às suas ferramentas, isolado, com um supervisor revisando cada execução e puxando você apenas quando algo parece errado. Seu agente permanece a interface. Ele configura os trabalhos, verifica o que foi executado e lhe entrega a única coisa que precisa de você.

Aqui está o tipo de coisa que ele captura. Eu tinha um trabalho de pesquisa semanal que continuava me enviando uma visão geral normal enquanto o trabalho por trás dele silenciosamente se tornava raso. A saída nunca revelou isso, mas o supervisor lê a execução e não apenas o resultado, então ele capturou o raciocínio se tornando superficial e sinalizou o trabalho como desatualizado. Nada no e-mail jamais teria me contado isso.

Seu agente, sem a supervisão

Imagine o agente que você usa agora, conectores e tudo, lidando com sua rotina diária. Agora ele ganha uma nova habilidade. Qualquer coisa recorrente, a visão geral da pesquisa semanal, a busca por ideias e rascunhos de postagens, o relatório que você verificaria todas as manhãs, ele pode passar para algum