Você roda hermes update, reinicia o agente e pergunta o que aconteceu com a refatoração de ontem. Ele faz uma pausa e responde que não tem registro de nada. Você abre o config.yaml: memory.provider: honcho continua lá, e o bloco memory.honcho inteiro está intacto. O que falta é só o código — o provider saiu do repositório core, e a sua atualização substituiu apenas a metade do core.

Nada foi perdido. O que você está vendo é o tipo mais desagradável de falha: uma config apontando para uma implementação que não existe mais. O PR #114569, mesclado na main em 18 de setembro de 2026, foi feito exatamente para esse estado: quando o Hermes percebe que o provider de memória configurado está ausente, ele o reinstala a partir do catálogo de plugins, no pin revisado. Veja a seguir como ele decide, por qual caminho a instalação passa, o que acontece quando não dá para instalar e se você precisa fazer alguma coisa.

O que permanece igual: nome, config, dados

A parte tranquilizadora dessa migração é que só o código se muda. Quando um plugins/memory/<name> embutido passa a ser um plugin autônomo do catálogo:

• o nome do provider continua o mesmo (memory.provider: honcho segue funcionando);
• a seção de config continua igual (nenhuma chave sob memory.<name> é tocada);
• o diretório de dados continua no lugar (tudo o que seu agente lembrava está onde sempre esteve);
• os nomes das ferramentas não mudam (as instruções na memória do agente sobre como usar a memória não precisam ser reaprendidas).

A única mudança é que o código agora vive em HERMES_HOME/plugins/<name>. Em teoria, o efeito visível para o usuário deveria ter sido uma reinstalação silenciosa. Este PR é o que faz essa teoria valer.

Dois hooks: hermes update e o agent init

O novo módulo hermes_cli/memory_provider_migration.py expõe um único ponto de entrada, migrate_home(). Ele faz três coisas: lê memory.provider daquele home, verifica se o nome ainda resolve em algum lugar em que o Hermes procura (o diretório embutido, os plugins de usuário daquele home, um entry point) e — somente quando não resolve em lugar nenhum — procura uma entrada de catálogo com o mesmo nome. As três condições precisam bater antes de qualquer instalação.

Dois pontos de chamada diferentes cobrem dois hábitos de atualização:

• hermes update roda isso para todos os homes de profile que compartilham o virtualenv. É o lugar natural: a atualização já está reconstruindo dependências, e as dependências dos plugins são reaplicadas sob os pins do core.
• O agent init roda isso quando load_memory_provider retorna None — ou seja, quando o provider não consegue ser carregado de jeito nenhum — uma vez por processo, por nome. Esse hook existe para quem usa o desktop, atualiza pelo app e nunca roda hermes update na mão.

A instalação em si passa pelo caminho normal de instalação de plugins: o pin revisado da entrada do catálogo, a kill list, as restrições de dependências e o enable-on-install. Nada ganha atalho por ser automático, e uma fonte customizada nunca é substituída.

Um switch importa aqui. Como esse passo instala código, ele respeita security.allow_lazy_installs (ligado por padrão). Se você desligou essa opção por questões de segurança, a migração automática não acontece — e o log diz isso, em vez de deixar a memória morta em silêncio.

Quando não dá para instalar: um comando de verdade, não amnésia silenciosa

O melhor hábito de engenharia nessa mudança é que a falha fica visível e é imediatamente acionável. Três caminhos, três saídas:

Situação	Comportamento
O catálogo não tem entrada para esse provider	Um aviso nomeando exatamente o hermes plugins install <source> a rodar, ou sugerindo um memory.provider diferente
O catálogo tem a entrada, mas a instalação falha (rede, uv, kill list)	O texto de erro do próprio instalador, mais o mesmo one-liner
security.allow_lazy_installs está desligado	Uma linha de log informando que a config impediu a instalação automática

