10
vmarino
2 min de leitura ·

Pitch: E se seu agente de IA nunca mais esquecesse o contexto do seu projeto?

Já reparou que toda vez que você abre uma nova sessão no Claude Code, Cursor ou Codex, você gasta os primeiros 15 minutos explicando de novo o que o agente já sabia ontem?

Decisão de arquitetura, convenção do time, o motivo daquele workaround estranho no auth.ts — tudo zerado. Na sessão seguinte, lá vai você de novo.

Criei a MOM — Memory Oriented Machine: uma camada de memória persistente pros agentes de IA, acessível via MCP.

O que ela faz:

  • Guarda decisões, padrões e fatos do projeto em arquivos de memória versionáveis (.mom/) — git-friendly, zero vendor lock-in
  • Funciona em múltiplos runtimes: Claude Code, Codex CLI e Windsurf (outros no radar)
  • Recording contínuo via hooks — você não precisa lembrar de "salvar"
  • Recall com citação de fonte nas resposta (o agente devolve o ID da memória de origem; se não tem, ele diz que não tem)
  • Escopos hierárquicos (user > org > repo) com herança
  • Princípio: a MOM lembra, ela não instrui. Ela devolve o que você já sabia, não o que ela acha que você deveria fazer. Isso é o que evita o "agente opinativo que alucina decisão de arquitetura".

Stack atual: Golang + MCP, storage local em arquivos JSON (melhorias planejadas pra essa frente)

Repo: https://github.com/momhq/mom

Estou solo no projeto 🙏 — Soltando múltiplos releases por semana. Feedback de quem convive com essa dor vale ouro. O que falta? O que tá over-engineered? Manda bala nos comentários.

Carregando publicação patrocinada...
4

Meus 2 cents,

Parabens pela iniciativa !

Eh um problema recorrente no trabalho com agentes a questao de memoria de longo prazo: ja existem varias tentativas de solucao, mas ainda eh um campo virgem para ser explorado.

Projeto devidamente starreado e forkeado.

Obrigado por compartilhar !

Post devidamente favoritado via extensão TABNEWS FAVORITOS

Saude e Sucesso !

1
2
3

Sim! Existe redução significativa, principalmente por conta da forma que os dados são coletados e buscados. Em geral há redução significativa no consumo de tokens Input/Output. Temos também uma funcionalidade que força o padrão de comunicação do Agente, conseguindo reduzir entre 30-45% no consumo de tokens. E tem diversas melhorias no radar que vão ajudar ainda mais.

1
2

Depois da v0.11 salva automático. Porém está tendo algumas inconsistencias dependendo do harness que usa. O Claude Code funciona 100%.

Estou trabalhando na v0.13 agora e vai contar com uma mudança de arquitetura que vai garantir a coleta das respostas automaticamente sem custar nada de token e nem precisar de MCP. Vai ficar bala!

2
1

Não temos ainda Adapter pro OpenCode. Vou adicionar na lista pra avaliar. Eu estou tentando cobrir o máximo possivel de harness mas tem muitos, então no momento estou focando em Claude Code, Codex, Cursor e Windsurf. Outros eu adicionei pra testar mas vou remover por conta de limitação deles não funciona direito. Vou avaliar o OpenCode. :)

-1
2
1

Obrigado, meu caro! Fique à vontade pra abrir discussions lá no repo caso tenha dúvidas ou queira dar algum feedback pra melhoria.

1

Cara para resolver esse tipo de problema, integrei o meu Claude com o Obsidian, e fiz alguns skills pra ele poder interagir.
Quando vejo que há algo que vai precisar salvar para depois por qualquer motivo que seja, utilizo o /nota e o Claude resume e explica tudo numa nota, já com as tags certas do Vault.
Na próxima vez que eu precisar utilizar, uso o /busca para ele ler as notas necessárias para contexto.
Também tem outros skills como /registrar que salva oque foi feito no arquivo de daily, para ter um log mais geral, digamos assim. E também o /tarefa que cria uma nota no diretório exclusivo de tarefas para organizar oque fazer depois.
Só não criei hooks para ele buscar contexto automaticamente ainda.

1

Esse setup é muito bom! Você chegou sozinho num padrão que o Karpathy descreveu naquele gist do "LLM Wiki" (ou talvez o tenha lido) e que muita gente tá reinventando ou tentando aplicar de forma diferente. Markdown + Obsidian + skills é literalmente o protótipo manual da ideia toda. Funciona. E pra uso individual, vai longe.

