🆚 Hermes vs o Mercado

Hermes tem gateway nativo para Telegram, Discord, WhatsApp, Slack, iMessage, Signal, Teams, Matrix e mais 12 plataformas. Claude Code roda exclusivamente no terminal — sem gateway de mensagens.

Mensageria é o que transforma o agente em "sempre disponível". Sem gateway você só usa quando está no PC. Pra agente proativo via celular, Hermes é a única opção entre os dois.

Gateway = módulo do projeto, não wrapper externo. hermes gateway setup roda wizard. Claude Code precisaria de stack extra (bot custom + bridge) pra equivalente.

Hermes inclui agendador de tarefas com entrega direta no canal de mensagem ("todo dia 8h, manda resumo no Telegram"). Claude Code não tem cron embutido — você teria que orquestrar via crontab do sistema.

Tarefas recorrentes (resumos, alertas, auditorias, backups) são onde agente proativo brilha. Sem cron + gateway nativo, o operacional cresce muito.

Hermes cron = jobs que o agente executa em runtime, com LLM raciocinando o resultado. Crontab + Claude Code = você precisa codar o passo de envio + a chamada.

Hermes mantém SKILL.md como documentos YAML estruturados com progressive disclosure (só carrega o que importa pra tarefa atual). Claude Code usa CLAUDE.md e system prompts livres, sem catálogo indexado.

Em projetos pequenos, CLAUDE.md livre é mais simples. Em escala (centenas de procedimentos), o catálogo de skills evita estourar contexto e facilita reuso entre máquinas.

Skills hub = compartilhamento entre usuários. CLAUDE.md = só seu projeto. Hermes carrega skill por demanda; Claude Code carrega CLAUDE.md inteiro toda sessão.

Hermes conecta a OpenAI, Anthropic, OpenRouter, modelos locais (Ollama/llama.cpp), MiniMax OAuth e Codex OAuth. Claude Code é acoplado ao modelo Claude via API Anthropic.

Multi-provedor importa pra controle de custo, fallback quando uma API cai e privacidade (modelo local). Lock-in num único provedor é risco operacional.

Hermes pode usar Codex OAuth (ChatGPT Plus $20/mês) — barato pra coding. Claude Code = pay-per-token Anthropic ou Claude Pro. Cada um otimiza pra um perfil de gasto.

v0.13.0 introduz Kanban multi-agente com heartbeat, reclaim e zombie detection. Workers pegam tarefas, marcam status, devolvem pro pool se travarem. Claude Code não tem coordenação multi-agente nativa.

Quando uma tarefa é grande demais pra um agente só (ex: refactor multi-repo, processar 1000 emails), você precisa coordenar workers. Sem Kanban, vira gambiarra com filas externas.

Kanban = board de tarefas (To Do / Doing / Done). Heartbeat = worker prova que está vivo. Reclaim = se travou, outro worker pega. Zombie detection = ninguém respondeu, marca pra revisão.

Hermes ganha em: assistência 24/7 via mensagem, automações agendadas, usuários não-técnicos no Telegram/WhatsApp, multi-agente Kanban. Claude Code ganha em: raciocínio profundo de código, refactor complexo, review de PR sentado no PC.

Forçar a ferramenta errada gera atrito. Tentar usar Hermes pra hardcore coding com Claude Sonnet 4.5 raciocinando 30 min num PR é frustrante. Tentar usar Claude Code pra cron de marketing também.

Default profissional em 2026: Claude Code no PC + Hermes no Telegram, ambos apontando ao mesmo repo Git. Não é "ou", é "e". Detalhamos a stack híbrida em 5.6.

OpenCode é CLI puro de coding open source. Hermes é generalista com gateway, skills hub, memória persistente. Hermes tem skill bundled opencode que delega tarefas de coding ao OpenCode CLI — coexistem.

Pra workflow de vida completa (código + comunicação + automação), Hermes é mais amplo. Pra engenharia de software pura, OpenCode foca melhor. Saber a divisão evita escolha errada.

Diferenciais Hermes: gateway 20+ plataformas, skills hub agentskills.io, MEMORY.md/USER.md, multi-provedor com OAuth. OpenCode: foco exclusivo em desenvolvimento de software.

Codex CLI é o CLI da OpenAI, requer conta OpenAI/ChatGPT. Hermes usa Codex como um dos provedores opcionais via OAuth. E tem skill bundled codex que delega tarefas ao Codex CLI como subagente.

Codex via ChatGPT Plus ($20/mês) sai mais barato que pay-per-token Anthropic pra uso pesado. Saber que Hermes consome Codex permite usar a subscription que você já paga.

Codex CLI = terminal-only, sem cron, sem skills, sem gateway. Hermes oferece tudo isso por cima e ainda usa Codex como motor quando você manda. Combinação forte.

