📉 Decay: curva de esquecimento
Decay e compressao programada. Memoria nova: detalhe completo. Memoria velha: one-liner. Memoria muito velha: arquivada.
📐 Curva aplicada
Dia 1: 'Debugamos webhook timeout no endpoint /charge.
Root cause: Lambda payload limit de 6MB.
Fix: chunking em 4MB segments. Deployed staging.'
(80 palavras)
Dia 7: 'Webhook timeout fixado por chunking sob limite Lambda.'
(9 palavras)
Dia 30: 'Webhook chunking fix (Lambda).'
(5 palavras)
Dia 90: [arquivado em archive/2026-Q1/]📊 Economia acumulada
- Sem decay: 1000 entries × 100 palavras = 100k palavras
- Com decay: ~20% detalhado, 40% medio, 40% one-liner → 25k palavras
- Reducao: 75% em storage e tokens de busca
⭐ Salience: frequencia resiste
Salience e o contra-peso do decay. Memoria acessada frequentemente resiste ao envelhecimento.
📐 Formula simples
Decay com salience:
- •
age_effective = age_days / salience_factor - •
salience = 1 + (access_count × 0.2) - •Exemplo: memoria de 30 dias, acessada 5 vezes
- •→ salience = 2.0 → idade efetiva = 15 dias
- •→ ainda no estagio 'summary', nao vira one-liner
💡 Tracking simples
Cada busca em knowledge/ incrementa access_count no frontmatter. 3 linhas em Python.
⬆️ Promotion: 3-strikes → regra
Quando um mesmo padrao aparece 3+ vezes, vira regra prescritiva em CLAUDE.md. A memoria se graduou.
Observacao 1
'Usei idempotency key no webhook da Stripe.' → knowledge/patterns/
Observacao 2
'Idempotency key no webhook de retry.' → knowledge/patterns/
Observacao 3
'Idempotency key no webhook de refund.' → script detecta cluster.
PROMOVIDA
Regra em CLAUDE.md: 'Sempre usar idempotency key em payment webhook.' Observacoes originais arquivadas.
💡 Sempre com aprovacao
Script cria promotions/pending.md. Voce revisa e aprova. CLAUDE.md ruim e pior que ausente.
🎚️ Progressive disclosure
Principio arquitetural: carrega o minimo essencial sempre, busca o resto por demanda. 10x economia de tokens.
📐 Backpack vs library card
BACKPACK (carrega tudo sempre): Session start: 25k tokens de memoria Custo por sessao: alto, mesmo sem precisar LIBRARY CARD (carrega indice, busca on-demand): Session start: identidade + contexto = 500 tokens Por pergunta: busca top 3 = 1500 tokens Total medio: 2k tokens Custo: 10x menor, mesma utilidade.
📊 Orçamento de camadas
- Sempre-ativo: identidade (200) + contexto (400) = 600 tokens
- Pesquisado: long-term top 3 por turno = 1500 tokens
- Working: variavel, 1-2k no meio de sessao
- Episodica: 0 por default, so quando voce pede
📐 Orçamento de tokens por camada
Cap rigido evita inflacao. Quando estoura, voce REFATORA a camada. Disciplina e parte do design.
✓ Respeitar os caps
- ✓Identidade: ≤200 tokens
- ✓Contexto critico: ≤400 tokens
- ✓Working por sessao: ≤2k tokens
- ✓Long-term injetado por turno: ≤1.5k tokens
✗ Sinais de inflacao
- ✗Identidade com 'projeto atual' (vai em contexto)
- ✗Contexto com historico (vai em long-term)
- ✗Working sem lifecycle (entope)
- ✗Long-term carregado em bloco (vira backpack)
🎓 Sintese: a pilha completa
Os 7 niveis resumidos. Voce ja tem o modelo mental que vai usar pelo resto do curso.
📐 A pilha inteira
┌─ ALWAYS ON (cheap, tiny) ────────────────┐ │ IDENTIDADE ~200 tokens persistente │ │ CTX CRITICO ~400 tokens sobrevive │ │ compact │ ├─ ON DEMAND ──────────────────────────────┤ │ WORKING MEM ~1-2k sessao │ ├─ SEARCHED ───────────────────────────────┤ │ LONG-TERM ilimitado nunca bulk │ │ EPISODICA arquivo raramente │ ├─ BACKGROUND ─────────────────────────────┤ │ DECAY comprime automaticamente │ │ PROMOTION padroes viram regras │ │ PROGRESSIVE min sempre, max on-demand │ └──────────────────────────────────────────┘
📝 Resumo do Modulo
Proximo:
Trilha 3 — Anatomia dos 18 hooks