🌹 Escala e Maestria

Começar com 1 agente único, sem multiplicar até existir motivo concreto. A maioria das pessoas que cria 3-4 agentes no primeiro mês acaba abandonando 2 deles.

Um agente só, bem treinado e usado, vale mais do que cinco vazios. Operar 1 agente sólido te ensina o ciclo de skills, memória e crons antes de fragmentar.

Heurística: só crie um segundo agente quando o primeiro já tiver pelo menos 5 skills usadas regularmente, 3 crons úteis e 1 mês de uso real.

Quatro critérios concretos: (1) chaves de API diferentes; (2) memória que não pode misturar; (3) função/tom muito distinto; (4) escopo de risco diferente.

Sem critério, viram 5 agentes que fazem quase a mesma coisa. Com critério, cada agente tem responsabilidade clara e atualização independente.

Pessoal e financeiro misturam tom (informal vs sério), chaves (Telegram pessoal vs canal restrito) e risco (acesso à conta bancária). Justifica separar.

Receita testada: pessoal (assistente do dia), marketing (tom de marca), financeiro (acesso restrito), suporte (FAQ + escalação), ops (audit + backup), conteúdo (newsletter, posts).

Você não precisa inventar a divisão. Esse é o recorte que sustenta operações pequenas e médias. Pode começar por 2 verticais e adicionar conforme uso.

Cada vertical = container Docker próprio + .env próprio + skills próprios. Soul.md muda o tom; memory.md muda os fatos; user.md muda quem é o dono.

Modelo mental: VPS é o prédio (recurso físico, IP, banda), Docker container é a sala (isolamento, .env próprio), agente Hermes é o funcionário dentro daquela sala (skills, memória, soul).

Esse modelo evita confusão clássica: "por que minha chave do Telegram não funciona?" geralmente é porque você editou o prédio quando deveria editar a sala.

Múltiplos containers num único VPS é o padrão. Cada um expõe (ou não) sua porta. Backup do VPS protege todos os containers de uma vez.

Skills, MEMORY.md, SOUL.md, USER.md — tudo Markdown versionado. Migrar conhecimento entre agentes é copiar arquivos, ajustar tom no soul e subir novo container.

Faz a multiplicação ser barata. Você cria o agente "marketing" reaproveitando 70% do "pessoal", muda só o soul e algumas skills específicas.

Mantenha um repositório GitHub com skills compartilhadas. Cada container faz git clone e usa só os subdiretórios que precisa.

Recurso novo da v0.13.0 ("The Tenacity Release"): um perfil orquestrador cria um board Kanban durável, define tarefas, e múltiplos workers Hermes pegam, fazem handoff e fecham.

É o caminho de paralelismo real. Você descreve um trabalho grande, ele se quebra em cards, e seus agentes executam em paralelo. Útil pra pesquisa, geração de conteúdo, análise de dados.

Heartbeats mantêm workers honestos. Reclaim devolve tarefa de worker travado. Zombie detection mata processos pendurados. Hallucination gate impede commit de saída suspeita.

A web UI inclui visualização de sessões, lista de canais ativos, crons (cron view), gerenciador de skills, plugins, configurações e — na v0.13.0 — Kanban view multi-agente.

Algumas tarefas ficam mais fáceis visuais: revisar últimas 50 sessões, ativar/desativar plugins, editar arquivos de config. Telegram é ótimo pro dia a dia, mas dashboard é melhor pra manutenção.

Dashboard é apenas leitura/edição do estado interno. Tudo o que ela mostra também está em arquivos de ~/.hermes/.

A dashboard sobe por padrão em localhost:8080 dentro do VPS. Pra acessar do seu laptop: ssh -L 8080:localhost:8080 user@vps e abrir http://localhost:8080.

SSH tunnel evita expor a dashboard publicamente. Nginx + Cloudflare Tunnel é a alternativa quando você quer URL fixa com autenticação.

Nunca abrir a porta da dashboard direto na internet sem auth. Token de admin não é firewall. SSH key + tunnel é o padrão seguro.

Skill bundled "abrir-dashboard": você pede no Telegram "abre minha dashboard" e ela executa o SSH tunnel local, espera a porta abrir e te entrega o link http://localhost:8080.

Reduz fricção. Em vez de decorar comando SSH, abrir terminal e digitar — você fala. Mantém o agente como porta única de operação.

A skill assume que sua chave SSH e o host estão configurados localmente. Não funciona se o agente está no VPS — só rodando localmente no seu Mac/Linux.

Visual de board (To Do, In Progress, Done) que mostra cards de tarefas e qual worker pegou cada uma. Adicionado no v0.13.0 junto com o Kanban multi-agente.

Quando você roda 2-3 workers em paralelo, fica difícil acompanhar pelo Telegram. O Kanban view dá overview imediato: o que falta, o que travou, qual worker está zumbi.

Cards mostram heartbeat dos workers, contagem de retries e estado da hallucination gate. Tarefa marcada zombie volta automaticamente pro topo do board.

A aba de plugins lista todos os plugins instalados, versão, status (ativo/desativado) e botões para atualizar, desativar ou remover. Inclui plugins oficiais (LCM, kanban) e da comunidade.

Manutenção visual evita errar comando no terminal. Atualizações ficam um clique em vez de pull + restart manual.

Atualização de plugin pode quebrar skill que dependia da versão antiga. Sempre olhe changelog antes de atualizar em produção.

A maioria do uso diário cabe via Telegram: pedir tarefas, conferir crons, ler resumos, ajustar memória. Dashboard é para manutenção, não operação.

Quem se acostuma a abrir dashboard pra qualquer coisa perde a praticidade do agente "no bolso". O Telegram é o ponto único de contato.

