Que tarefas você deve delegar primeiro ao Hermes Agent (e quais segurar)?

Fala aí, beleza? Você instalou o agente, abriu o terminal e travou na pergunta errada

A dúvida da primeira semana quase nunca é "o que ele consegue fazer"

É "o que eu entrego primeiro sem me arrepender depois"

O Hermes Agent é um agente de IA de código aberto mantido pela Nous Research, lançado em 25 de fevereiro de 2026

Projeto novo, mexendo em terminal de verdade, e é exatamente aí que a decisão de delegação separa ganho de retrabalho

Então bora montar um critério, e não uma lista de exemplos bonitinhos 🙂

Como o Hermes Agent delega (e por que isso muda o critério):

Antes do "o quê", o "como", porque o mecanismo é que define o critério

A delegação acontece pela ferramenta delegate_task, que abre subagentes com contexto isolado, ferramentas herdadas e sessão de terminal própria

E aqui está a parte que muda tudo: só o resumo final volta pro agente pai

O subagente começa numa conversa nova e não conhece o histórico do pai

Todo o contexto dele vem dos campos goal e context preenchidos na chamada

Se você não sabe escrever a tarefa, você não sabe delegar ela:

Essa é a consequência prática, e ela é dura

Tarefa que mora só na sua cabeça, cheia de "ah, mas nesse caso eu faço diferente", chega capenga no subagente

Se você conhece a lógica de abrir uma issue bem descrita pra outro dev pegar sem te perguntar nada, é bem semelhante

A diferença é que o dev te chama no chat quando fica na dúvida, e o subagente não vai te chamar

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Background e o teto de simultaneidade:

A delegação de topo roda em background, e a concorrência de subagentes em paralelo é limitada por padrão

São no MÁXIMO 3 tarefas simultâneas, configurável em delegation.max_concurrent_children ou na variável de ambiente DELEGATION_MAX_CONCURRENT_CHILDREN (piso de 1, sem teto rígido)

Ou seja: dá pra abrir mais, mas o padrão já te empurra pra pensar em lotes pequenos, o que é ótimo enquanto a confiança está sendo construída

E o que é recorrente?

Pra tarefa que se repete existe uma ferramenta só, a cronjob

Ela aceita quatro formatos: atraso relativo (30m), intervalo (every 2h), expressão cron (0 9 *) e timestamp ISO

Os jobs podem ser criados, pausados, editados e removidos em linguagem natural, sem você editar arquivo de crontab na unha

Delegar agora ou segurar? Um teste rápido por tipo de tarefa:

Três perguntas, nessa ordem

Reversível: se sair errado, dá pra desfazer sem drama?

Verificável: você consegue olhar a saída e saber em segundos se está certo?

Autocontido: cabe inteiro nos campos goal e context, sem depender do que você já falou antes?

Se as três respostas forem sim, sai da sua mão hoje

Repare que a última faixa da tabela não é achismo meu

Essas classes são justamente as que o Hermes NUNCA coloca na lista de aprovação permanente, mesmo que você já tenha aprovado várias vezes

Isso vale enquanto a checagem de aprovação estiver ligada, e mais pra frente eu te mostro o modo que desliga ela por completo

Se a ferramenta se recusa a decorar esse "sim", você também não deveria decorar

As tarefas que pagam mais rápido quando saem da sua mão:

Poucos casos, e cada um justificado pelo critério, não pela novidade

1. O repetitivo que não pede raciocínio nenhum:

Existe um modo de cron sem LLM: o parâmetro no_agent=True na criação do job

O script roda no horário e a saída padrão é entregue na plataforma de mensagens, sem passar pelo modelo

É o retorno mais rápido de todos, porque não tem alucinação possível: o que roda é o teu script, o agente só é o carteiro

2. O resumo de horário fixo:

Rotina de leitura em 0 9 *, que junta o estado das coisas e te entrega um resumo pra ler com o café

Passa nos três testes com folga: não muda nada, você confere na hora, e cabe inteiro no prompt

3. O lote paralelizável:

Quando você tem quatro coisas independentes pra levantar, delegar cada uma vira ganho real de relógio

Com o padrão de 3 simultâneas, o quarto item espera a vaga, e isso é bom no começo: te obriga a ver o resultado dos primeiros antes de escalar

4. O exploratório de contexto pesado:

Aquela varredura chata, que enche a conversa de saída de terminal e te faz perder o fio

Como o subagente tem contexto isolado e só o resumo final volta, essa bagunça toda fica lá dentro e não polui a tua sessão

