Por que OpenClaw e Hermes estouraram — e o que o Zero acrescenta

OpenClaw e Hermes não estouraram porque o mundo precisava de mais um chatbot. Eles estouraram porque chegaram no momento exato em que os usuários começaram a fazer uma pergunta mais difícil: e se um assistente de IA pudesse de fato operar?

O OpenClaw tornou essa ideia pessoal. Ele colocou um agente no seu próprio dispositivo, conectou-o aos canais de mensagem que você já usa e deu aos power users a sensação de um assistente local com mãos de verdade.

O Hermes tornou a mesma ideia extensível. Ele transformou o agente em um runtime operável por desenvolvedores: CLI, gateway de mensagens, memória, skills, MCP, cron, backends de terminal e um ciclo de aprendizado que melhora à medida que trabalha.

O Zero surfa a mesma onda, mas a leva para uma direção diferente. OpenClaw e Hermes mostraram que as pessoas querem agentes autônomos. O Zero faz a próxima pergunta: como tornar esse agente seguro, útil e repetível para um time de verdade?

Esta análise se baseia em documentação pública do GitHub e do produto, verificada em 2 de junho de 2026.

A linha do tempo: quando OpenClaw e Hermes apareceram

Ilustração da linha do tempo do estouro dos agentes de IA

Produto	Sinal público	Sinal de estouro	O que representava
OpenClaw	Repositório no GitHub criado em 24 de novembro de 2025; primeiro release público em 25 de novembro de 2025	Mais de 376 mil estrelas e 78 mil forks no GitHub quando verificado em 2 de junho de 2026	O assistente de IA pessoal viral: local-first, self-hosted, acessível por mensagem de qualquer lugar.
Hermes Agent	Repositório no GitHub criado em 22 de julho de 2025; a primeira onda visível de releases começa em 12 de março de 2026	Mais de 176 mil estrelas e 30 mil forks no GitHub quando verificado em 2 de junho de 2026	O runtime técnico de agentes: autoaperfeiçoável, flexível em modelos, nativo de CLI, extensível.
Zero	Repositório open-source criado em 14 de novembro de 2025; o ritmo público de produto/releases acelerou na primavera de 2026	Mais de 100 connectors, superfície de time no Slack/web, execução de trabalho com permissões	O colega de IA do time: trabalho real entre ferramentas SaaS, com governança e auditabilidade.

O timing importa. No fim de 2025 e início de 2026, os desenvolvedores já tinham visto o que os agentes de programação conseguiam fazer. Claude Code, CLIs no estilo Codex, agentes de navegador e modelos com tool-calling tinham tornado o ciclo do agente algo real. Os usuários não queriam mais uma caixa de respostas melhor. Eles queriam um assistente capaz de abrir ferramentas, lembrar o contexto, executar tarefas e voltar com um resultado pronto.

OpenClaw e Hermes capturaram essa demanda, cada um a partir de uma ponta diferente do mercado.

Ilustração dos flywheels de estouro do OpenClaw e do Hermes

Por que o OpenClaw estourou

O estouro do OpenClaw não foi só uma questão de recursos. Foi uma questão de clareza emocional.

Seu README o chama de um assistente de IA pessoal que você roda nos seus próprios dispositivos. Essa mensagem cola na hora. Você não está comprando uma plataforma de workflow. Você não está instalando uma suíte de automação corporativa. Você está criando um agente pessoal que responde no WhatsApp, Telegram, Slack, Discord, iMessage, Signal, Microsoft Teams, Matrix, WeChat, QQ e muitos outros canais.

Isso deu ao OpenClaw três vantagens de estouro.

1. Fez a autonomia parecer pessoal

A ideia matadora não era "framework de agentes". Era "meu assistente, nos meus dispositivos, nos meus chats".

Esse é um enquadramento viral mais forte do que um diagrama de arquitetura técnica. Um assistente local-first gera curiosidade instantânea porque soa como o produto de IA de consumo que faltava: aquilo que vive ao seu lado, escuta, responde, encaminha mensagens, executa ferramentas e parece estar sempre ativo.

O OpenClaw apostou nisso. Tinha um mascote claro, uma identidade forte, uma configuração local concreta e uma promessa simples: se você quer um assistente de usuário único que pareça local, rápido e sempre ativo, é isto.

2. Transformou a distribuição em um recurso

A maioria dos produtos de agentes faz os usuários irem até o agente. O OpenClaw fez o agente ir até o usuário.

