Um desenvolvedor comunitário (Claudio Drews) lançou Memory OS hoje, uma pilha de memória de 6 camadas sob licença MIT que se assenta sobre o framework Hermes Agent da NousResearch. As camadas mapeiam a propósitos de memória distintos: arquivos workspace (MEMORY.md, USER.md, CREATIVE.md injetados no system prompt), histórico de sessões (SQLite + FTS5 busca full-text), fatos estruturados (SQLite + HRR + trust scoring com loops de feedback), Fabric (extração de sessões por LLM, forkeado de Icarus Plugin), base de dados vetorial (Qdrant com vetores cosseno 4096-dimensionais mais BM25 sparse), e um Wiki LLM auto-curado que é re-ingerido de volta em Qdrant. Tudo roda localmente via Docker (Qdrant + Redis + ARQ Worker + Python 3.11+); as chamadas LLM vão ao provider que Hermes suporte (OpenRouter, OpenAI, Anthropic, Ollama).
A arquitetura é um sistema de recuperação em cascata. Em pre_llm_call, quatro fontes (Fabric, Qdrant, Sessions, Facts) são consultadas com busca híbrida primeiro, depois vetores densos, depois léxico, depois SQLite como fallback. A deduplicação por sessão impede o mesmo contexto de aparecer duas vezes em uma janela, e um threshold de relevância filtra antes que nada alcance o modelo. Em post_llm_call e on_session_end, a captura escreve de volta nas camadas. O esquecimento é explícito: um scanner de decay semanal envelhece entradas stale, e a dedup semântica funde memórias quase-idênticas quando a similaridade cosseno excede 0,92. O trust scoring (camada 3) mantém um loop de feedback que ajusta a credibilidade de fontes no tempo. O que falta importa: sem benchmarks publicados sobre qualidade de recall, latência, ou economias de tokens, e sem resolução formal de conflitos de escrita para consistência multi-agente. O repo está em github.com/ClaudioDrews/memory-os, recém-nascido com poucos commits, desenvolvedor único. Tratar como scaffolding early-stage para a ideia de camadas, não como componente production-hardened ainda.
Dois fios de ecossistema. Primeiro, a arquitetura é uma articulação explícita community-built do que a maioria dos builders de agentes acaba montando ad-hoc: um pipeline de memória em camadas onde propósitos diferentes (contexto do sistema, recall de sessão, armazenamento de fatos, busca semântica, extração estruturada, acumulação de conhecimento) recebem mecanismos distintos em vez de colapsarem em um único padrão "vector DB e rezar". Essa camadação é a lição de design que vale levar mesmo se você nunca tocar Memory OS diretamente. Segundo, o posicionamento: Memory OS se contrasta explicitamente com serviços cloud como mem0, Zep, e Letta sendo totalmente local. Isso encaixa na onda mais ampla de "quero a memória do meu agente no meu disco, não na base de dados de outra pessoa," que é uma postura legítima para builds privacy-sensitive ou air-gapped. O trade-off é operacional: uma pilha Docker com Qdrant + Redis + ARQ Worker é mais infraestrutura que chamar mem0 via API. Para builders decidindo entre memória cloud-managed e self-hosted, isso põe uma opção real do lado local do ledger, embora framework-bound a Hermes.
Segunda-feira pela manhã, se você já constrói sobre Hermes Agent: Memory OS vale tentar como drop-in upgrade da memória nativa do Hermes, especialmente se seu agente se beneficia de recall semântico através de longas histórias. Rode sua própria avaliação sobre qualidade de recall e uso de tokens antes de apostar; sem benchmarks publicados significa que você é o benchmark. Se você não está no Hermes, a decomposição de 6 camadas é o takeaway, não o código: workspace + sessões + fatos + extração + vetores + wiki curado mapeia a propósitos distintos que você provavelmente já precisa, separadamente, em qualquer stack que você esteja. Se você despliega um agente privacy-sensitive ou air-gapped e não quer um provider de memória cloud, esta é uma opção fresca para avaliar contra alternativas estabelecidas. Single-developer mais few-commits-old significa apoie-se com cuidado; o valor agora é a arquitetura como documentação, não o código como dependência battle-tested.