Agente Gerenciado Na Nuvem Ou Rodando Na Sua Máquina? Hermes Contra Managed Agents

Semana passada um colega que toca a área de dados de uma empresa média me mandou uma pergunta curta no fim do expediente: "se eu fosse montar um agente interno hoje, colocava na nuvem de um fornecedor ou rodava numa máquina nossa?". Ele tinha acabado de ver o preço de um DGX Spark numa proposta de fornecedor e, na mesma semana, lido que a OpenAI estaria preparando o próprio serviço de agentes gerenciados. A dúvida dele não era técnica, era de orçamento e de risco: capex numa caixa que fica na sala dele ou opex numa conta de tokens que cresce todo mês.

Não respondi na hora, porque percebi que a resposta honesta dependia de coisas que eu mesmo não tinha organizado. Em maio escrevi aqui sobre Hermes e OpenClaw como dois caminhos para agentes persistentes, um que aprende e outro que controla. Aquele post terminava com cautela sobre dar acesso amplo a um agente e sobre auditar o que ele aprende. De lá para cá o Hermes teve pelo menos duas releases grandes em julho e uma sequência de correções em setembro que mudam um pouco o quadro.

Do outro lado, os agentes gerenciados saíram do papel e já são produto de mais de um fornecedor. A Anthropic tem o Claude Managed Agents desde abril, o Google colocou Managed Agents no Gemini API em junho, e a OpenAI, segundo a Forbes, teria algo parecido reservado para a DevDay. A pergunta do meu colega, então, é a pergunta que muito head de tecnologia vai fazer nos próximos meses.

Este post tem duas metades. Na primeira, atualizo o que o Hermes ganhou desde maio, sem reexplicar o que já está no post anterior: as releases Judgment e Quicksilver, os recursos de agosto, a leva de confiabilidade de setembro e o caminho local que a NVIDIA vem empurrando. Na segunda, monto a comparação que eu queria ter tido na hora de responder: agente gerenciado na nuvem contra agente self-hosted, critério por critério, incluindo o que ninguém gosta de discutir, que é o risco de um agente que escreve as próprias skills.

---

O Que O Hermes Ganhou Entre Maio E Agosto

Para situar: quando escrevi em maio, o Hermes já era o agente open source da Nous Research com a proposta de "crescer com você", memória persistente e skills. Segundo a NVIDIA, em post de 13 de maio, o projeto tinha passado de 140 mil estrelas no GitHub em menos de três meses e era o agente mais usado do mundo segundo o OpenRouter. São números de divulgação, não auditoria.

A primeira release grande depois disso foi a v0.18.0, chamada "Judgment", de 1º de julho. O nome é bom porque descreve a tese: o agente precisa julgar se terminou o trabalho, não só parar de gerar texto. As notas de release falam em uma varredura de cerca de 700 itens de prioridade P0 e P1 fechados, o que por si só é um sinal de amadurecimento de projeto. Mas as funcionalidades que mais me interessam para quem pensa em adoção são três. O /goal introduz contratos de conclusão, em que o agente verifica o trabalho contra evidência concreta antes de declarar a tarefa encerrada. O /learn transforma um fluxo que você acabou de executar em skill reutilizável. E o /journey mostra, numa linha do tempo, as memórias e skills que o agente acumulou.

Na mesma release entrou o Mixture-of-Agents como modelo selecionável: em vez de escolher um único modelo, você escolhe um conjunto nomeado de modelos de referência, com o raciocínio de cada um visível. E veio a delegação em background, que permite abrir vários subagentes sem travar a conversa principal.

Vinte dias depois saiu a v0.19.0, "Quicksilver", focada em velocidade. O número de destaque é o time-to-first-token do primeiro turno cerca de 80% menor em todas as plataformas, segundo as notas do projeto. O app desktop passou a renderizar markdown em streaming 14 vezes mais rápido. Mas os itens que eu destacaria para quem avalia risco são outros dois: a integração com Bitwarden e 1Password como fonte de segredos, que tira credencial de arquivo solto, e o transcript ao vivo de subagentes, que deixa acompanhar o que os delegados em background estão fazendo. A mesma release traz "smart approvals" ligados por padrão, em que um modelo independente revisa comandos sinalizados em vez de pedir aprovação manual para tudo.

Em agosto e nos meses recentes, pelo que os changelogs agregados pela Gradually e pelo Releasebot descrevem, vieram o Bot Mode, que coloca múltiplos agentes conversando em grupo, orquestração e steering ao vivo da delegação em background, voz com TTS em streaming e wake word, app desktop nativo para macOS, Linux e Windows, e uma rodada de hardening de credenciais e de defesa contra prompt injection, incluindo os arquivos de instrução do agente.

