# Melhores práticas de memória
SUMMARY: Como estruturar memórias para recall eficaz — categorias, keys, tags, prioridades.

Melhores práticas de memória
A forma como você estrutura memórias determina quão úteis elas são. Este guia
cobre padrões para categorizar, taguear e priorizar memórias para que o LLM
possa recuperar a informação certa na hora certa.
Categorias: escolha a mais específica
| Categoria | Usar para | Exemplo |
|-----------|-----------|---------|
|  | Nome, papel, contato do usuário |  |
|  | Gostos, desgostos, estilo de trabalho |  |
|  | Fatos verificáveis |  |
|  | Status de projeto, decisões |  |
|  | Habilidades do usuário |  |
|  | Erros passados a evitar |  |
|  | Contexto relevante para a sessão |  |
|  | Notas diversas |  |
> [!TIP]
> Em caso de dúvida, use  para info verificável e  para todo o
> resto. Não categorize em excesso — melhor ter um  claro do que um
>  confuso.
Keys: identificadores significativos
O campo  é o identificador da memória. Use keys significativas e estáveis:
Keys boas:
- 
- 
- 
- 
Keys ruins:
-  (não significativa)
-  (não descritiva)
-  (data não ajuda o recall)
Convenções de nomenclatura de keys
-  (minúsculas com underscores)
- Prefixe com a categoria: , , 
- Use substantivos descritivos, não verbos
- Mantenha abaixo de 50 caracteres
Tags: para busca e filtragem
Tags permitem filtragem e busca rápidas. Adicione 2-5 tags por memória:
[CODE BLOCK]
Padrões de tags
- Nomes de projeto: , , 
- Tópicos: , , , 
- Status: , , 
- Indicadores de prioridade: , 
> [!NOTE]
> Tags são case-insensitive. Use minúsculas para consistência.
Prioridades: seja realista
| Prioridade | Usar para | % das memórias |
|------------|-----------|-----------------|
|  | Identidade do usuário, info jurídica, decisões irreversíveis | 5% |
|  | Projetos ativos, preferências importantes | 20% |
|  | Maioria dos fatos, notas, contexto | 65% |
|  | Efêmero, bom saber | 10% |
> [!WARNING]
> Não marque tudo como . Se tudo é crítico, nada é. Reserve
>  para coisas que causariam dano real se esquecidas.
Quando armazenar vs não armazenar
Sempre armazene
- Identidade do usuário (nome, email, papel)
- Preferências de longo prazo
- Decisões de projeto e racional
- Erros passados e lições aprendidas
- Compromissos assumidos com o usuário
Não armazene
- Estado transitório (use variáveis em vez disso)
- Histórico literal de conversa (o sistema de chat cuida disso)
- Dados sensíveis (senhas, API keys)
- Fatos facilmente deriváveis (data atual, conteúdo de arquivos)
- Contexto efêmero (use categoria  com prioridade baixa)
Atualizando memórias
POST  com a mesma  +  atualiza a memória existente:
[CODE BLOCK]
> [!TIP]
> Use keys estáveis para poder atualizar sem criar duplicatas. O LLM deve
> refazer POST da mesma key conforme a info muda, não criar novas memórias.
Ciclo de vida da memória
[CODE BLOCK]
- Create: POST /memory com contexto completo
- Active: Recall frequente, atualize conforme necessário
- Stale: Ainda relevante, mas não usado ativamente (prioridade mais baixa?)
- Archive: Defina prioridade como , mantenha para referência histórica
- Delete: DELETE /memory/:id quando não for mais relevante
Limpeza periódica
[CODE BLOCK]
Padrão: herança de memória
Para contexto hierárquico (projeto → subprojeto → tarefa):
[CODE BLOCK]
O LLM pode então buscar  para encontrar todas as memórias
relacionadas.
Padrão: log de decisões
Armazene decisões com racional para que o LLM não as rediscuta:
[CODE BLOCK]
Padrão: evitar erros
Armazene erros com instruções específicas de evitação:
[CODE BLOCK]
Antipadrões a evitar
> [!WARNING]
> - Armazenar logs de conversa — o sistema de chat cuida disso
> - Armazenar arquivos inteiros — use script store ou armazenamento externo
> - Armazenar estado efêmero — use variáveis
> - Armazenar segredos — use variáveis de ambiente
> - Duplicar memórias — use keys estáveis
> - Taguear em excesso — 2-5 tags por memória é o ideal
> - Tudo é crítico — seja realista com prioridades
Próximos passos
- API de Memória
- Agente LLM persistente
- Estratégia de tagueamento de memória