Como os agentes OpenClaw substituem funcionários, não tarefas
Estou construindo agentes de IA há meses. Pipelines personalizados, automações Claude Code, sistemas multiagentes – toda a pilha. E na maior parte desse tempo, eu os usei de maneira errada.
Não está errado da maneira óbvia. Meus agentes trabalharam. Eles completaram tarefas. Eles produziram resultados. Mas toda vez que eu precisava fazer algo, eu tinha que sentar, escrever o prompt, cuidar da execução, revisar o resultado e fazer tudo de novo no dia seguinte. Eu automatizei o trabalho, mas não o fluxo de trabalho. O agente foi uma ferramenta que peguei e larguei. Não é um membro da equipe que apareceu e fez seu trabalho.
Então assisti ao resumo de Brian Castle sobre como ele administra seus negócios com agentes OpenClaw, e algo clicou que eu estava perdendo. A distinção é aparentemente simples, mas mudou completamente a forma como penso sobre a delegação de IA: há uma enorme diferença entre dar uma tarefa a um agente e dar um trabalho a um agente.
Uma tarefa é “resumir este artigo”. Um trabalho é “todas as manhãs, às 7h, examinar essas doze fontes do setor, identificar os três anúncios mais relevantes, redigir um briefing e enviá-lo para o meu Telegram”. Um exige que eu apareça e pergunte. O outro exige que eu configure uma vez e depois saia do caminho.
Essa reformulação – de tarefas para empregos – desbloqueou algo contra o qual eu vinha lutando há semanas. E vale a pena entender em detalhes o sistema que Brian construiu em torno dele, quer você use OpenClaw ou qualquer outra estrutura de agente. A transferência de princípios.
Aqui está o que aprendi, o que comecei a implementar e onde essa abordagem falha de uma forma que ninguém fala.
Por que a maioria das pessoas atinge o teto com agentes de IA
Há um padrão que vejo constantemente – em meu próprio trabalho e em todas as comunidades de criadores de IA das quais faço parte. Alguém descobre agentes de IA. Eles ficam entusiasmados. Eles automatizam algumas coisas. E então... eles estagnaram.
O platô acontece porque a delegação baseada em tarefas não é escalonável. Cada vez que você delega uma tarefa única, você paga um custo de configuração: configuração de contexto, elaboração imediata, revisão de resultados. Para uma única tarefa complexa, esse custo vale a pena. Mas quando você delega vinte coisas por dia, cada uma exigindo um novo contexto, você basicamente cria uma segunda tarefa para si mesmo: gerenciar os agentes.
Eu bati nessa parede com força por volta do terceiro mês. Eu tinha agentes que podiam escrever, pesquisar, analisar e codificar. Mas eu passava duas horas por dia apenas orquestrando-os. Enfileirar o trabalho, verificar resultados, executar novamente tentativas fracassadas. Minha “automação” se transformou em uma lista de tarefas muito sofisticada que ainda exigia de mim cada passo.
Brian Castle enquadra esse problema perfeitamente: você está tratando os agentes como empreiteiros que você contrata para um trabalho, em vez de funcionários que você contrata para uma função. Os empreiteiros precisam de um novo escopo de trabalho a cada compromisso. Os funcionários aprendem o trabalho uma vez e depois o executam repetidamente, melhorando ao longo do tempo com o mínimo de supervisão.
A mudança do pensamento do contratante para o pensamento do funcionário muda tudo sobre como você arquiteta seus sistemas de agentes. E tudo começa com uma pergunta que a maioria dos criadores de IA nunca faz: quais são os empregos recorrentes na minha empresa?
Não tarefas. Empregos. Trabalho previsível e repetido que acontece em uma cadência conhecida – diariamente, semanalmente, mensalmente – e segue sempre um processo consistente.
Quando sentei e mapeei isso para meu próprio trabalho, descobri dezessete trabalhos recorrentes que vinha fazendo manualmente. Dezessete. Varredura de pesquisa, elaboração de conteúdo, resumos de revisão de código, relatórios de atualização de clientes, monitoramento de boletins de segurança, rastreamento de concorrentes. Todas as coisas que fiz aproximadamente no mesmo cronograma, seguindo aproximadamente o mesmo processo, produzindo aproximadamente o mesmo tipo de resultado.
Dezessete empregos que não precisavam de mim. Eles precisavam de um agente que conhecesse o processo e chegasse na hora certa.
Mas saber que você precisa de agentes recorrentes e realmente construir um sistema que os execute de maneira confiável são dois problemas muito diferentes. É aqui que a estrutura técnica de Brian se torna interessante — e onde comecei a ver lacunas em minha própria configuração que não havia reconhecido.
A arquitetura por trás de uma equipe de agentes autônoma
O sistema de Brian é executado em uma pilha de componentes criados especificamente, e a compreensão de como eles se encaixam revela princípios que se aplicam independentemente de suas ferramentas específicas.
A base é o próprio OpenClaw, rodando em um Mac Mini. Pense nela como uma agência de empregos – ela hospeda e executa os agentes. Mas o OpenClaw sozinho não resolve o problema de orquestração. Uma plataforma de agente oferece trabalhadores. O que você precisa é de um sistema de gerenciamento.
É aí que entra o BMHQ (Builder Methods HQ). É um aplicativo Rails personalizado que Brian construiu como seu controle de missão. Imagine um quadro Kanban projetado especificamente para gerenciamento de agentes de IA: modelos de tarefas, agendamento, expedição, rastreamento de status e revisão de resultados — tudo em um único painel.
Aqui está o que acontece na prática. Uma tarefa recorrente – digamos, “digitalizar as notícias do setor de IA e produzir um briefing diário” – existe como modelo no BMHQ. O agendador o aciona no horário configurado. O código de despacho personalizado envia a tarefa diretamente ao agente atribuído através do gateway do OpenClaw. O agente pega, executa, produz a saída e envia uma notificação de conclusão via Telegram.
Nenhum humano no circuito para execução. O humano analisa os resultados quando for conveniente, não quando o agente precisar de permissão para prosseguir.
Quero me deter no artigo do Telegram porque é sutilmente brilhante. A maioria das configurações de agentes que vi (incluindo a minha, até recentemente) exige que você verifique um painel ou abra um terminal para ver o que seus agentes produziram. Os agentes de Brian enviam notificações e links diretos para ele por meio do Telegram. Os agentes vêm até ele. Ele não vai até eles.
Isso inverte o modelo de atenção. Em vez de gerenciar ativamente os agentes, você recebe passivamente seus resultados e só interage quando algo precisa de correção. Essa é a diferença entre gerenciar uma equipe e microgerenciar uma equipe. E é a escolha arquitetônica que torna sustentáveis mais de vinte empregos recorrentes de agentes para uma única pessoa.
A camada de gerenciamento de saída é igualmente cuidadosa. Os agentes produzem arquivos de descontos armazenados em pastas compartilhadas do Dropbox, acessíveis por meio de um editor de descontos personalizado chamado Brainown. Cada notificação do Telegram inclui um link direto para o arquivo relevante. Um toque: você está lendo a saída do agente. Quer editá-lo? Você já está no editor.
O que me impressionou nesta arquitetura não é a sua complexidade – é a sua especificidade. Cada componente existe para resolver um ponto de atrito que surgiu da execução real de agentes em escala. O aplicativo Rails personalizado, a integração do Telegram, o editor de descontos – nada disso é tecnicamente impressionante isoladamente. Mas juntos, eles eliminam a sobrecarga que faz com que a maioria das pessoas abandone os fluxos de trabalho dos agentes depois que o entusiasmo inicial passa.
A pergunta que eu sempre voltava: eu poderia construir algo equivalente? E o mais importante, devo? Voltaremos a isso.
Habilidades: a parte que todos erram
É aqui que a estrutura de Brian diverge de como a maioria das pessoas — inclusive eu, até recentemente — configura agentes de IA. E, honestamente, este pode ser o conceito mais transferível de todo o sistema.
Quando você configura um agente para executar uma tarefa recorrente, o instinto natural é incorporar todas as instruções diretamente no prompt da tarefa. "Aqui está o que fazer, aqui como formatá-lo, aqui está onde salvá-lo, aqui está o que evitar." Um grande prompt que contém tudo.
O problema: quando você precisa atualizar o processo, você precisa encontrar e modificar todas as tarefas que fazem referência a essas instruções. Tem dez tarefas recorrentes que seguem a mesma metodologia de pesquisa? Agora você tem dez lugares para fazer a mesma edição. Perca um e seus agentes estarão executando processos inconsistentes.
A solução de Brian é o que ele chama de Skills: documentação de processo modular armazenada como arquivos markdown separados com scripts incorporados e materiais de referência. As tarefas não contêm as instruções. Eles fazem referência a uma habilidade.
O arquivo de habilidades é a única fonte de verdade sobre como um tipo específico de trabalho deve ser realizado. Precisa mudar o processo de pesquisa? Atualize um arquivo de habilidade. Cada tarefa que faz referência a ele usa automaticamente o processo atualizado em sua próxima execução.
Se você já trabalhou com engenharia de software, este é o princípio DRY (Don't Repeat Yourself) aplicado ao gerenciamento de agentes. E é uma daquelas ideias que parece óbvia em retrospectiva, mas que muda tudo na prática.
Implementei uma versão disso em minha própria configuração quarenta e oito horas depois de assistir ao colapso de Brian. Meu agente de pesquisa de conteúdo de IA costumava ter um prompt de 2.000 tokens incorporado em cada configuração de tarefa. Agora ele faz referência a um arquivo content-research-skill.md que reside em um diretório compartilhado. Quando percebi que o agente estava constantemente faltando dados de preços dos concorrentes em seus resultados de pesquisa, atualizei um arquivo. Na manhã seguinte, todas as três tarefas de pesquisa que fazem referência a essa habilidade produziram resultados que incluíam análise de preços.
Uma edição. Três resultados melhorados. Anteriormente, seriam três revisões imediatas separadas, três testes separados e provavelmente um que esqueci de atualizar até perceber a inconsistência uma semana depois.
As habilidades também criam um ciclo natural de melhoria. Ao revisar a saída de um agente e encontrar uma lacuna, você atualiza a habilidade. A atualização se propaga para todas as execuções futuras. Com o tempo, o documento de habilidades torna-se cada vez mais refinado – um manual de operações em evolução que captura o conhecimento acumulado sobre como um tipo específico de trabalho deve ser realizado.
Há um princípio mais profundo aqui que se aplica além dos agentes de IA. Qualquer processo repetível que não esteja documentado em um local único e editável será desviado. Os agentes não ficam entediados e economizam como os humanos fazem, mas seguirão instruções desatualizadas com perfeita consistência se você não mantiver a fonte da verdade.
A abordagem baseada em habilidades também torna muito mais fácil integrar novos agentes ou trocar o modelo subjacente. Seu conhecimento do processo reside nos arquivos de habilidades, e não na configuração de qualquer agente específico. Mudar de um modelo para outro? Aponte o novo agente para as mesmas habilidades. Seu conhecimento institucional é transferido instantaneamente.
Esse conceito por si só — separar a documentação do processo da execução da tarefa — valeu mais para mim do que qualquer ferramenta específica da pilha de Brian. E isso se aplica quer você esteja usando OpenClaw, agentes Claude Code, LangChain, CrewAI ou qualquer outro.
Se você está acompanhando e concordando, está pronto para a parte em que explico o que aconteceu quando tentei implementar tudo isso. Spoiler: não foi tão suave quanto estou fazendo parecer.
O que eu construí (e o que quebrou)
Passei um fim de semana construindo minha própria versão do sistema de Brian. Não é um clone — não preciso de um aplicativo Rails personalizado (ainda) — mas um equivalente funcional usando ferramentas que eu já tinha.
Minha pilha: agentes Claude Code para execução. Um agendador Python simples usando APScheduler para envio de tarefas recorrentes. Arquivos de habilidade Markdown em um diretório compartilhado. Bot do Telegram para notificações. Cofre de obsidiana para armazenamento e revisão de saída.
Primeiro dia: configurei cinco trabalhos recorrentes. Varredura matinal da indústria. Resumo diário de commit de código em meus repositórios ativos. Análise competitiva duas vezes por semana para um projeto de cliente. Relatório semanal de status do pipeline de conteúdo. Compilação mensal de boletins de segurança para conteúdo xcybersecurity.io.
Dia dois: três dos cinco trabalhos foram executados com êxito na primeira execução automatizada. A análise da indústria produziu um briefing limpo. O resumo do commit do código era preciso e bem formatado. O modelo de relatório semanal funcionou perfeitamente.
A análise competitiva falhou porque o arquivo de habilidade fazia referência a uma fonte de dados que exigia autenticação que eu não havia configurado no ambiente do agente. A culpa foi minha – a documentação do processo estava incompleta porque eu estava executando essa etapa manualmente sem perceber que era uma etapa.
O trabalho do boletim de segurança produziu resultados, mas era lixo. O arquivo de habilidades era muito vago sobre o que constitui um evento de segurança “notável”, e o agente interpretou essa ambiguidade incluindo tudo – dezessete páginas de cada CVE publicado naquele mês. Eu precisava definir critérios de filtragem explícitos: limites de gravidade, categorias de tecnologia afetadas, relevância para nossa base de clientes.
Ambas as falhas me ensinaram a mesma lição: as habilidades precisam ser mais explícitas do que você pensa. Quando você mesmo realiza um trabalho, carrega conhecimento implícito sobre dezenas de microdecisões que toma inconscientemente. O agente não tem conhecimento implícito. Cada critério de decisão precisa estar explícito no arquivo de habilidade, ou o agente irá adivinhar (mal) ou incluir tudo (desperdício).
No quinto dia, todos os cinco trabalhos estavam funcionando de forma confiável. Eu adicionei mais dois. No décimo dia, eu tinha nove trabalhos de agente recorrentes em execução com supervisão mínima. Minha rotina matinal mudou de “sentar e começar a delegar” para “abrir o Telegram, revisar o que meus agentes produziram durante a noite, sinalizar qualquer coisa que precise de revisão”.
A economia de tempo foi real, mas não onde eu esperava. O tempo real de execução economizado foi talvez de noventa minutos por dia – significativo, mas não transformador. O ganho real foi cognitivo. Parei de carregar dezessete tarefas recorrentes na minha fila mental. Meu cérebro não estava monitorando o que precisava acontecer hoje porque o sistema estava monitorando. Isso liberou largura de banda mental para o trabalho que realmente exige de mim - decisões de arquitetura, conversas com clientes, solução criativa de problemas.
Aqui está o número que mais me surpreendeu: depois de duas semanas, revisei cerca de setenta resultados de agentes. Desses, cinquenta e oito não exigiram nenhuma edição. Nove precisavam de pequenas correções. Três precisavam de um retrabalho significativo. Isso representa uma taxa de sucesso totalmente autônoma de 83% e uma taxa de 96% de resultados que podem ser usados com no máximo pequenos ajustes.
Não é perfeito. Mas considere a alternativa: eu mesmo realizar todas essas setenta tarefas. Os agentes não estão substituindo meu julgamento. Eles estão substituindo a execução na qual meu julgamento não precisa estar envolvido.
A economia sobre a qual ninguém fala
Brian destaca um ponto que merece mais atenção: a economia da contratação de agentes de IA é fundamentalmente diferente da contratação de humanos.
Com um funcionário humano, existe uma carga de trabalho mínima viável que justifica o custo. Você não contrata um pesquisador em tempo integral para fazer duas horas de pesquisa por semana. O salário, os benefícios, as despesas administrativas – nada disso faz sentido abaixo de um certo limite de trabalho recorrente.
Os agentes de IA não têm carga de trabalho mínima viável. Um agente que executa uma tarefa por dia custa alguns centavos em tokens de API. Um agente que executa vinte tarefas por dia custa alguns dólares. Não há salário, benefícios ou tempo de integração além da configuração inicial de habilidades.
Isso muda o cálculo para o qual vale a pena delegar funções. Tarefas que nunca justificariam a contratação de um humano – porque o volume é muito baixo ou a frequência é muito esporádica – justificam absolutamente a implantação de um agente.
Analisei os números dos meus nove empregos recorrentes de agente. Custo total mensal do token para todos os agentes: aproximadamente US$ 34. Tempo total que esses trabalhos levariam para serem realizados manualmente: aproximadamente 45 horas por mês. Mesmo avaliando meu tempo em modestos US$ 50/hora, isso representa um valor de US$ 2.250 contra US$ 34 em custos de infraestrutura.
A proporção fica ainda mais atraente à medida que você aumenta. Brian executa dezenas de trabalhos recorrentes de agente. Seus custos de infraestrutura são mais altos – ele está executando um Mac Mini dedicado, pagando pelo OpenClaw, mantendo aplicativos personalizados – mas o custo por trabalho permanece insignificante em comparação com o que esse trabalho custaria em mão de obra humana.
Há um problema, no entanto. O custo de configuração é real. Brian construiu aplicativos Rails personalizados. Passei um fim de semana codificando um agendador e configurando integrações. Escrever bons arquivos de habilidades leva horas de iteração por trabalho. O investimento inicial é medido em tempo de engenharia, não em dólares, e para usuários não técnicos, esse investimento pode ser proibitivo.
Esta é a compensação honesta: sistemas recorrentes de agentes de IA economizam muito tempo em escala, mas exigem um esforço real de engenharia para serem configurados corretamente. As pessoas que mais se beneficiam são os construtores que podem escrever suas próprias ferramentas – que é exatamente o público de Brian e, francamente, o meu também.
Se você não consegue construir seu próprio sistema de agendamento e despacho, você depende de quaisquer ferramentas de orquestração disponíveis no mercado. Neste momento, no início de 2026, essas ferramentas estão a melhorar rapidamente, mas ainda apresentam lacunas significativas em comparação com soluções personalizadas. Essa lacuna será fechada. Mas hoje, os maiores retornos vão para as pessoas que conseguem construir a sua própria infra-estrutura.
O que eu faria de diferente começando do zero
Após duas semanas de execução deste sistema, eis o que eu gostaria de ter sabido no primeiro dia.
Comece com três empregos, não nove. Eu estava entusiasmado e sobrecarregado. Três trabalhos bem configurados com arquivos de habilidades sofisticados ensinam mais do que nove trabalhos configurados às pressas. Acerte o ciclo de feedback — execução, revisão, refinamento de habilidades — antes de escalar.
Escreva arquivos de habilidades como se estivesse treinando alguém que nunca fez o trabalho. Cada suposição que você deixar implícita surgirá como um modo de falha. Documente os critérios de decisão, os casos extremos, as coisas “óbvias” que você faz sem pensar. O agente precisa de tudo isso.
Crie primeiro a camada de notificação. Antes de agendar, antes de enviar, antes de qualquer outra coisa — configure como seus agentes se comunicarão com você. Se você não conseguir ver facilmente o que eles produziram, você não revisará os resultados de forma consistente, e os resultados não revisados significam processos não melhorados.
Não crie ferramentas personalizadas antes de validar o fluxo de trabalho manualmente. Eu poderia ter economizado seis horas executando meus primeiros cinco trabalhos com envio manual (apenas enviando a tarefa para o agente dentro do cronograma) antes de criar o agendador automatizado. A execução manual teria detectado a lacuna de autenticação e o vago arquivo de habilidades antes de eu investir na automação de processos interrompidos.
Reserve duas horas de refinamento de habilidades por trabalho na primeira semana. Este não é um sistema do tipo "configure e esqueça". As primeiras cinco a dez execuções de qualquer trabalho recorrente revelarão lacunas na documentação de suas habilidades. Planeje essa iteração. Os arquivos de habilidades que funcionaram perfeitamente no décimo quarto dia começaram como rascunhos medíocres no primeiro dia.
Brian defende a construção de suas próprias ferramentas usando Claude Code, e eu concordo – mas com a ressalva de que você deve validar o fluxo de trabalho antes de otimizar as ferramentas. Construa a coisa certa e depois construa bem. Não o contrário.
Panorama geral: Agentes de IA como infraestrutura, não como recursos
Aqui está o que está comigo desde que comecei a executar este sistema.
A maioria das conversas sobre agentes de IA concentra-se no que eles podem fazer. Eles podem escrever código? Eles podem analisar dados? Eles podem gerar conteúdo? Essas são questões de capacidade. Elas são importantes, mas não são mais as questões mais importantes.
A questão mais importante é: eles podem aparecer de forma confiável, todos os dias, e fazer um trabalho que você teria que fazer sozinho ou contratar alguém para fazer?
Essa é uma questão de infraestrutura. E requer pensamento de infraestrutura — agendamento, monitoramento, documentação de processos, gerenciamento de resultados, melhoria contínua. Os mesmos sistemas enfadonhos, mas essenciais, que fazem qualquer equipe funcionar.
A estrutura de Brian me chamou a atenção porque trata os agentes de IA como infraestrutura organizacional, em vez de ferramentas de produtividade individuais. Os agentes não o tornam mais produtivo em sua mesa. Eles cuidam do trabalho que acontece quer ele esteja em sua mesa ou não. Sua manhã não começa com “o que devo delegar hoje?” Começa com "o que minha equipe produziu durante a noite?"
Essa mudança mental – da delegação ativa para a revisão passiva – é o verdadeiro desbloqueio. E não requer OpenClaw especificamente, ou um aplicativo Rails personalizado, ou qualquer ferramenta específica. É necessário pensar nos agentes de IA da mesma forma que você pensaria na construção de uma equipe: definir as funções, documentar os processos, configurar canais de comunicação, revisar o trabalho e melhorar continuamente.
Ainda estou no início desta jornada. Nove empregos recorrentes, US$ 34 por mês, taxa de sucesso autônomo de aproximadamente 83%. Esses números irão melhorar à medida que meus arquivos de habilidades amadurecerem. Adicionarei mais empregos à medida que identificar trabalhos mais recorrentes que não precisam do meu envolvimento direto.
Mas a questão fundamental já foi respondida para mim. Os agentes de IA não são apenas ferramentas que pego quando preciso de ajuda. Eles são membros da equipe que realizam trabalho real, dentro de um cronograma real. A única coisa que faltava era o sistema para tornar isso possível.
Se você está construindo com agentes de IA e atingiu o patamar — aquele em que você gasta mais tempo gerenciando agentes do que os agentes estão salvando você — pare de adicionar recursos. Comece a adicionar infraestrutura. Defina os trabalhos. Escreva as habilidades. Construa o cronograma. Deixe os agentes fazerem aquilo em que são genuinamente bons: comparecer sempre e acompanhar o processo sem ficar entediados, distraídos ou esgotados.
Essa não é uma possibilidade futura. É um projeto de terça à tarde. A questão é se você irá construí-lo esta semana ou continuará fazendo tudo manualmente até finalmente ficar frustrado o suficiente para tentar.
Já sei o que recomendaria.
🤝 Vamos trabalhar juntos
Procurando construir sistemas de IA, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- 🔗 Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- 🌐 Portfólio: mejba.me
- 🏢 Ramlit Limited (soluções empresariais): ramlit.com
- 🎨 ColorPark (design e branding): colorpark.io
- 🛡 xCyberSecurity (serviços de segurança): xcybersecurity.io