---

Setembro: Uma Release Que Fala De Confiabilidade

A release 2026.9.24, de 24 de setembro, fecha uma sequência de versões de setembro com um foco que raramente aparece em manchete: confiabilidade. Olhando o changelog, os itens são menos vistosos e mais reveladores. Sessões remotas não expiram mais quando há rajadas de refresh. Foram corrigidos writers duplicados no banco de estado, que causavam vazamento de memória em processos longos. Corrupção no índice full-text deixou de derrubar a conversa. E sessões não conseguem mais ler o banco de outro perfil.

Esse último item merece uma pausa. Se sessões conseguiam ler dados de outro perfil, havia um problema de isolamento. Em uso pessoal, com um único usuário, isso é um bug chato. Num cenário em que perfis separam contextos, por exemplo trabalho e pessoal, ou dois clientes diferentes, é um vazamento de dados entre fronteiras que você achava que estavam fechadas. A correção é boa notícia. O fato de ter existido é informação útil para quem está pensando em colocar o Hermes num fluxo com dados sensíveis.

O ponto estratégico é este. Quando você escolhe um agente gerenciado na nuvem, essa categoria de problema é do fornecedor. Quando escolhe rodar o Hermes numa máquina sua, ela é sua. A release de setembro não é um argumento contra o caminho local, mas é um lembrete concreto de que "rodar na minha máquina" inclui atualizar, monitorar e às vezes descobrir que a versão anterior tinha um vazamento de memória que explicava aquele processo que precisava ser reiniciado toda semana.

Há um lado positivo que também vale registrar. Um projeto que dedica uma release inteira a sessões, banco de estado, índice e isolamento está priorizando o que importa para uso sério, e não só a próxima funcionalidade de demo.

---

Auto-Melhoria: A Promessa E A Conta De Governança

A tese central do Hermes continua sendo a mesma que discuti em maio, agora com mais ferramental em volta. Pelo que a NVIDIA descreve, o agente escreve e refina as próprias skills a partir de tarefas complexas e de feedback, evoluindo as capacidades com o tempo. O /learn torna isso explícito: você executa um fluxo, pede ao agente para aprender, e ele cristaliza aquilo num procedimento reutilizável. O /journey deixa ver o que foi acumulado.

É uma ideia poderosa por um motivo simples: a maior parte do custo de usar agente no dia a dia é reexplicar contexto. Já escrevi sobre isso quando tratei de memória compartilhada entre agentes e o problema do estado mutável, e a conclusão lá vale aqui. Memória que persiste é estado que muda, e estado que muda sem revisão acumula erro.

Skill auto-escrita é um caso mais agudo desse problema. Uma memória errada enviesa uma resposta. Uma skill errada vira procedimento: ela vai ser executada de novo, com as mesmas permissões, em contextos parecidos, sem que ninguém tenha lido o que ela faz. Pense num cenário hipotético: um time pede ao agente para aprender o fluxo de "limpar ambiente de staging". Na primeira execução, o ambiente tinha só recursos temporários. A skill registra "apague tudo que tiver a tag staging". Três meses depois, alguém cria um recurso compartilhado com essa tag. A skill não sabe disso.

Por isso eu trato auto-melhoria como promessa com custo de governança, não como funcionalidade pronta. A promessa é real: um agente que aprende o jeito do time reduz fricção. O custo também é real: cada skill nova é código não revisado entrando num sistema com acesso à máquina. A prática que eu recomendaria é tratar o diretório de skills como tratamos código: versionado, com diff visível, com revisão humana antes de uma skill nova ganhar permissão de escrita ou ação externa. O /goal com contratos de conclusão e as smart approvals ajudam, mas eles verificam execução, não intenção. Uma skill pode passar no contrato e ainda estar fazendo a coisa errada.

---

O Caminho Local: DGX Spark, LM Studio E Ollama

A outra metade da história do Hermes em 2026 é o hardware. A NVIDIA publicou em maio um post inteiro sobre rodar o Hermes em PCs com RTX e no DGX Spark, e o argumento é direto: o Hermes foi otimizado para uso local e sempre ligado, e o DGX Spark, com 128 GB de memória unificada e 1 petaflop de desempenho de IA, consegue rodar continuamente modelos de 120 bilhões de parâmetros do tipo mixture-of-experts. O post cita suporte nativo a LM Studio e Ollama, além de llama.cpp.

É importante ler isso com o filtro certo. É material da NVIDIA, que vende o hardware. Os números de memória e petaflop são especificação do produto. As afirmações sobre qualidade de modelos específicos, como o Qwen 3.6 de 35B rodando em cerca de 20 GB e superando antecessores de 120B, são afirmações de divulgação, não benchmark independente.