Cursor é IDE com copilot embutido (autocompletion inline, chat lateral). Hermes é agente headless rodando em VPS, respondendo via Telegram. Hermes detecta e respeita .cursorrules e .cursor/rules/*.mdc.

Não competem diretamente. Cursor é pra desenvolvimento interativo. Hermes é pra automação 24/7 e ambientes sem GUI. Saber que regras de projeto são compartilhadas entre os dois evita duplicação.

Cursor = pago (plano separado). Hermes = open source, custo só da inferência. Mesma .cursorrules pode guiar Cursor no PC e Hermes no servidor.

Você usa Cursor sentado no PC (autocomplete, chat inline). Quando precisa que o agente faça algo no servidor (deploy, cron, leitura de email), pede pro Hermes via Telegram. Os dois leem a mesma .cursorrules.

Esse fluxo é o sweet spot pra dev solo. Cursor produz código, Hermes opera infra. Sem conflito de regra porque a fonte de verdade é uma só (Git + rules file).

Convenção: commit das rules → ambos puxam ao iniciar sessão. Memória do Hermes (MEMORY.md) registra o que foi feito; Cursor segue contexto interativo.

Hermes vem com skill codex que sabe invocar o Codex CLI como subprocess pra tarefas de código pesadas. Você fala "Hermes, usa Codex pra refatorar esse módulo" e ele orquestra.

Junta o melhor dos dois: Hermes coordena, recebe contexto via Telegram, gerencia memória; Codex executa o trabalho de coding com modelo otimizado. Sem você ter que escolher.

Mesmo padrão funciona com Aider (skill aider) e OpenCode (skill opencode). O Hermes vira o "controller" que decide qual subagente chamar pra cada tipo de tarefa.

Coding interativo no IDE? Cursor. Coding via terminal? OpenCode ou Codex CLI. Agente proativo via mensagem com automações? Hermes. Tudo junto na rotina? Os quatro coexistem com Hermes orquestrando.

Decisão errada gera atrito diário. Decisão certa = você acelera 3x sem ficar trocando de ferramenta toda hora.

Stack típica de dev solo em 2026: Cursor + Codex CLI (subscription Plus) + Hermes (Telegram + cron). 100% cobrado em uma única subscription OpenAI + um VPS barato.

n8n usa workflows visuais com nós conectados (drag-and-drop, igual Zapier mas open source e auto-hospedável). Hermes usa linguagem natural + skills em Markdown — sem interface de desenho de fluxo.

Quem prefere visual e tem fluxos determinísticos vai pra n8n. Quem prefere chat e quer raciocínio adaptativo vai pra Hermes. A escolha define a mentalidade da equipe.

Workflow n8n = sequência de nós (Trigger → HTTP → Code → Webhook). Skill Hermes = procedimento Markdown que o LLM lê e adapta na hora.

Hermes usa LLM para decidir próximos passos em runtime — se algo muda no input, ele adapta. n8n executa a sequência exata que você desenhou — se input quebrar o esperado, o nó falha.

Adaptativo é melhor pra entrada não-estruturada (mensagem do usuário, email, documento livre). Determinístico é melhor pra integração de APIs com schema fixo.

"Resume esse email e responda no tom da empresa" — Hermes ganha. "Quando webhook X chegar, chama API Y, salva no Postgres, manda Slack" — n8n ganha.

n8n requer banco de dados (Postgres ou SQLite), webhook server, configuração de cada nó. Hermes roda com pip install hermes-agent + uma API key — pronto.

Pra começar e validar uma ideia, Hermes sai em 10 min. n8n exige planejamento de infra (DB, backup, secrets). Em produção pesada, a infra do n8n compensa.

Hermes em VPS minúsculo (1GB RAM) já roda. n8n recomenda 2GB+ por causa do DB. Em Hostinger, ambos têm one-click separado.

n8n requer entender cada nó (HTTP Request, Code, Webhook, IF, Loop, etc), credenciais, expressões. Hermes aceita instruções em linguagem natural — você descreve a tarefa.

Equipe não-técnica adota Hermes em horas. n8n tem barreira de entrada maior (semanas pra dominar). Em compensação, n8n dá controle visual cirúrgico.

"Pesquise como agendar um cron no Hermes" → ele responde em texto. n8n: você lê doc, arrasta nó "Schedule Trigger", configura cron expression, salva.

Hostinger lista n8n como aplicação one-click separada do Hermes. Os dois podem coexistir no mesmo VPS, com Hermes como camada de inteligência sobre automações n8n.

Combinação real: n8n executa workflow visual (sincroniza CRM, dispara webhook). Hermes adiciona raciocínio adaptativo (resume, classifica, decide tom). Pipe de webhook entre os dois.

n8n chama webhook do Hermes via HTTP node. Hermes recebe via gateway "browser/http", processa, devolve. Você ganha visualização do n8n + inteligência do Hermes.

n8n: workflows determinísticos pesados (ETL, sync entre 5+ sistemas, webhooks com schema rígido), audit trail visual, equipe ops/marketing. Hermes: inteligência adaptativa (mensagens humanas, decisões com contexto), automação pessoal, equipe pequena.

Forçar Hermes pra ETL repetitivo é caro (LLM em cada execução). Forçar n8n pra "respondam emails no tom da empresa" é improdutivo (regex não cobre nuance).

Combo recomendado: n8n na camada de integração + Hermes na camada de raciocínio. Webhook entre os dois é colinha simples.

LangChain/LangGraph são frameworks Python para desenvolvedores construírem aplicações LLM. Hermes é agente pronto com instalador, gateway e interface — você baixa e usa.

Quem precisa embedar IA em produto custom usa LangChain. Quem precisa de agente operável imediatamente usa Hermes. Confundir os dois gera projeto que nunca termina.

LangChain te entrega blocos de Lego (LLM, Tool, Memory, Retriever, Chain, Agent). Hermes te entrega o brinquedo montado e pronto pra rodar via Telegram.

LangGraph: desenvolvedor Python que quer definir grafos de agentes em código. Hermes: usuário (técnico ou não) que quer um agente funcionando via hermes no terminal ou Telegram.

Cada um se vende pra quem se beneficia. Forçar não-dev a montar grafo LangGraph é frustrante. Forçar dev profissional a operar só em chat é limitante pra produto.

LangGraph = control flow explícito (nodes, edges, state). Hermes = control flow implícito (LLM decide). Trade-off entre controle e simplicidade.

SKILL.md são procedimentos em Markdown — qualquer um edita no editor. LangChain usa chains e tools em Python — muito mais poder programático, mas requer código e testes.

Markdown é leve mas limitado a linguagem natural. Python é poderoso mas exige skill técnica. Escolha alinhada ao perfil do mantenedor.

Skill: progressive disclosure, YAML front matter, lido pelo LLM em runtime. Tool LangChain: função Python tipada, executada determinísticamente.

LangChain tem ecosystem de 500+ integrações (vector stores, retrievers, parsers, document loaders). Hermes tem plugin system para hooks + skills hub com centenas de skills.

Pra RAG complexo com 10 vector stores e parsers exóticos, LangChain ganha. Pra agente operacional com gateway de mensagem e cron, Hermes ganha. Cada um especializa onde investe.

Hermes plugin = hook em ciclo de vida (pre-tool, post-message). Skill = procedimento. LangChain integration = adapter pra serviço externo.

Hermes roda standalone com gateway nativo. LangChain requer servidor próprio (FastAPI, Flask, LangServe), infraestrutura de hosting, autenticação custom.

Hermes em produção em 1h. LangChain em produção é projeto de semanas (auth, frontend, observabilidade, escala). Custo de tempo é diferente.

LangServe ajuda a expor LangChain como API. Hermes já é a API + interface + persistência. Trade-off: customização vs velocidade.

LangChain/LangGraph: você está construindo um SaaS, app interno ou produto que precisa de IA embarcada com control flow customizado. Hermes: você quer um agente operacional funcionando hoje.

Decidir errado custa meses. Time-to-value Hermes = horas. Time-to-value LangChain = semanas/meses. Avalie o que você está construindo.

Combinação avançada: você pode chamar LangChain de dentro de uma skill ou plugin do Hermes pra um nó específico. Hermes vira o "frontend" e LangChain o "backend de raciocínio".

CrewAI coordena múltiplos agentes com papéis fixos (Researcher, Writer, Editor, etc) definidos em código. Hermes v0.13.0 usa Kanban com workers dinâmicos que pegam tarefas conforme disponibilidade.

Papel fixo é bom pra pipeline previsível (pesquisa → escrita → revisão). Worker dinâmico é melhor pra fila de tarefas heterogêneas onde quem está livre pega o próximo.

CrewAI = "uma empresa com cargos". Hermes Kanban = "uma fila com trabalhadores intercambiáveis". Os dois resolvem multi-agente, mas com filosofias opostas.

Hermes persiste sessões em SQLite com índice full-text FTS5 — qualquer conversa antiga é pesquisável. CrewAI não tem sistema de persistência equivalente por padrão.

Sem histórico, multi-agente vira execução one-shot. Você perde contexto entre runs. Pra agente operacional 24/7, persistência é diferencial enorme.

Tool session_search consulta histórico. CrewAI requer você implementar storage manualmente (Redis, Postgres, etc).

CrewAI é framework Python puro — você escreve script, executa. Hermes tem TUI (terminal interativo), CLI e gateway de mensagens.

Pra produção que rodam pipelines automatizados, framework basta. Pra agente que recebe input humano em runtime via Telegram, framework não cobre.

CrewAI bom pra batch jobs. Hermes bom pra ambiente online com interação. Você pode chamar uma "crew" de dentro do Hermes pra etapas específicas.

AutoGen foca em conversações multi-agente onde agentes dialogam entre si até chegar a uma resposta. Hermes Kanban tem ownership de tarefa — um worker pega, executa, devolve.

Conversação é boa pra resolver problema com debate (cada agente questiona o outro). Ownership é melhor pra fila de trabalho com SLA (quem pega, é responsável).

AutoGen = "comitê deliberando". Hermes = "kanban de equipe". AutoGen pode entrar em loop (debate infinito); Hermes tem heartbeat e zombie detection.

AutoGen tem integração com Azure OpenAI e Microsoft Teams nativamente. Hermes tem integração com Microsoft Teams via gateway, sem dependência Azure obrigatória.

Empresa Microsoft-shop com Azure OpenAI tende a AutoGen. Empresa multi-cloud ou que quer manter portabilidade tende a Hermes.

Ambos MIT. AutoGen tem suporte corporativo Microsoft. Hermes tem comunidade NousResearch + fork openclaw migrado.

CrewAI/AutoGen: você quer pipeline multi-agente codificado, com papéis estáveis e execução em batch. Hermes: você quer agente operável via mensagem, com workers que escalam dinamicamente.

Pra pesquisa acadêmica em multi-agente, AutoGen é referência. Pra produção operacional pessoal/pequena equipe, Hermes ganha em ergonomia.

Avalie quem opera o sistema. Dev Python sentado no PC? CrewAI/AutoGen funciona. Operador em Telegram precisando agendar tarefa? Hermes ganha de longe.

Hermes (proativo via msg, cron, gateway) + Claude Code (cockpit de coding sentado no PC) + GitHub (fonte de verdade pra contexto, skills, configs). Os três apontam ao mesmo repo.

Cada um cobre uma fricção diferente: Hermes pra tarefas em movimento, Claude Code pra raciocínio profundo, GitHub pra estado compartilhado. Sinergia maior que escolher um único.

Repo central tem CLAUDE.md, AGENTS.md, .hermes.md, skills/, soul.md. Cada agente lê seu próprio formato. Commits viram source of truth.

CLAUDE.md fica na raiz do repo, lido pelo Claude Code. .hermes.md (ou MEMORY.md/USER.md) fica no mesmo repo, lido pelo Hermes. Cada um respeita seu próprio formato sem conflito.

Tentar fazer um único arquivo pra ambos vira bagunça. Cada agente tem convenção própria; respeitar isso simplifica manutenção.

Conteúdo comum (overview do projeto, regras gerais) pode estar em README.md e ambos lêem. Específico vai no arquivo do agente.

n8n executa workflow visual determinístico (sincroniza CRM, dispara webhook). Hermes adiciona inteligência adaptativa onde precisa de raciocínio (resumir email, classificar ticket, ajustar tom).

Você economiza custo de inferência (n8n faz a parte determinística sem LLM) e aproveita raciocínio onde dá retorno. Combo barato e poderoso.

Padrão: n8n recebe trigger, decide se precisa de LLM, chama webhook do Hermes via HTTP, recebe resposta, continua o workflow. Hermes vira "função de raciocínio".

Hermes tem plugin system. Você cria plugin Python que importa LangChain e expõe como ferramenta. Hermes chama a ferramenta quando precisa de RAG complexo, parsing de documento ou retriever especializado.

Você ganha o ecossistema LangChain (vector stores, document loaders) sem ter que construir o agente do zero. Hermes vira a casca operacional, LangChain o miolo de retrieval.

Padrão: skill rag-search chama plugin langchain-retriever que devolve trechos relevantes. Hermes raciocina em cima.

Skills bundled codex e aider permitem ao Hermes invocar Codex CLI ou Aider como subprocess pra tarefas de coding pesadas. Hermes coordena, eles executam.

Codex e Aider têm modelos otimizados pra código com integração git superior. Em vez de Hermes fazer coding mediano, ele delega pra ferramenta especializada.

Padrão: você manda mensagem "refatora módulo X usando Aider". Hermes lê contexto, chama Aider via skill, recebe diff, mostra resumo no Telegram.

Tentar substituir Claude Code por Hermes em coding pesado é frustrante (modelo via Codex Plus não é Sonnet 4.5). Tentar substituir Hermes por Claude Code em automação proativa também (sem cron, sem gateway).

Cada ferramenta foi otimizada pra um nicho. Forçar fora dele = trabalho extra, qualidade baixa, frustração diária. Aceitar a divisão = stack mais produtiva.

Regra: cada agente faz aquilo que ele faz melhor. Hermes orquestra. Claude Code raciocina código. n8n integra serviços. LangChain busca em vector store. Aider commita diffs limpos.