Regra: se você consegue pedir em texto, peça via Telegram. Só vá pra dashboard quando precisar editar arquivos longos, ver gráfico ou triar dezenas de cards Kanban.

Sintoma: você manda mensagem e não recebe nada. Sequência: hermes gateway status → ler ~/.hermes/logs/gateway.log → conferir TELEGRAM_TOKEN e TELEGRAM_HOME_CHANNEL no .env.

É o problema mais comum. Em 90% dos casos é token errado, home channel não configurado ou gateway parado. Saber a sequência economiza 30 minutos cada vez.

Em Docker, confirme também que o container tem acesso à internet (firewall/iptables). hermes gateway setup re-executa o wizard se algo ficou inconsistente.

Sintoma: localhost:8080 não carrega no laptop. Em VPS sem IP público direto, é esperado — você precisa criar o túnel: ssh -L 8080:localhost:8080 user@vps.

Muita gente acha que está bugado quando na verdade só faltou o túnel. Confirmar que o processo Hermes está rodando na porta correta evita debug perdido.

Alternativa: nginx como reverse proxy com auth básica + HTTPS via Let's Encrypt. Bom quando múltiplas pessoas precisam acessar.

Problema clássico de Docker: o .env certo fica em /root/.hermes/.env dentro do container. No host, monte: ~/.hermes:/root/.hermes.

Quem coloca chaves no .env da raiz do projeto sem volume montado vê o agente subir sem ler nada e fica caçando bug onde não há.

Verificar com docker exec -it hermes env | grep TELEGRAM. Logs com auto-redação ficam em ~/.hermes/logs/errors.log.

Hermes comprime conversas longas automaticamente antes do limite do modelo. Comando /compress força. /usage mostra tokens. v0.13.0 mostra contagem de compressões na status bar.

Sintoma: agente "esquecendo" coisas no meio da sessão. Geralmente é compressão muito agressiva ou mal configurada. Trocar pelo plugin LCM elimina perda.

Use modelo barato pra compressão (google/gemini-2.5-flash via OpenRouter). Plugin LCM oferece compressão lossless sem chamada de LLM extra.

Container Docker roda em UTC por padrão. Hermes precisa de timezone: "America/Sao_Paulo" no config.yaml ou TZ=America/Sao_Paulo nas env vars.

Sem timezone, cron pra "09:00" dispara às 09:00 UTC = 06:00 em Brasília. Você acorda com mensagem do agente 3 horas antes do esperado e não entende por quê.

Afeta: timestamps em logs, agendamento de cron, e a hora injetada no system prompt. Use string IANA padrão (America/Sao_Paulo, Europe/Lisbon, etc).

Dentro do container: docker exec -it hermes bash e use o CLI hermes com subcomandos: gateway status, cron list, config get, doctor.

Quando o Telegram não responde, você precisa de uma porta de diagnóstico fora dele. Terminal do container é o "modo seguro" pra inspecionar tudo.

Logs com auto-redação de secrets ficam em ~/.hermes/logs/. Pode mandar pro suporte sem medo de vazar token.

Três regras: (1) errou 2x → atualiza skill ou memória; (2) repetiu instrução → vira skill; (3) tom errado → ajusta soul. Aplique na hora, não acumule pra depois.

Sem regra, manutenção vira tarefa "quando der tempo" — e nunca dá. Com regra simples, vira reflexo: "isso virou problema duas vezes, agora salva".

Frase mágica: "isso aqui virou skill, salva." O agente cuida do resto. Você não precisa lembrar a sintaxe de SKILL.md.

Mensalmente, peça: "leia sua memória", "leia seu soul", "liste skills ativas", "liste crons ativos". O próprio agente apresenta resumo e sugere podas.

É auditoria barata. Você vê em 5 minutos o que está desatualizado, o que está duplicado e o que ficou órfão. Sem isso, a memória vira lixão silencioso.

Coloque um cron mensal: "sugira poda da memória e me liste 3 skills sem uso recente". Você só aprova ou rejeita.

Memory.md acumula fatos antigos: VPS antigo, projeto morto, preferência que mudou. O agente continua agindo conforme esses fatos e parece "estranho" ou "errado".

Antes de assumir bug do código, abra memory.md. 70% dos "comportamentos estranhos" do Hermes são fato desatualizado lá dentro.

Memória deve ser editada como diário, não como log. Quando algo muda na sua vida, peça: "atualiza memória: agora uso X em vez de Y".

Protocolo de debug: 1) leia memory.md, 2) leia soul.md, 3) leia skill envolvida, 4) só então cheque logs e config. Erros frequentemente são instrução antiga, não bug.

Você economiza horas de debug em código quando o problema é texto. Hermes é 90% Markdown — começar pelo texto cobre a maioria dos casos.

Frase pra usar: "comportamento estranho em X. Audita memory, soul e skill relacionada antes de eu mexer no código."

Cadência: rotação de tokens trimestral; review de skills mensal; auditoria de segurança semanal (cron skill "auditoria de segurança"). Tudo agendado, não manual.

Sem cadência, ninguém faz. Com cron, vira automático: o agente lembra você. É a diferença entre "tenho intenção de" e "está acontecendo".

Tokens vencidos no .env são causa frequente de gateway parado. Auditoria semanal pega ports abertas, processos novos e skills suspeitas.

Hermes não é um app que você instala e está pronto. É um colega: precisa de onboarding, contexto, correção e crescimento. Quem trata como ferramenta estática nunca aproveita.

A diferença entre 1 mês e 1 ano de Hermes é exatamente esta. Quem mantém a relação viva tem agente cada vez mais útil. Quem trata como ferramenta abandona.

Mentalidade final: você é o tech lead, ele é o estagiário sênior. Você aprova, corrige e ensina. Ele executa, lembra e sugere. Cada mês, mais alinhamento.