🚫 Não criar cedo demais
O erro mais comum de quem começa com Hermes é criar 3-4 agentes no primeiro mês achando que está "se preparando para escalar". Resultado: nenhum agente fica bem treinado, todos têm memórias rasas, e em 60 dias 2 deles estão abandonados.
📏Heurística do "1º agente"
Só crie um segundo agente quando o primeiro tiver:
- ✓Pelo menos 5 skills em uso regular
- ✓Pelo menos 3 crons entregando valor
- ✓Pelo menos 1 mês de uso real (não só teste)
- ✓Pelo menos 1 vez em que você atualizou memória ou soul para corrigir comportamento
💡Por que isso importa
Operar 1 agente sólido te ensina o ciclo completo: criar skill, atualizar memória, ajustar soul, agendar cron, debugar, rotacionar. Esses ciclos repetidos viram músculo. Tentar aprender o ciclo em 3 agentes ao mesmo tempo dilui aprendizado e gera frustração.
🎯 Critérios para um novo agente
Quando o critério aparece, separe sem dó. Existem 4 sinais concretos de que vale criar um segundo agente em vez de empilhar mais coisas no primeiro.
🔑 Chaves diferentes
A nova função exige conta diferente: outro Telegram bot, outro Gmail, outra API key de banco. Misturar viola princípio do menor privilégio.
🧠 Memória que não pode misturar
Dados de cliente A vazando pra cliente B é catástrofe. Memória pessoal vazando pra agente da empresa, idem. Isolar via container.
🎭 Função/tom muito distinto
Soul "informal e debochado" pra você não combina com "profissional e empático" pra suporte. Mesmo soul não atende os dois.
⚠️ Escopo de risco diferente
Agente que pode pagar contas é risco diferente de agente que só lê email. Separe pra reduzir blast radius se algo for comprometido.
📋 Regra prática
Se 2+ critérios estão presentes, separe. Se só 1, pondere — talvez uma skill nova com escopo limitado resolva sem fragmentar.
🗂️ Padrão por vertical
Receita testada por dezenas de operadores. Você não precisa inventar a divisão — esses são os recortes que funcionam em operações pessoais e pequenas empresas.
🧘 Pessoal — assistente do dia
Resumos, lembretes, agenda, leitura assistida. Soul informal. Memória sobre você, projetos pessoais, preferências. Acesso ao seu Telegram principal.
📣 Marketing — tom de marca
Soul = voz da marca, com exemplos. Memória = histórico de conteúdo, calendário editorial. Skills: responder comentário, sugerir thread, revisar copy.
💰 Financeiro — acesso restrito
Chaves bancárias separadas. Canal Telegram privado. Soul sério. Skills: relatório semanal, alerta de vencimento, anomalia de custo.
🎧 Suporte — FAQ + escalação
Soul empático e profissional. Memória = FAQ vivo. Skills: triagem, sugestão de resposta, escalação para humano em casos críticos.
⚙️ Ops — audit + backup
Acesso root ao VPS. Crons: auditoria semanal, backup diário, monitor de disco/memória. Soul direto e técnico.
✍️ Conteúdo — newsletter, posts
Soul = sua voz autoral. Memória = exemplos de bons textos seus. Skills: revisar texto, sugerir variações, compilar newsletter semanal.
🏢 Anatomia do "prédio"
Modelo mental simples e útil: pense em três camadas físicas. Cada uma tem responsabilidade clara, e confundir entre elas é fonte de bug recorrente.
VPS = o prédio
Recurso físico (CPU, RAM, disco), IP público, banda. Ubuntu LTS + Docker + nginx + ssh. Você é o síndico — cuida do prédio inteiro.
Container Docker = a sala
Isolamento. Cada agente tem seu container, seu .env, seus volumes. Reiniciar uma sala não afeta as outras. Atualizar uma versão de Hermes é trocar o conteúdo da sala.
Agente Hermes = o funcionário
A pessoa que trabalha dentro da sala. Tem skills (procedimentos), memória (fatos), soul (jeito de ser). Quando você "atualiza o agente", está editando esses arquivos Markdown.
⚠️Confusão clássica
"Coloquei a chave no .env e não funciona." → Você editou o .env do prédio (host) quando o Hermes lê o .env da sala (container). Sempre confirme onde está editando: docker exec -it hermes env | grep TELEGRAM.
🚚 Migração entre agentes
Boa notícia: Hermes guarda quase tudo em arquivos Markdown. Skills, MEMORY.md, SOUL.md, USER.md — tudo legível, versionável e portável. Migrar conhecimento entre agentes vira um git clone e um ajuste de tom.
📋 Receita de migração
- Crie um repo GitHub privado:
hermes-shared - Lá dentro:
/skills,/templatesde soul/memory por vertical - Cada container faz
git clonee linka só o que usa - Skill compartilhada por 5 agentes: editou 1 vez, todos pegam no próximo pull
- Skill específica por vertical: pasta
/marketing,/financeiro, etc.
💡Dica de versionamento
Trate skills como código: PR review antes de mergeer, changelog quando muda comportamento, semver simples (v1.0, v1.1). Evita "skill nova quebrou o cron de backup" sem aviso.
🪐 Multi-agente Kanban (v0.13.0)
A grande novidade do v0.13.0 "The Tenacity Release" é o sistema Kanban multi-agente. Em vez de você orquestrar manualmente, um perfil orquestrador cria um board durável, define cards de tarefa, e múltiplos workers Hermes pegam, trabalham e fecham.
📜 Citação dos release notes
"Spin up a durable board, drop tasks on it, and let multiple Hermes workers pick them up, hand off, and close them out. Heartbeats, reclaim, zombie detection, retry budgets, and a hallucination gate keep the team honest."
💓 Heartbeats
Cada worker bate ping no board. Sem heartbeat por X minutos = considerado travado. Tarefa volta pro topo.
🔄 Reclaim
Tarefa abandonada por worker travado é "reclamada" por outro disponível. Trabalho não trava por causa de um worker zumbi.
🧟 Zombie detection
Processo pendurado (CPU 0%, sem heartbeat) é detectado e morto. Evita worker fantasma consumindo recurso.
🎯 Hallucination gate
Antes de fechar card, valida que a saída faz sentido (testes passam, output não-vazio, etc). Bloqueia "completou" sem ter feito.
🎯 Casos de uso típicos
- •Geração de conteúdo em massa: 1 orquestrador + 3 workers de redação + 1 revisor
- •Análise de dados: dividir dataset em N pedaços, cada worker processa um
- •Refactor de código: orquestrador descreve mudança, workers aplicam por arquivo
- •Pesquisa paralela: N temas, N workers, consolidação no final
🎯Resumo do módulo
Próximo módulo:
6.2 - 📊 Dashboard, gateway, túnel, Kanban