O que a NVIDIA descreve, e que me parece o ponto mais relevante, é a frase de que o Hermes é "uma camada ativa de orquestração, não um wrapper fino", permitindo agentes persistentes no dispositivo em vez de execução tarefa a tarefa. Essa é a diferença de modelo mental. Um agente gerenciado na nuvem tende a ser pensado como execução por sessão: você abre, ele trabalha num sandbox, você fecha. Um agente local sempre ligado é pensado como processo residente, que está lá quando você chega de manhã, com memória e skills do dia anterior.

Para o meu colega com a proposta de DGX Spark na mão, a pergunta prática é qual modelo vai rodar ali e se ele é bom o suficiente para as tarefas do time. Já discuti em outro post quando modelo aberto rodando localmente faz sentido contra APIs fechadas, e a lógica continua valendo: modelo aberto local ganha em controle de dados e custo marginal, e costuma perder na fronteira de capacidade. Um agente é tão bom quanto o modelo que o dirige em tarefas de raciocínio longo. Se o trabalho do time exige o topo da curva, o Hermes pode apontar para uma API de fronteira, mas aí o conteúdo das conversas sai da empresa e parte do argumento de "tudo local" some, mesmo com memória e skills na sua máquina.

---

Do Outro Lado: O Que Os Agentes Gerenciados Entregam

Os agentes gerenciados atacam o problema oposto. Quando escrevi sobre o Claude Managed Agents e a infraestrutura que a Anthropic assume por você, a lista de dores era exatamente a que o Hermes precisou resolver em setembro: sandbox, estado persistente, retry, monitoramento de execuções longas, segurança de chaves, escala. A proposta da Anthropic, em beta público desde abril, é que você define o agente e a plataforma cuida do que está embaixo.

O Google seguiu em junho com Managed Agents no Gemini API, e o recorte ali foi o sandbox Linux efêmero com AGENTS.md e SKILL.md versionáveis. O ambiente sobe, o agente trabalha, produz o artefato e o ambiente desaparece. Isso reduz persistência acidental e torna cada execução mais reproduzível. É quase a filosofia inversa do agente local sempre ligado: em vez de um processo residente que acumula, uma execução descartável que começa limpa.

A OpenAI é a terceira peça, e aqui preciso ser cuidadoso. O que existe publicamente é uma reportagem da Forbes, de 21 de setembro, dizendo que a empresa planeja apresentar um serviço para construir e gerenciar agentes na DevDay, com base em código detectado pelo TestingCatalog. Não trato isso como produto até ver documentação. O ponto relevante para esta discussão é só que os três maiores fornecedores de modelo parecem convergir para o mesmo formato: o agente como serviço hospedado, não como software que você instala.

Essa convergência diz algo sobre para onde o mercado está indo. Trocar de modelo numa chamada de API é mudar uma string. Trocar de plataforma de agente é migrar definições, ferramentas, estado, logs e integrações. Isso torna a decisão mais cara de reverter.

---

A Tabela Que Eu Levaria Para A Reunião

Organizei os critérios que acho que um head de tecnologia precisa discutir antes de escolher. Não há preço na tabela de propósito: o custo depende do volume, do modelo e do hardware, e qualquer número que eu colocasse aqui seria invenção. O que dá para comparar é a natureza do custo.

Critério	Agente gerenciado (Claude, Gemini)	Agente local/self-hosted (Hermes)
Controle de dados	Dados passam pela infraestrutura do fornecedor; depende de contrato e região	Pode ficar 100% interno se o modelo também for local
Custo	Opex: tokens e execução, cresce com uso	Capex em hardware + energia + tempo de gente; custo marginal por tarefa baixo
Latência	Rede + fila do fornecedor; modelos de fronteira	Sem rede se o modelo for local; depende do hardware e do tamanho do modelo
Manutenção e operação	Do fornecedor: sandbox, estado, escala	Sua: atualizar, monitorar, corrigir banco de estado e isolamento
Segurança do ambiente	Sandbox efêmero isola cada execução	Agente com acesso à máquina; isolamento depende da sua configuração
Aprendizado persistente	Mais limitado e mais controlado; estado definido pela plataforma	Skills e memória auto-escritas; exige revisão
Lock-in	Alto na plataforma de agente, mesmo que o modelo mude	Baixo no agente (open source); moderado no hardware

Duas linhas pedem comentário. A de custo engana quem olha só o preço. Um DGX Spark é uma compra única, mas quem vai atualizar o sistema, acompanhar as releases, investigar por que o processo está consumindo memória e responder quando o índice corromper? Do outro lado, o opex de tokens é previsível por tarefa e imprevisível por mês, porque agente em loop consome muito mais que chat.