A lista de canais é incomumente ampla: WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, IRC, Microsoft Teams, Matrix, Feishu, LINE, Mattermost, Nextcloud Talk, Nostr, Twitch, Zalo, WeChat, QQ, WebChat, macOS, iOS e Android. Essa amplitude não é só trabalho de integração. É estratégia de distribuição.

Cada canal vira uma possível demo. Cada thread de mensagens vira um lugar para mostrar o agente fazendo algo útil. É por isso que era fácil falar sobre o OpenClaw: as pessoas conseguiam se imaginar usando-o imediatamente, sem mudar o lugar onde já se comunicam.

3. Deu controle aos power users

O modelo de Gateway self-hosted do OpenClaw virou parte do apelo. Ele permitia que usuários técnicos rodassem o control plane por conta própria, configurassem canais, gerenciassem pareamentos, instalassem skills, expusessem um Gateway e decidissem quanta autoridade o assistente deveria ter.

Esse controle também criou o principal trade-off. A própria documentação de segurança do OpenClaw o enquadra como um modelo de confiança de assistente pessoal, não como uma fronteira de segurança multi-tenant hostil. Esse é o enquadramento correto. O OpenClaw é poderoso porque o operador é dono do ambiente. Isso também significa que o operador é dono do risco.

Para indivíduos e entusiastas técnicos, isso é aceitável. Para empresas, é uma venda mais difícil.

Por que o Hermes estourou

O Hermes estourou para um público diferente. O OpenClaw fez as pessoas quererem um assistente pessoal. O Hermes fez os desenvolvedores quererem um runtime de agente sério.

Seu README descreve o Hermes como um agente de IA autoaperfeiçoável construído pela Nous Research. A promessa do produto não é apenas "executar ferramentas". É um ciclo de aprendizado fechado: skills criadas a partir da experiência, memórias preservadas entre sessões, busca sobre conversas passadas, troca de modelos, cron, gateway de mensagens, subagentes isolados e backends de terminal que podem rodar localmente, em Docker, via SSH, no Modal ou no Daytona.

Isso posicionou o Hermes como o agente que você poderia operar como infraestrutura.

1. Chegou depois que a categoria já estava visível

A primeira onda visível de releases do Hermes começou em 12 de março de 2026. A essa altura, o OpenClaw já tinha tornado a categoria de agente pessoal impossível de ignorar. Isso ajudou o Hermes. O mercado não precisava ser convencido de que agentes importavam. Os usuários técnicos estavam prontos para fazer uma pergunta de segunda ordem: em qual runtime devo confiar, estender e construir em volta?

O Hermes respondeu com um pacote nativo para desenvolvedores: instalação em uma linha, CLI/TUI, gateway, flexibilidade de provedores de modelo, suporte a MCP, cron, ferramentas, memória e migração a partir do OpenClaw.

2. Transformou o autoaperfeiçoamento em uma ideia de produto

A afirmação mais distintiva do Hermes é o ciclo de aprendizado. Skills, memória, busca de sessões e modelagem de usuário não são apresentados como recursos secundários. Eles são o centro do produto.

Isso importa porque o modo de falha óbvio dos agentes é o esquecimento. Os usuários não querem reconstruir o contexto a cada sessão, reexplicar procedimentos ou curar manualmente cada arquivo de instruções. O Hermes transformou essa dor em uma narrativa de produto: o agente cresce com você.

Essa é uma história forte para desenvolvedores e pesquisadores. Faz o Hermes parecer menos uma ferramenta e mais um sistema que se acumula.

3. Mostrou uma velocidade extrema de releases

As notas de release do Hermes fazem parte da sua história de estouro. A "Velocity Release" de 28 de maio de 2026 afirma 1.302 commits, 747 PRs mesclados, mais de 560 issues fechadas e 321 contribuidores da comunidade desde o release principal anterior. Os releases de 16 e 7 de maio mostram um movimento igualmente agressivo.

Esse tipo de velocidade gera confiança em um produto de infraestrutura open-source. Diz aos usuários técnicos que o projeto está vivo, responsivo e vale a pena construir em volta dele. Também cria um flywheel de comunidade: releases rápidos atraem usuários, os usuários abrem issues e PRs, e o projeto avança mais rápido.

4. Reduziu o custo de troca a partir do OpenClaw

O Hermes também fez algo estrategicamente inteligente: tornou-se legível para os usuários do OpenClaw. O README documenta o hermes claw migrate, que pode importar configurações, memórias, skills, allowlists de comandos, configurações de mensagens, chaves de API selecionadas e instruções de workspace do OpenClaw.

