O projeto Godot terminou de compilar às 4h42 da manhã. Eu não estava acordado para ver. O que vi, quando virei e desbloqueei meu celular às 8h11, foi uma mensagem no Telegram do meu Hermes Agent: "Build completo. Shooter stealth jogável em ~/projects/godot-tps. Pickups de loot funcionando (munição, bandagens). Toggle de visão através de paredes nos inimigos. IA de patrulha básica em três guardas. Último commit 04:42:13. Sem erros no editor. Quer que eu rascunhe o brief da próxima iteração?"
Eu tinha dado um único prompt na noite anterior. Fui dormir. Enquanto dormia, ele entregou um shooter em terceira pessoa no Godot 4.
Quero ser claro sobre algo antes que isso vire um parágrafo de hype. O shooter não é um jogo finalizado. A IA dos inimigos é burra. As texturas são placeholder. O rig de animação está meio feito. Mas o negócio é jogável. Você pode andar com um personagem por uma fase, pegar munição, usar uma bandagem para curar, ver inimigos brilhando através das paredes em um modo de visão stealth e disparar uma arma que causa dano. O esqueleto é real. A próxima iteração, com assets gerados por IA e mais algumas passadas pelo mesmo agente, será um jogo de verdade.
O ponto maior é o que o slashgoal provou. Fui de "ideia vaga" para "projeto Godot compilado e jogável" sem sentar no teclado. O agente não estava resumindo o que eu deveria fazer. Ele estava fazendo. Por vinte e três horas. Continuamente. Enquanto eu cozinhava, via um filme, dormia e fazia café.
Este é o post que queria escrever há meses. Não o post "Hermes Agent é incrível" — já escrevi o sobre conectar Hermes ao Claude Code como um SO de IA compartilhado e o sobre combiná-lo com OpenClaw para redundância. Este é o post sobre o que o Hermes Agent realmente faz por mim todos os dias. Seis casos de uso específicos. Fluxos de trabalho reais. Os que transformaram um buzzword de "agente auto-aprimorável" em uma força de trabalho IA 24/7 que eu genuinamente teria dificuldade em devolver.
Se você tem curiosidade sobre o Hermes mas não sabe no que apontá-lo, este é seu manual.
Por que "força de trabalho IA" é o enquadramento certo, não "assistente IA"
A maioria das pessoas instala o Hermes e tenta usá-lo como ChatGPT com passos extras. Digita um prompt. Recebe uma resposta. Fecha a janela. Repete.
Esse é o modelo mental errado. Desperdiça 90% do que torna o Hermes interessante.
O Hermes Agent (Nous Research, atualmente na v0.13 em maio de 2026) foi construído em torno de três decisões arquiteturais que mudam tudo sobre como você o usa:
- Ele persiste. Hermes roda em um servidor, um VPS ou um processo local de longa duração. Você pode falar com ele pelo Telegram, WhatsApp, Slack ou terminal — mas o agente em si não termina quando você fecha a janela. Ele continua rodando, lembrando e executando tarefas que você delegou horas ou dias atrás.
- Ele se auto-aprimora. Toda tarefa bem-sucedida é extraída em uma skill. Toda skill é refinada conforme você a usa mais. Isso significa que um pipeline de pesquisa que você configurou em fevereiro é mensuravelmente melhor em pesquisa em maio do que no dia em que foi construído. O agente compõe.
- Ele é multi-instância. Você pode rodar vários perfis Hermes em paralelo — um orquestrador, um pesquisador, um programador, um escritor — e eles passam trabalho entre si por meio de um quadro Kanban integrado. Isso não é metáfora. Existe literalmente um dashboard Kanban. Cards se movem entre colunas. Perfis são atribuídos. Trabalho acontece.
Junte essas três propriedades e "assistente IA" deixa de ser a palavra certa. O que você realmente tem é uma pequena força de trabalho. Sempre ativa. Sempre aprendendo. Coordenada por um quadro. Esse reenquadramento é o que desbloqueia os casos de uso abaixo.
Aqui está o que a minha faz por mim, na ordem em que os construí.
Caso de uso 1: Slashgoal para tarefas que levam mais de 24 horas
O slashgoal — /goal na CLI do Hermes — é a funcionalidade única que me fez parar de tratar o Hermes como um chatbot. De acordo com a documentação oficial do Hermes, /goal define um objetivo permanente no qual o agente continuará trabalhando ao longo das interações até concluí-lo, usando o que a Nous chama de Ralph loop. Em termos práticos: você dá um alvo e ele trabalha.
A primeira vez que tentei, fiz o que todo desenvolvedor faz. Digitei /goal construa um app para mim e fui dormir me sentindo esperto.
Acordei com um servidor Express meio quebrado, três readmes contraditórios e uma conta de tokens que me fez fazer careta. O agente genuinamente tentou. Só não tinha ideia do que eu queria.
Esse fracasso me ensinou a lição que agora ensino a todo usuário de Hermes que encontro: o slashgoal não é um desejo. É um contrato. E contratos funcionam quando ambas as partes são específicas.
A solução foi metaprompting. Em vez de digitar meu objetivo às cegas, comecei a co-escrever o objetivo com uma IA primeiro. Sentava com Claude ou Codex e respondia perguntas como:
- Qual é o entregável alvo, descrito como se eu o estivesse passando para um desenvolvedor?
- Quais são as restrições rígidas (linguagem, framework, dependências, estrutura de arquivos)?
- Quais são as preferências flexíveis (estilo, convenções de nomenclatura, bibliotecas a evitar)?
- Como é o "pronto"? Qual é a prova mínima viável de conclusão?
- O que o agente pode decidir? Sobre o que deve me perguntar?
- Qual é o orçamento — tokens, tempo, escopo?
Ao terminar, tenho um slashgoal de duas ou três páginas. Doloroso de escrever. Mágico de executar.
O projeto Godot que abriu este post veio de um desses slashgoals longos. O prompt especificou Godot 4 como engine, uma câmera em terceira pessoa conectada a um CharacterBody3D, dois pickups consumíveis (munição e bandagens), uma mecânica stealth onde inimigos ficam visíveis através de paredes quando o jogador se agacha, e IA de patrulha para três NPCs inimigos. Listava a estrutura exata de diretórios. Dizia ao agente quais APIs do Godot usar e quais evitar. Dava permissão para o agente commitar em um repositório git local em cada marco e me enviar mensagem no Telegram quando bloqueado.
O agente rodou por 23 horas. Atingiu o limite de orçamento que eu tinha definido para iterações máximas. Me consultou duas vezes, ambas porque identificou corretamente uma ambiguidade na minha especificação. O resultado foi o protótipo jogável que descrevi na abertura.
Esse mesmo padrão funciona para coisas que não são jogos. Já usei slashgoal para:
- Um documento técnico extenso (um playbook de 60 páginas para um cliente). O agente rascunhou, auto-revisou contra uma rubrica e iterou até cada seção passar. Tempo total: ~14 horas.
- Uma migração de um app Laravel legado para uma base de código Laravel 13 nova. O agente leu o código antigo, mapeou rotas e modelos, gerou a nova estrutura e produziu um diff para eu revisar. Tempo total: ~11 horas.
- Um site inteiro de documentação estática para um projeto open-source que mantenho. Hermes escreveu o conteúdo, gerou a configuração Astro, configurou o deploy em um VPS e me avisou quando o DNS precisou de intervenção manual. Tempo total: ~6 horas.
Há um padrão nesses exemplos que vale nomear. O slashgoal funciona melhor para trabalho delimitado, verificável e de cauda longa. Delimitado porque objetivos vagos falham. Verificável porque o agente precisa saber quando terminou. De cauda longa porque se uma tarefa leva 15 minutos, você deveria simplesmente fazê-la.
A troca honesta: execuções de slashgoal são caras quando você erra o cálculo. Uma execução de 23 horas no Opus 4.7 via OpenRouter me custou cerca de $38 para o projeto Godot. Vale por um protótipo real. Doloroso se o prompt era ruim e o output é inutilizável. Sempre limite sua configuração de iterações máximas em hermes init antes de delegar algo ambicioso.
Antes de seguirmos, aqui está o gancho que fecharei depois: um ótimo slashgoal ainda precisa de um ótimo lugar para entregar seu output. É aí que entra o Kanban.
Caso de uso 2: O quadro Kanban como meu controlador de tráfego humano-IA
O Kanban do Hermes é a segunda funcionalidade que mudou como eu trabalho. Vem como plugin de dashboard incluído em plugins/kanban/, roda localmente e expõe colunas para triagem, a fazer, pronto, rodando, bloqueado, feito e arquivado. Você o inicia com hermes dashboard no terminal, e uma aba do navegador abre na URL do kanban.
Essa frase subestima o que está realmente acontecendo. O Kanban não é uma lista de tarefas. É uma fila de delegação com roteamento integrado.
Aqui está o fluxo diário que sigo.
Manhã, por volta das 8h30. Escrevo minha lista de tarefas do dia. Caneta e papel, geralmente. Cerca de uma dúzia de itens: trabalho de cliente, revisões de código, dois artigos para escrever, três ligações para fazer, algo de faturamento que meu contador precisa, recados.
Separo a lista em duas pilhas. Pilha A é trabalho que só eu posso fazer. Pilha B é trabalho que um agente pode plausivelmente começar. A divisão é geralmente 60/40 em alguns dias, 30/70 em outros. Qualquer coisa que envolva uma ligação, uma decisão criativa, uma reunião presencial ou julgamento que depende de contexto que o agente não tem — isso é pilha A. Qualquer coisa que seja pesquisa, rascunho, scaffolding de código, refatoração, coleta de dados ou documentação rotineira — pilha B.
A pilha B vai para o Kanban. Abro o hermes dashboard, clico no botão de criação inline da coluna Triagem e coloco cards curtos. "Pesquisar três concorrentes do produto X, output em relatório markdown." "Refatorar o módulo de auth no repo Y para usar o novo padrão de middleware." "Rascunhar as primeiras 1.500 palavras do artigo da próxima semana sobre o tema Z."
O despachante assume. Por padrão, Hermes roda com kanban.auto_decompose: true. O despachante lê cada card na coluna Triagem, olha meu roster de perfis e roteia a tarefa. Um card de pesquisa vai para meu perfil Pesquisador. Um card de código vai para meu perfil Programador. Um card de escrita vai para meu perfil Escritor. Cards longos são desmembrados em um grafo de subtarefas via a ação Decompor. Cards curtos recebem uma reescrita de especificação de tarefa única via Especificar.
Cards fluem. Triagem → a fazer → pronto → rodando → feito. Eu não os movo. Os agentes movem. Assisto o quadro mudar ao longo do dia da mesma forma que costumava assistir pipelines de CI rodar.
A primeira vez que isso clicou para mim foi uma terça em março. Eu tinha colocado sete cards no quadro às 9h. Ao meio-dia tinha trabalhado em três das minhas tarefas só-humanas. Quando verifiquei o dashboard, quatro dos sete cards tinham ido para feito. Um estava bloqueado — o agente bateu numa parede e deixou um comentário me fazendo uma pergunta. Dois ainda estavam rodando. Respondi à pergunta do card bloqueado em quinze segundos. O agente se desbloqueou e retomou.
Esse é o momento em que parei de sentir que estava gerenciando tarefas. Eu estava revisando o trabalho de uma equipe da qual eu era, tecnicamente, o único membro humano.
Alguns detalhes que importam quando você realmente usa:
- Cards aceitam comentários. Deixo contexto nos comentários dos cards em vez de enfiar no título. O agente os lê. Contexto longo pertence aos comentários, não aos títulos.
- Cards aceitam links. Você pode anexar um caminho de arquivo, uma URL ou uma referência a outro card. Hermes os usa como inputs.
- O auto-decompositor de triagem é opinativo. Se não gostar de como ele quebrou uma tarefa, clique no botão Decompor novamente com um prompt mais claro em um comentário primeiro. Ele re-roteará baseado no comentário.
- Use descrições de perfil. O despachante roteia baseado nas descrições de perfil, não nos nomes. Um perfil chamado
codersem descrição recebe roteamento genérico. Um perfil chamadocoderdescrito como "Especialista TypeScript / Next.js / Tailwind, vive em~/projects/web" recebe exatamente o trabalho que deveria.
O Kanban é o que transforma Hermes de "um agente fazendo uma coisa" em "uma força de trabalho fazendo muitas coisas." Uma vez que estiver rodando, você vai parar de abri-lo para checar progresso e começar a abri-lo para delegar.
Mas a parte mais contraintuitiva de como uso o Hermes não é o comando de goal nem o Kanban. É o motor de pesquisa autônomo que chegarei a seguir — que produz output tão detalhado que facilita o trabalho do Claude Code.
Caso de uso 3: Pesquisa técnica e análise competitiva que se transferem sem atrito
Faço uma análise competitiva de todo produto que avalio. Costumava fazer manualmente. Abrir uma aba. Ler o copy de marketing. Abrir outra aba. Clicar pelo produto. Abrir o DevTools. Olhar o tamanho do bundle. Notar a página de preços. Notar os scripts de analytics. Notar o processador de pagamento. Digitar as descobertas.
Isso costumava ser uma hora, no mínimo, por produto. Às vezes meio dia se o produto fosse profundo.
Agora é um card no Kanban.
O card fica assim: "Analisar produto concorrente Creator Buddy (creatorbuddy.ai). Produzir um relatório markdown cobrindo stack tecnológico, lista de funcionalidades, faixas de preço, configuração de analytics, processador de pagamento, principais claims de posicionamento e lacunas versus ferramentas comparáveis. Output em ~/research/competitors/creator-buddy-2026-05.md."
O agente faz esse trabalho da mesma forma que eu faria, exceto mais rápido e mais minuciosamente. Abre o site. Lê cada página. Inspeciona requisições de rede. Olha os bundles JavaScript carregados e nota quais frameworks são visíveis. Lê o source da página procurando tags de analytics. Verifica a página de preços. Compara linguagem de posicionamento entre páginas. Produz um relatório markdown — geralmente de 1.500 a 2.500 palavras — que posso colocar diretamente no Claude Code ou Codex como input para uma tarefa de construção.
A análise do Creator Buddy rodou por cerca de 40 minutos. O output continha:
- Identificação do stack tecnológico. Next.js 14, Tailwind, deploy no Vercel, usando Stripe para pagamentos, Mixpanel para analytics de produto, Intercom para suporte. Tudo inferido dos headers, scripts carregados e source da página.
- Inventário de funcionalidades. Vinte e três funcionalidades, cada uma descrita em uma frase, organizadas pelas quatro superfícies do produto (dashboard, editor, biblioteca, configurações).
- Matriz de preços. Três tiers, com as diferenças de funcionalidades destacadas. Extraído diretamente da página de preços e alguns documentos de suporte linkados no rodapé.
- Claims de posicionamento. Seis claims centrais que o marketing faz, ranqueados por quão proeminentemente são apresentados.
- Lacunas. A avaliação do próprio agente — baseada em comparação com duas ferramentas de referência que eu tinha mencionado — do que o Creator Buddy não faz que ferramentas comparáveis fazem.
Essa última seção foi o ponto-chave. O agente não apenas descreveu o produto. Ele o analisou. A seção de lacunas me deu três oportunidades concretas que uma ferramenta no mesmo espaço poderia perseguir.
O que torna este caso de uso especialmente valioso: o output é estruturado para agentes downstream. Como o relatório é um arquivo markdown limpo em um local conhecido, posso colocá-lo como contexto no Claude Code com um slashgoal de acompanhamento: "Leia ~/research/competitors/creator-buddy-2026-05.md. Construa um protótipo Next.js 15 que aborde as três lacunas identificadas no relatório. Use o mesmo stack tecnológico. Output em ~/projects/prototype-x."
São duas operações Hermes encadeadas. Pesquisa → protótipo. Ambas autônomas. Ambas produzindo artefatos reais que posso revisar. O mesmo padrão de transferência funciona para qualquer fluxo pesquisa-depois-construção.
Uma nota sobre ética, porque levo isso a sério: o agente só inspeciona páginas publicamente disponíveis. Sem scraping atrás de paywall. Sem burlar autenticação. Sem simular usuários. O agente lê o que um navegador deslogado veria e reporta o que é visível. É uma restrição que defino na descrição do perfil e reforço em todo card de pesquisa.
Se você escreve muito conteúdo prático de IA como eu, a cadeia pesquisa-depois-construção paga a assinatura do Hermes sozinha. As horas que eu costumava gastar juntando contexto agora são horas que gasto na escrita em si.
Caso de uso 4: Uma wiki de memória pessoal que fica mais inteligente conforme vivo
Há uma categoria de caso de uso do Hermes que não aparece em nenhum post de "10 casos de uso" que li, e é a que eu mais teria dificuldade em perder.
Tenho uma wiki de memória pessoal. É um site privado, hospedado em um domínio que só eu consigo acessar, mantido automaticamente pelo Hermes. Toda conversa que temos, toda decisão que tomo em um log diário, todo artefato de pesquisa, todo marco de projeto — tudo chega como uma entrada clicável, pesquisável e interligada nessa wiki.
Configurá-la foi um prompt e cerca de 25 minutos.
Pedi ao Hermes para me construir um site estático com três coisas: uma homepage listando meus projetos ativos com badges de status, uma seção de log diário com uma entrada por dia, e uma seção de tópicos onde cada tópico é uma página markdown que se auto-atualiza sempre que uma conversa relevante acontece. Disse onde hospedá-lo (um subdomínio privado no meu VPS), dei acesso de escrita ao vault Obsidian onde minhas notas ficam e apontei para o diretório de logs de conversas.
Essa foi a instalação. Agora a wiki se mantém sozinha.
Toda noite por volta da meia-noite, uma tarefa agendada roda no Hermes. Ela puxa as conversas do dia, extrai os pontos substantivos (decisões, lições, referências úteis, coisas que eu disse que lembraria) e os escreve nas páginas de tópico apropriadas. Atualiza o log diário com um resumo limpo. Interliga novas entradas a tópicos existentes onde o conteúdo se sobrepõe. Pela manhã, a wiki cresceu um dia inteiro de memória precisa e navegável — sem eu tocar em nada.
Por que isso importa? Duas razões.
Reforça minha própria memória. Eu costumava esquecer coisas. Decisões tomadas três semanas atrás. Conversas com clientes sobre mudanças de escopo. A razão específica pela qual escolhi uma biblioteca em vez de outra em um projeto do mês passado. Agora apenas abro a wiki e pesquiso. O ato de registrar coisas — mesmo quando o agente faz o registro — as puxa de volta para a memória acessível de curto prazo.
Dá ao agente melhor contexto de longo prazo. Esta é a parte que não previ. Como a wiki também é a fonte de verdade do agente, toda conversa que tenho com o Hermes é informada por toda conversa que já tive. Pergunte ao Hermes sobre um projeto do trimestre passado e ele não tropeça — abre a página do tópico, lê suas próprias notas e responde com contexto completo. A wiki é, efetivamente, a memória de longo prazo externalizada do agente em uma forma que posso navegar e auditar.
Um exemplo específico. Duas semanas atrás estava em uma call com um cliente sobre um projeto Laravel. Eles referenciaram uma decisão que tínhamos tomado em fevereiro sobre autenticação. Eu não tinha nenhuma lembrança. Abri a wiki no meu segundo monitor, digitei "auth" na busca e a entrada apareceu: "2026-02-14 — Decisão de auth do Cliente X. Escolhido Laravel Sanctum em vez de Passport porque a equipe mobile deles usa auth baseada em tokens e o modelo de token de API do Sanctum mapeia de forma mais limpa. Mejba sinalizou o custo de migração. Cliente aceitou." Li isso para o cliente. Confirmaram. A call seguiu.
Sem a wiki, são quinze minutos de "deixe-me verificar e te retorno" constrangedor. Com a wiki, são seis segundos. Multiplique por toda conversa que depende de contexto anterior — que é, eventualmente, toda conversa — e você entende por que eu lutaria para manter essa configuração.
A configuração é mais simples do que parece. Hermes constrói o site com qualquer stack que você quiser (o meu é Astro porque compila rápido e fica decente com estilização mínima). A tarefa agendada é uma única entrada cron na configuração do Hermes. A interligação acontece através de uma pequena skill que o agente aprendeu ao longo do tempo — e que agora está na minha biblioteca de skills, pronta para compartilhar se você pedir.
Construa isso. Sério. É o caso de uso que mais retorna ao longo do maior período de tempo.
Caso de uso 5: Uma rede mesh Tailscale que transforma cada dispositivo em um terminal Hermes
Aqui está o caso de uso que transformou minha coleção de dispositivos em um sistema funcional único.
Tenho um MacBook Pro na mesa. Um Mac Mini numa prateleira rodando trabalhos longos. Um iPhone no bolso. Um iPad numa mochila. Uma máquina Linux sobressalente que mantenho para testes. Antes dessa configuração, cada dispositivo era sua própria ilha. Arquivos no Mac Mini ficavam no Mac Mini. Modelos rodando na máquina Linux rodavam na máquina Linux. Para mover um arquivo ou consultar um serviço entre dispositivos, eu improvisava com Dropbox, SSH ou um cabo USB.
O Tailscale engoliu tudo isso.
Tailscale é uma VPN mesh. Você instala em todo dispositivo que possui. Eles se autenticam na sua tailnet. Formam conexões peer-to-peer criptografadas usando WireGuard. Todo dispositivo recebe um nome estável (via MagicDNS) e um endereço IP acessível apenas de dentro da sua mesh privada. Celulares, laptops, servidores, tablets — todos em uma rede, todos endereçáveis por hostname, todos protegidos por SSO na borda.
A configuração leva vinte minutos e é gratuita para uso pessoal até 100 dispositivos. Instale o app. Faça login com Google ou GitHub. Pronto. Todo dispositivo aparece no console admin do Tailscale com um nome e um IP. De qualquer dispositivo na mesh, você pode alcançar qualquer outro dispositivo pelo hostname.
O que isso desbloqueia para o Hermes é irracional.
Acesso a arquivos entre dispositivos. Um processo Hermes rodando no meu Mac Mini pode ler arquivos no meu MacBook Pro referenciando-os em macbook-pro:/Users/mejba/projects/... pela mesh. Não preciso sincronizar, copiar ou fazer upload. O agente lê os arquivos onde eles vivem.
Serviços tipo localhost de qualquer lugar. Rodo um LLM local (um modelo Llama quantizado) na máquina Linux. Do meu MacBook, consigo acessá-lo em linux-box:11434 — a porta do Ollama — como se fosse localhost. Do Hermes no Mac Mini, a mesma coisa. A mesh inteira trata todo dispositivo como uma máquina lógica única.
Execução de testes entre dispositivos. Se o Hermes está construindo um web app no meu MacBook e quer testá-lo de uma "rede diferente," pode rodar um curl do iPhone (sim, com iSH ou a-Shell) ou da máquina Linux. Mesmo código, caminho de rede diferente, teste real.
Celular como controle remoto do Mac Mini. Este é levemente absurdo mas útil. O dashboard do Hermes no Mac Mini é acessível do navegador do meu iPhone pelo nome MagicDNS do Mac Mini. Posso estar na cafeteria, ver meu quadro Kanban atualizar em tempo real no meu celular e arrastar cards entre colunas pela tela do iPhone. O Mac Mini trabalha. O celular é o volante.
O vídeo que inspirou parte deste texto escreveu o produto como "Tailcale." Na verdade é Tailscale, com o S. Mesmo produto, grafia real, disponível em tailscale.com. Gratuito para uso pessoal. Vale instalar hoje mesmo se nunca rodar Hermes — mas se rodar Hermes, transforma o que um agente em uma máquina consegue alcançar.
Uma nota de segurança: quando coloca dispositivos em uma tailnet, eles ficam acessíveis de todo outro dispositivo da sua tailnet. Esse é o ponto todo. Mas isso significa que um comprometimento em um dispositivo potencialmente expõe serviços em outros. Use ACLs do Tailscale para delimitar o que cada dispositivo pode acessar. Não rode serviços sem autenticação em um IP da tailnet só porque a mesh parece privada. A mesh é privada. Os serviços ainda devem autenticar.
Se esse tipo de configuração distribuída te interessa, já escrevi sobre deploy de agentes autônomos em um VPS com notificações Discord — mesma filosofia, mesh diferente.
Caso de uso 6: O prompt de prioridade matinal das 9h que dirige meu dia
O último caso de uso é o menor do post e o que eu defenderia com mais força.
Toda manhã às 9h, Hermes me envia uma mensagem no Telegram com uma pergunta: "Qual é sua prioridade número um hoje?"
Só isso. Esse é o prompt inteiro.
Respondo com uma frase. Às vezes duas. Geralmente algo como "lançar o redesign da landing page da agência" ou "terminar o segundo rascunho do artigo sobre Hermes" ou "ligar para meu contador e resolver o faturamento da semana passada."
Hermes faz três coisas com minha resposta.
Atualiza a wiki. Uma nova entrada chega no meu log diário: data de hoje, a prioridade, minhas palavras exatas. No final da semana, há uma coluna que posso escanear para ver o que me disse que importava a cada dia. Padrões emergem que não consigo ver em tempo real.
Gera tarefas de apoio. Se eu disse "lançar o redesign," Hermes coloca cards no Kanban: pesquisar o que está atualmente na página, reunir assets de marca, rascunhar três variações de hero, escrever três opções de meta description, preparar um checklist de deploy. Posso manter, matar ou editar qualquer um. Na primeira vez deletei metade. Na segunda semana, estava mantendo a maioria. O agente aprendeu quais tarefas de apoio eu valorizo e quais não.
Adapta seu comportamento. Ao longo das semanas, o agente constrói um modelo do que priorizo, quando e por quê. Segundas tendem a tarefas de escrita. Quartas tendem a trabalho de cliente. Sextas tendem a lançar ou finalizar. O agente usa esse padrão para enviesar as tarefas de apoio que gera. Pergunte minha prioridade de segunda e as tarefas de apoio se inclinam para pesquisa e esboço. Pergunte minha prioridade de sexta e elas se inclinam para checks de lançamento e revisão.
O loop de auto-aprimoramento é o ponto todo. O prompt matinal é o menor sinal de feedback possível que você pode dar a um agente que quer aprender seu fluxo de trabalho, e produz a maior mudança de comportamento possível ao longo do tempo. Após três meses, meu perfil Hermes me conhece de uma forma que a primeira semana de uso não poderia ter previsto.
Você pode construir este prompt em cinco minutos. Configure uma tarefa cron dentro do Hermes (hermes cron create --time "09:00" --message "Qual é sua prioridade número um hoje?"), aponte para seu bot do Telegram, dê a ele uma pequena skill chamada daily-priority-handler que faz as três coisas acima, e deixe rodar.
Na primeira semana, é uma pergunta que interrompe seu café. Na terceira semana, é um pequeno ritual que você espera com expectativa. No terceiro mês, é o hábito mais importante do seu dia.
O que une esses seis casos de uso
Seis casos de uso. Um padrão.
Cada um deles pega o mesmo primitivo — um Hermes Agent que pode persistir, aprender e executar — e o transforma em uma função de produção diferente. O slashgoal é o trabalhador de turno longo. O Kanban é o despachante. O motor de pesquisa é o analista. A wiki de memória é a memória institucional. A mesh Tailscale é a rede do escritório. O prompt matinal é a reunião de standup.
Rode todos juntos e você não tem um assistente IA. Tem uma organização. De um humano e quantos perfis Hermes você decidir criar.
Há uma desvantagem real para ser honesto sobre. O custo de manutenção não é zero. Hermes lança atualizações frequentemente. O auto-decompositor do despachante Kanban fica opinativo de formas que ocasionalmente irritam. O slashgoal às vezes bate em paredes e queima orçamento antes de falhar utilmente. A tarefa cron da wiki precisa de poda ocasional quando páginas de tópico ficam pesadas. Nenhum desses é um impeditivo. Todos são reais.
Mas a pergunta não é "o Hermes é perfeito?" É "a força de trabalho produz mais do que custa?" Para mim, facilmente sim. Lancei mais código, escrevi mais artigos, conduzi mais pesquisa e lembrei de mais decisões nos últimos seis meses com Hermes do que nos doze meses anteriores sem ele.
A noite em que o projeto Godot terminou de compilar às 4h42 foi a noite em que parei de questionar se manteria essa configuração.
Aqui está a única pergunta que vale a pena considerar esta noite: se você tivesse uma força de trabalho de prontidão agora — uma que nunca dormisse, nunca esquecesse, nunca perdesse contexto — o que você já teria delegado?
Esse é o slashgoal que você deveria digitar a seguir.
Perguntas Frequentes
O que é o comando slashgoal do Hermes Agent?
O slashgoal (/goal) é um comando do Hermes Agent que define um objetivo permanente no qual o agente continuará trabalhando ao longo das interações até concluí-lo, usando o que a Nous Research chama de Ralph loop. É projetado para tarefas autônomas de longa duração — de algumas horas a vários dias — que têm um entregável claro. Para o fluxo completo de slashgoal e padrão de metaprompting que uso, veja a seção de slashgoal acima.
Como funciona o quadro Kanban do Hermes Agent?
O Kanban do Hermes vem como plugin de dashboard incluído e expõe colunas para triagem, a fazer, pronto, rodando, bloqueado e feito. Cards colocados na coluna Triagem são auto-roteados por um despachante para o perfil de agente certo baseado nas descrições de perfil que você configurou. Você o inicia com hermes dashboard no terminal.
O Hermes Agent pode rodar autonomamente enquanto durmo?
Sim — esse é o design central. Hermes roda como um processo persistente em um servidor, VPS ou máquina local de longa duração, e continua executando slashgoals ou tarefas Kanban mesmo quando você está offline. Você pode acessá-lo pelo Telegram, WhatsApp ou pelo dashboard web sempre que quiser verificar o status.
Preciso do Tailscale para usar o Hermes Agent?
Não. O Tailscale é opcional, mas expande dramaticamente o que um processo Hermes pode alcançar. A VPN mesh do Tailscale permite que seu agente Hermes acesse arquivos e serviços em todo dispositivo que você possui — celular, tablet, laptop, servidor — como se fossem uma única máquina. Veja o caso de uso do Tailscale acima para a configuração.
Quanto custa rodar múltiplos perfis Hermes?
Os custos dependem de qual modelo você direciona cada perfil. Um perfil Hermes rodando no Claude Sonnet 4.7 da Anthropic é dramaticamente mais barato que um no Opus 4.7. Minha configuração mistura Opus para orquestração e revisão com modelos mais baratos para execução rotineira, e roda confortavelmente por menos de $200/mês entre múltiplos perfis e um ou dois slashgoals de 23 horas por semana.
Vamos Trabalhar Juntos
Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- Fiverr (builds e integrações customizadas): 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