A linha de segurança é a que mais me preocupa no caminho local. Um agente gerenciado roda num sandbox que o fornecedor desenhou para ser descartável. Um agente local sempre ligado roda com as permissões que você deu, na máquina onde ele está, com acesso aos arquivos, à rede interna e às credenciais que estiverem ao alcance. A integração com gerenciador de senhas da Quicksilver e o hardening contra prompt injection dos meses recentes melhoram o quadro, mas não mudam a natureza do problema: a fronteira de isolamento é responsabilidade sua. A correção de setembro sobre sessões lendo banco de outro perfil mostra que essa fronteira pode falhar mesmo quando você acha que configurou certo.

A linha de lock-in é a que mais favorece o local. O Hermes é open source, roda com LM Studio, Ollama ou API de terceiros, e as skills são arquivos seus. Se o projeto tomar um rumo de que você não gosta, a porta de saída existe. Num agente gerenciado, as definições, os logs e o histórico de execução vivem na plataforma, e o formato de exportação é decisão do fornecedor.

---

Como Eu Dividiria A Decisão

Se eu tivesse que responder ao meu colega hoje, não escolheria um lado. Dividiria o trabalho pelo tipo de dado e pelo tipo de tarefa.

Para tarefas que tocam dado sensível que não pode sair da empresa, e que um modelo aberto resolve bem, como triagem de documentos internos, resumo de tickets, classificação e busca em base de conhecimento, o caminho local faz sentido. Um agente como o Hermes rodando com modelo local numa máquina dedicada, com perfil isolado, sem acesso à rede externa e com skills revisadas, é defensável tanto em custo quanto em compliance. O preço é assumir operação: alguém do time precisa ser dono daquele sistema como seria dono de qualquer outro serviço interno.

Para tarefas que exigem modelo de fronteira, execução de código não confiável ou escala variável, como agentes que rodam em resposta a eventos de clientes, processamento em lote que dispara centenas de sessões, ou trabalho de raciocínio longo em que a diferença de qualidade do modelo aparece, o agente gerenciado ganha. O sandbox efêmero é exatamente o que você quer quando o agente vai executar código que ninguém revisou, e pagar por token é melhor do que dimensionar hardware para o pico.

O que eu evitaria é a decisão por inércia nos dois sentidos. Comprar hardware porque "local é mais seguro" sem ter alguém para operar é trocar risco de fornecedor por risco de abandono. Adotar a plataforma de agente do fornecedor de modelo que o time já usa, só porque está a um header de distância, é aceitar lock-in sem ter pesado a alternativa. Os dois caminhos são legítimos. O erro é não ter decidido.

---

Conclusão

O Hermes de outubro é um projeto mais maduro que o de maio. Julho trouxe verificação de trabalho, aprendizado explícito, delegação em paralelo e ganho de latência. Setembro trouxe algo menos vistoso e mais importante: a admissão, pelo changelog, de que operar um agente sempre ligado é operar um sistema com estado, com todos os problemas que isso implica. Para quem avalia adoção, essa release vale mais do que qualquer funcionalidade nova, porque mostra o tipo de problema que você vai herdar ao escolher o caminho local.

Do lado gerenciado, Claude e Gemini já oferecem o oposto: sandbox descartável, estado sob responsabilidade do fornecedor e escala sem hardware. A OpenAI, se a reportagem se confirmar, vai completar o trio. O custo é um lock-in mais profundo do que o de API de modelo e menos controle sobre onde o dado circula. Nenhum dos lados é gratuito, e a tabela acima é mais útil como roteiro de conversa do que como veredito.

A parte que continuo sem resposta fechada é a auto-melhoria. A promessa de um agente que escreve as próprias skills é real e resolve uma dor que todo mundo que usa agente conhece. Mas ainda não vi um processo de governança maduro para revisar o que o agente aprendeu antes de deixá-lo agir com base nisso, nem no open source nem nos fornecedores. Até existir, eu trataria cada skill auto-escrita como um pull request de um colaborador novo e muito rápido: provavelmente útil, eventualmente errado, e sempre digno de revisão antes do merge.

Fontes:

• NVIDIA Blog — Hermes Unlocks Self-Improving AI Agents, Powered by NVIDIA RTX PCs and DGX Spark
• GitHub — NousResearch/hermes-agent Releases
• Gradually.ai — Hermes Agent Changelog
• Releasebot — Hermes Agent Updates
• Forbes — OpenAI Plans To Introduce Managed Agents At DevDay 2026