Isso transforma a popularidade do OpenClaw em uma ponte, e não apenas em uma ameaça competitiva. Se um usuário técnico começa com o OpenClaw e depois quer um runtime mais voltado a desenvolvedores, o Hermes tem um caminho.

O que OpenClaw e Hermes ainda deixam por resolver

OpenClaw e Hermes estouraram porque são empolgantes. Mas os mesmos traços que os tornaram virais também expõem a próxima camada do problema.

Eles são mais fortes para usuários que conseguem operar uma stack de agentes. Isso inclui desenvolvedores, power users, entusiastas, pesquisadores e operadores técnicos. Não inclui automaticamente um líder de vendas, gerente de suporte, fundador, profissional de marketing, operador de finanças ou gerente de produto que só quer o trabalho feito com segurança.

As principais lacunas não são lacunas de inteligência. São lacunas de adoção.

Lacuna	Por que importa
Esforço de configuração	Rodar um Gateway, configurar provedores, gerenciar canais e endurecer o acesso são tarefas operacionais reais.
Risco de credenciais	Se o agente pode operar ferramentas poderosas, o time precisa de regras claras sobre o que o agente pode ver, fazer, registrar e aprovar.
Governança de time	Assistentes pessoais não resolvem automaticamente permissões em nível de workspace, uso por membro, política de connectors ou auditabilidade.
Integrações de negócio	Canais de mensagem são úteis, mas os times precisam de acesso confiável a Slack, Gmail, GitHub, Notion, Linear, HubSpot, Sentry, Sheets, Calendar, Drive e mais.
Fluxos de trabalho repetíveis	Uma demo viral não é a mesma coisa que um processo de negócio que roda toda segunda-feira de manhã, semana após semana.

É aí que o Zero vai além.

O que o Zero faz melhor

Ilustração da governança de time do Zero

O Zero não tenta vencer sendo o runtime de agente mais configurável. Ele vence transformando a capacidade agêntica em um produto que os times conseguem de fato adotar.

A diferença é simples: OpenClaw e Hermes são operator-first. O Zero é organization-first.

1. O Zero passa da autonomia pessoal para a delegação de time

O OpenClaw pergunta: como rodo meu próprio assistente pessoal?

O Hermes pergunta: como opero e estendo meu próprio runtime de agente?

O Zero pergunta: como um time delega trabalho real a um colega de IA sem que cada usuário precise virar um operador de agentes?

Essa é uma superfície de produto diferente. O Zero funciona no Slack e na web. As pessoas podem mencioná-lo, atribuir uma tarefa, conectar ferramentas, agendar trabalho e revisar saídas sem saber como funciona um Gateway, um backend de terminal, um servidor MCP ou um daemon local.

Isso importa porque a maioria das empresas não adota ferramentas por meio dos seus usuários mais técnicos. Elas adotam ferramentas quando times não técnicos conseguem usá-las com segurança.

2. O Zero se conecta a sistemas de trabalho, não só a canais de chat

A amplitude de canais do OpenClaw é impressionante. A amplitude de gateway do Hermes é útil. Mas o trabalho de negócio geralmente depende de sistemas SaaS, não apenas da entrega de mensagens.

O Zero se conecta a mais de 100 ferramentas: Slack, GitHub, Gmail, Google Calendar, Google Sheets, Notion, Linear, Sentry, Axiom, HubSpot, Intercom, Figma, Vercel, Dropbox, Airtable, Plausible, Resend, X, Reddit e mais.

Essa camada de connectors muda a categoria. O Zero não é apenas acessível a partir do Slack. Ele pode usar Slack, GitHub, Gmail, Notion, Linear e outros sistemas como superfícies de trabalho. Ele pode fazer triagem no Sentry, abrir issues no GitHub, preparar prospecção, resumir métricas de campanha, redigir um update para o board, agendar um relatório recorrente ou transformar discussões do Slack em decisões estruturadas.

Para os times, essa é a diferença entre um assistente com quem você pode conversar e um colega que consegue concluir o trabalho.

3. O Zero faz das permissões um recurso de produto

Essa é a maior lacuna entre um agente viral e um agente de time adotável.

O modelo de permissões do Zero é connector por connector e ação por ação. A postura padrão é conservadora: ler antes de escrever, perguntar antes de enviar e permitir revogação. Ações sensíveis — enviar e-mail externo, movimentar dinheiro, publicar algo, excluir dados, convidar usuários ou alterar infraestrutura de produção — pausam para aprovação humana.