É o caso onde delegar rende mesmo que a tarefa não seja "difícil"

Fato ou procedimento? Isso decide o que rende:

A documentação separa os dois de forma explícita

Memória guarda fatos duráveis pequenos, que precisam estar sempre em contexto: preferências, projetos, ambiente e correções, nos arquivos MEMORY.md e USER.md

Skill guarda procedimento mais longo, carregado só quando é relevante, num padrão de divulgação progressiva pra economizar token

A delegação rende MUITO mais quando o procedimento já virou skill, porque aí o teu goal fica curto e a skill entrega o resto

Vale a mesma lógica de alimentar bem a memória do Hermes Agent: fato durável você registra uma vez e para de repetir

E a fronteira entre delegar ou escrever na mão é a mesma discussão de sempre, só que agora com terminal de verdade do outro lado

Os quatro tropeços da primeira semana de delegação:

Tropeço 1: a tarefa em background simplesmente sumiu

Sintoma: você mandou rodar, foi fazer outra coisa, voltou e não tem resultado nenhum

Causa: o trabalho delegado em background fica preso à sessão e ao processo do Hermes que o criou

Fechar a sessão, usar /stop, usar /new ou reiniciar o processo pode cancelar ou deixar órfão o trabalho em andamento

Solução: rode de novo, e dessa vez segure a sessão aberta até o resumo voltar

Prevenção: enquanto a tarefa longa está no ar, trate /new como se fosse um rm -rf da vida… não é hora de dar aquele reset por reflexo

Tropeço 2: o job agendado entregou meia coisa

Sintoma: o cron disparou no horário certo, mas o resultado ignorou metade do que você queria

Causa: cada job agendado roda em uma sessão de agente TOTALMENTE nova

Ele não sabe nada do que vocês combinaram ontem no chat

Solução: o prompt do cron precisa carregar tudo que a tarefa exige e que já não venha das skills anexadas

Prevenção: antes de agendar, leia o prompt fingindo que você nunca viu esse projeto na vida

Se faltou contexto pra esse "você de fora", vai faltar pro agente também

Tropeço 3: o cron não se desdobrou em outros jobs

Sintoma: você pediu um job que criasse outros jobs conforme o resultado, e nada foi agendado

Causa: o Hermes desabilita as ferramentas de gestão de cron dentro da execução do cron

Isso é de propósito, pra evitar loop de agendamento descontrolado

Solução: o job entrega o resultado, e a decisão de criar novos jobs volta pra você (ou pra uma sessão normal)

Prevenção: desenhe cron como tarefa folha, nunca como orquestrador

Tropeço 4: não dá pra reconstruir o que o agente fez

Sintoma: algo mudou, ficou estranho, e você não sabe em qual passo aquilo aconteceu

Causa: você está tentando lembrar em vez de auditar

Solução: toda conversa vira sessão salva automaticamente, em qualquer superfície, com histórico completo, retomada e busca entre sessões

Os logs ficam em ~/.hermes/logs/ (ou em <profile>/logs/ em perfis não padrão)

E dá pra exportar:

hermes sessions export

O comando gera um registro JSONL por prompt, com id da sessão, índice, timestamp e texto

Prevenção: exporte a sessão da primeira tarefa delegada antes de ampliar o escopo

É o teu único jeito honesto de saber se o agente merece mais corda

Como ampliar o escopo conforme a confiança cresce:

A faixa que mais se move na tabela é a do "delegar com aprovação"

É ela que vira "delegar agora" quando você configura os controles certos

A faixa "segurar" é outra história: são as classes que o próprio projeto se recusa a pré-aprovar, então ela fica onde está

As aprovações vivem em um campo só:

É o approvals.mode no arquivo ~/.hermes/config.yaml, com três valores possíveis

manual: o Hermes compara o comando com uma lista curada de padrões perigosos antes de executar e pede aprovação explícita quando bate

Na CLI interativa aparece um prompt inline, e nas plataformas de mensagem o agente manda os detalhes no chat e espera a tua resposta

smart: um LLM auxiliar decide se o comando sinalizado é realmente perigoso

Ele auto-aprova o de baixo risco sem perguntar, bloqueia sem prompt o que considera perigoso e escala pro fluxo manual quando fica em dúvida

A aprovação automática vale no nível da sessão pro mesmo padrão

off: desliga todas as checagens, equivale a rodar com --yolo

Tome cuidado aqui: no off não sobra nem a proteção das classes da faixa "segurar", porque não existe mais checagem nenhuma pra segurar o que quer que seja