Antes disso, o relato era uma linha em nível DEBUG e nada mais, e é por isso que o sintoma visível para o usuário era simplesmente “o agente de repente não lembra de nada”. Há também uma regra deliberadamente contida dentro da função: ela nunca levanta exceção. O comentário diz isso de forma clara — a memória estar fora do ar não pode derrubar a atualização nem o agente junto.

Uma pequena correção de sintaxe de instalação da qual a migração depende

O mesmo PR faz hermes plugins install owner/repo#subdir ser interpretado corretamente. Antes, o # era colado na URL de clone, então qualquer plugin que vem em um subdiretório do repositório principal não podia ser instalado dessa forma.

Essa sintaxe não é acadêmica. O Honcho traz seu plugin dentro do repositório principal, então a fonte dele pós-migração é plastic-labs/honcho#hermes-plugin-honcho; a do supermemory é supermemoryai/hermes-supermemory. O PR verificou o caminho inteiro em uma instalação real: com o honcho e o supermemory embutidos apagados de um checkout de teste, memory.provider: honcho definido e um AIAgent() de verdade, o agent init instalou plugins/honcho a partir do repositório do mantenedor, com as dependências (honcho-ai, httpx) resolvidas dentro dos pins do core, e o carregou. O painel de configuração do honcho no desktop continuou renderizando seus 33 campos, o CLI hermes honcho continuou sendo descoberto, e uma segunda inicialização não fez nada.

O que fazer agora: uma checagem de cinco minutos

Este PR é trabalho de base — por si só, ele não remove nada do core. Mas a direção é pública: os providers de memória embutidos estão indo para os repositórios de seus mantenedores e para o catálogo (o PR menciona a conversa com os mantenedores do Hindsight, do Honcho e do Supermemory). Então vale saber onde você está:

1. Veja qual provider você usa: hermes config get memory.provider. Se for um dos embutidos (honcho, supermemory, mem0 e companhia), anote o nome.
2. Verifique se ele está embutido ou é um plugin autônomo: hermes plugins list. Depois de uma atualização futura, vê-lo instalado a partir do repositório do mantenedor é o esperado, não um problema.
3. Se alguma atualização deixar o agente amnésico, rode primeiro a linha hermes plugins install que aparecer no log. Assim que a memória voltar, cheque o hermes doctor para ver a saúde do banco de estado e do WAL — o diagnóstico de WAL grande que cobrimos no guia do live writer é o ponto de partida.

Se você quiser primeiro o panorama mais amplo, o guia do catálogo de plugins e a referência do hermes plugins explicam como as entradas de catálogo são revisadas e instaladas. E se você usa o Honcho para roteamento de sessões e workspaces, as configurações daquele guia de roteamento continuam funcionando sem alteração depois da migração.

Status de release

Esses commits entraram na main em 18 de setembro de 2026, e a tag mais recente é a v0.21.3 (nome de tag v2026.9.14, lançada em 14 de setembro), então os hooks de migração ainda não estão em uma release marcada. Instalações via git que rodam hermes update já os têm; quem usa imagem Docker ou cloud recebe com a próxima tag. Confira onde você está:

hermes --version
hermes update

Para contexto, a página da release v0.21.3 observa que as notas curadas completas de tudo desde a v0.21.0 chegam com a v0.22.0 — espere que a mudança dos providers de memória seja uma das seções que valem a leitura por lá.

A lição

A parte interessante não é a instalação automática. É a classe de falha que ela expõe: quando uma config referencia uma implementação que mudou de lugar, o usuário não vê um erro — ele vê uma capacidade desaparecer em silêncio. Três hábitos valem a pena ser roubados da correção: tratar “a implementação está faltando” como um estado de primeira classe que merece ser detectado, encaminhar o reparo automático pelo caminho já revisado em vez de por um atalho e, quando o reparo é impossível, imprimir um comando que alguém realmente possa rodar — a partir de um código que nunca vai derrubar a atualização nem o agente junto.