A MOM nasceu de eu rodar exatamente esse tipo de setup e bater em três paredes:

  1. Ter disciplina e lembrar de sempre chamar uma função como "/nota" quando eu vejo que vai precisar salvar. Eu esquecia. Muito. Inclusive as primeiras versões da MOM tinha a função "wrap-up" pra fazer isso. Fora esquecer de pedir o wrap-up, fechar sessão de forma acidental.. já era. Por isso agora a MOM captura tudo que acontece entre você e o Agente de forma bruta, sanitiza e estrutura os dados pra gerar uma memória. Zero preocupação de perder informação.

  2. Markdown solto envelhece mal. Sem schema, sem ciclo de vida, sem dedup, as notas viram um cemitério. Decisão de 6 meses atrás contradiz a de hoje e você nem sabe. MOM visa tratar cada memória como documento tipado com ciclo de vida e detectar conflitos.

  3. Se for só pra você, funciona por bastante tempo. Obsidian vault é seu. Quando outra pessoa entra, ou você usa três agentes diferentes, cada um tem que ler markdown diferente. A MOM é um servidor MCP — o mesmo memory serve Claude Code, Cursor, Codex, Windsurf, e no Enterprise a ideia será compartilhar memórias entre pessoas e times.

Seria legal ter você testando a MOM pra poder comparar e dar um feedback honesto do que acha de diferença entre o sistema atual que adotou e o que estou montando.

1
1

Pode deixar, está no meu radar. Tenho que avaliar se o OpenCode tem as ferramentas que preciso pra poder coletar e resgatar as memórias.

Sobre compactar, você diz com relação à redução do tamanho dos arquivos? Se sim, não faço nenhum tipo de compactação hoje. Hoje eu coleto todo o turn durante uma sessão em formato RAW (dado bruto) e, à partir dele, eu sanitizo e classifico para gerar uma memória.

Existe uma função que você pode ativar no config.yaml para deletar automaticamente as memórias RAW e você pode definir quanto tempo até deletar (padrão é 30d). Isso já ajuda a não concentrar uma quantidade gigante de dados. Dependendo do quanto você usa Agentes de IA, realmente pode se tornar um problema o volume.

1

Estou começando a ler sobre SDD (Spec Driven Development) e qual seria a diferença de ter esses mesmos arquivos versionados dentro do projeto e um AGENTS.md que aponte para ler esses arquivos no inicio de uma sessão?

1

Pergunta ótima — e bem honesta, porque é exatamente o ponto de partida que eu também tive. AGENTS.md e specs versionadas no repo resolvem uma parte do problema, mas batem num teto rápido. Algumas diferenças concretas:

  1. Rules vs. histórico: AGENTS.md é o que um humano lembrou de escrever. MOM é o que foi efetivamente decidido na conversa — a captura é contínua, sem você precisar lembrar de salvar. Toda resposta que o Agent te dá a interação User<>Agent e o contexto é automaticamente salva.
  2. Markdown corrido vs. memória estruturada: Um SPEC.md vira um blob que você joga no contexto inteiro toda sessão. MOM trata cada decisão / padrão / fato como um documento tipado, com tags, ciclo de vida e escopo. O Agente puxa só o que é relevante via MCP, em vez de carregar 40kb de markdown a cada turn.
  3. Sem citação vs. com citação: SPEC.md lido como contexto pode ser parafraseado e alucinado pelo modelo. Toda resposta da MOM vem com o ID da memória de origem — se não está salvo, ela diz que não está.
  4. Pessoal vs. compartilhado: AGENTS.md no repo funciona pra um usuário. Quando o time cresce, você precisa compartilhar contexto e ai que a estrutura inicial da MOM comba com o que está por vir: classificação, controle de acesso, dedup entre repos, detecção de conflito — tudo coisa que markdown solto não resolve.
  5. Harness-específico vs. agnóstico: AGENTS.md / CLAUDE.md / .clinerules são cada um pra um runtime. MOM é um servidor MCP — o mesmo memory atende Claude Code, Cursor, Codex, Windsurf de uma vez. E se você decide mudar de harness, só continuar usando a MOM que suas memórias estarão lá.

Resumindo: o Karpathy descreveu bem essa categoria no gist do "LLM Wiki" — markdown + AGENTS.md é o protótipo manual da ideia. MOM é tentar montar a infra pra fazer isso escalar sem virar um wiki abandonado. É produtizar uma dor que todo mundo está sentindo.

2
1
1