A documentação recomenda usar só em ambiente confiável, tipo CI/CD e containers

approvals:
  mode: manual

O que você aprova "pra sempre" fica salvo:

O diálogo tem três opções: Approve Once, Always Approve e Cancel

No Telegram, Discord e Slack ele aparece com botões nativos de sim e não, e nas outras plataformas cai num fallback em texto

O que for aprovado como Always fica salvo em ~/.hermes/config.yaml e passa silenciosamente nas sessões seguintes

Tome cuidado: esse é o botão que transforma "delegar com aprovação" em "delegar agora" de verdade, então clique nele com o dedo consciente

E lembra: as classes destrutivas ficam de fora dessa lista permanente por decisão do projeto, nos modos manual e smart, que é onde a checagem existe

O terminal como fronteira:

O Hermes suporta sete backends de terminal, que definem ONDE os comandos do agente rodam: máquina local, container Docker, servidor remoto por SSH, sandbox Modal, workspace Daytona, Vercel Sandbox e container Singularity/Apptainer

Nos backends containerizados (docker, singularity, modal, daytona e vercel_sandbox) a checagem de comando perigoso é pulada, porque o próprio container passa a ser a fronteira de segurança

Parece contraintuitivo, mas faz sentido: você trocou o guarda da porta pela parede

A documentação recomenda docker, modal, daytona ou vercel_sandbox em deploy de gateway em produção

E tem o iron-proxy, um proxy de egresso pra sandboxes Docker: ele injeta as credenciais e o sandbox recebe apenas tokens opacos, válidos só atrás do daemon local

Além disso, execute_code e terminal removem variáveis de ambiente sensíveis dos processos filhos

Os portões de escrita:

Por padrão o agente salva memória sozinho, mas dá pra ligar um portão

É a configuração memory.write_approval: true

Com ele ligado, escrita em foreground na CLI pergunta inline, e o resto (plataformas de mensagem, scripts e a revisão de auto-melhoria em background) fica numa fila pra revisão

Os comandos são /memory pending, /memory approve <id>, /memory reject <id> e /memory approval on

O agente também cria, atualiza e apaga as próprias skills pela ferramenta skill_manage

Com o write_approval ligado, toda escrita de skill entra na fila independentemente da origem, e você revisa com /skills pending, /skills diff <id>, /skills approve <id> e /skills reject <id>

O diff é o mais subestimado desses: é ele que te mostra o que o agente decidiu virar procedimento fixo

Por onde começar hoje:

O critério cabe numa frase: delegue primeiro o que é reversível, verificável e autocontido, deixe o que altera o sistema pra quando a aprovação estiver configurada, e segure o irreversível, que nem o próprio Hermes topa pré-aprovar

O próximo passo é bem menor do que parece

1. Escolha UMA tarefa recorrente que passe nos três testes (a de leitura e resumo é a candidata óbvia)
2. Descreva ela por completo nos campos goal e context, escrevendo como se o agente nunca tivesse te conhecido, porque é literalmente o caso
3. Rode com approvals.mode: manual no ~/.hermes/config.yaml, mesmo que pareça chato no começo
4. Audite o resultado com hermes sessions export antes de ampliar o escopo

O erro comum aqui é pular direto pro passo 4 sem ter feito o 2 direito: sessão exportada de uma tarefa mal descrita não prova nada, você só vai ler o agente errando bonito

Se você ainda não instalou, a instalação por linha de comando é um script só:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

O instalador cuida das dependências (Python, Node.js, ripgrep, ffmpeg), do clone do repositório, do ambiente virtual, do comando global hermes e da configuração do provedor de LLM

E ele roda em Windows nativo, sem exigir WSL: CLI, gateway, TUI e ferramentas funcionam ali mesmo

Quem preferir pode usar o mesmo one-liner de Linux e macOS dentro do WSL2

Uma última razão pra começar pequeno: o projeto está em movimento rápido

A versão atual publicada é a v0.20.1, tag v2026.8.13, de 13 de agosto de 2026, um release de correções e estabilização

A anterior, a v0.20.0 ("The Herald Release"), de 3 de agosto de 2026, trouxe voz conversacional em tempo real e Mixture-of-Agents como modelo selecionável

Com 231 mil estrelas no GitHub e lançamento em fevereiro de 2026, dá pra dizer que a comunidade chegou junto e que o chão ainda está sendo assentado

Então comece por uma tarefa, confira o resultado, e só depois amplie

Quem começa delegando o irreversível não ganha tempo, ganha história pra contar depois… e não é do tipo boa haha

até o próximo post! =)