Isso não é um pequeno detalhe de UX. É o que destrava a adoção.

Uma empresa não pergunta apenas "o agente consegue fazer isso?". Ela pergunta "o agente consegue fazer isso sem nos surpreender, vazar credenciais, excluir dados ou agir sob a autoridade da pessoa errada?".

O Zero é construído em torno dessa pergunta.

4. O Zero protege as credenciais do próprio agente

Sistemas self-hosted podem ser protegidos, mas o operador precisa fazer esse trabalho. O Zero torna isso uma propriedade em nível de plataforma.

A documentação de segurança do Zero descreve execução isolada em microVMs Firecracker, com isolamento KVM em nível de hardware. Cada execução acontece no seu próprio ambiente privado e é destruída após a conclusão. As credenciais são gerenciadas pela plataforma; o agente pode usar as ferramentas conectadas, mas não consegue ver nem extrair os tokens brutos. Os segredos são injetados na camada de rede, e as requisições de saída são analisadas para reduzir o risco de vazamento.

Para times de negócio, essa é uma vantagem prática importante. O agente pode realizar trabalho útil com Gmail, Slack, GitHub e outras ferramentas sem transformar cada credencial em algo que o modelo ou o código do agente possa inspecionar.

5. O Zero foi feito para trabalho recorrente

Uma demo de agente que estoura impressiona uma vez. Um fluxo de trabalho recorrente é valioso toda semana.

O Zero foi projetado para inteligência agendada: varreduras diárias de erros, relatórios semanais de campanha, briefs de métricas às segundas-feiras, follow-ups de leads, verificações de dívida técnica, produção de conteúdo, triagem de suporte e updates de status operacional. O usuário não precisa reprompetar o agente toda vez. O fluxo de trabalho vira uma rotina.

É aqui que o enquadramento de colega de time do Zero importa. Um colega não responde apenas quando perguntado. Um colega assume uma responsabilidade recorrente.

6. O Zero dá auditabilidade aos times

Quando um agente trabalha entre sistemas de negócio, os logs importam. O Zero enfatiza logs completos de atividade, chamadas de ferramentas, histórico de aprovações e execuções auditáveis. Isso facilita revisar o que aconteceu, depurar uma execução e construir confiança ao longo do tempo.

OpenClaw e Hermes dão controle aos operadores. O Zero dá visibilidade aos times.

São tipos diferentes de confiança.

A diferença estratégica

A forma mais simples de entender o mercado é esta:

Produto	O que estourou	Para o que otimiza	Principal limitação
OpenClaw	O assistente de IA pessoal e local	Controle, canais, propriedade self-hosted	O operador é dono da configuração e da segurança.
Hermes Agent	O runtime de agente autoaperfeiçoável	Extensibilidade, memória, modelos, MCP, CLI, cron	Melhor para usuários técnicos que conseguem operar infraestrutura.
Zero	O colega de IA do time	Delegação, connectors, permissões, segurança, trabalho recorrente	Menos sobre experimentação local; mais sobre execução de time gerenciada.

OpenClaw e Hermes ganharam atenção provando que agentes podiam parecer vivos. O Zero ganha adoção tornando os agentes utilizáveis na realidade bagunçada do trabalho em time.

Essa é uma barra mais alta. Os times não precisam só de autonomia. Eles precisam de autoridade delimitada, repetibilidade, observabilidade, segurança de credenciais e uma superfície de produto que pessoas não desenvolvedoras consigam entender.

Conclusão

O OpenClaw estourou porque fez o agente autônomo parecer pessoal e local. O Hermes estourou porque fez o agente parecer extensível, autoaperfeiçoável e tecnicamente sério.

O Zero parte das duas percepções e então sobe na stack.

Ele mantém o que as pessoas queriam do OpenClaw e do Hermes — uma IA que realmente consegue fazer trabalho — mas acrescenta o que as empresas precisam antes de poder confiar nele: mais de 100 connectors de trabalho, acesso via Slack e web, tarefas agendadas, subagentes, permissões em nível de ação, aprovações de ações sensíveis, isolamento de credenciais, execução em microVMs Firecracker e trilhas de auditoria.

É por isso que o Zero não é só mais uma entrada na lista de agentes. Ele é a passagem do agente pessoal e do runtime de desenvolvedor para o colega de IA confiável para trabalho de verdade.