Diagrama ilustrativo · agentes escrevem no cérebro (rose); ele processa e devolve briefings (ciano) no início de cada sessão.
🧠 O problema: agentes que esquecem
Você roda vários agentes — um para desenvolvimento, um autônomo para tarefas, automações para fluxos. Cada um mantém o próprio contexto e esquece tudo entre sessões. Quando um descobre algo importante, os outros nunca ficam sabendo. Esse é o problema que justifica um cérebro compartilhado.
⚠️ Por que key-value não basta
As soluções existentes ou são de máquina única, ou exigem serviço pago na nuvem, ou tratam memória como um saco de chave-valor plano — sem entender que um fato e um evento são coisas fundamentalmente diferentes, com ciclos de vida diferentes. Memória de verdade precisa de tipos.
✓ Com cérebro compartilhado
- ✓O que um agente aprende fica disponível para todos.
- ✓Funciona entre máquinas, ferramentas e frameworks.
- ✓A sessão começa sabendo o que mudou desde a última vez.
✗ Sem ele
- ✗Cada agente vive na própria bolha de contexto.
- ✗Amnésia total a cada nova sessão.
- ✗Descobertas valiosas não se propagam.
Contexto separado.
Esquece entre sessões.
Descobertas presas.
Cérebro compartilhado.
🧩 Os 4 tipos de memória
Aqui está a ideia central: um fato e um evento são coisas diferentes. O sistema entende quatro tipos, cada um com seu ciclo de vida e regra de mutação. Essa taxonomia é o que separa um sistema de memória de verdade de um depósito de strings.
| Tipo | Comportamento | Exemplo |
|---|---|---|
| event | Append-only, imutável. Você não atualiza histórico, registra. | "Workflow falhou às 3h" |
| fact | Upsert por key. Novo fato supersede o antigo. | "API status: healthy" |
| status | Update no lugar por subject. O último vence. | "migração: 70%" |
| decision | Append-only com raciocínio. O porquê importa. | "Postgres em vez de MySQL porque..." |
📊 Não é taxonomia por esporte
A tipagem diz ao sistema como cada memória deve se comportar quando muda: um fato é superseded, um status é sobrescrito, um evento é permanente, uma decisão é um registro de raciocínio. Dados diferentes, regras diferentes. Sem isso, tudo vira o mesmo blob e você perde a capacidade de versionar e de confiar no que está ativo.
Imutável.
Upsert por key.
Último vence.
Guarda o porquê.
🔄 O ciclo de vida da memória
Cada memória passa por uma esteira. É isso que mantém o cérebro útil em vez de virar um depósito que só cresce. Quatro mecanismos trabalham juntos: deduplicação, cadeia de supersedes, decaimento de confiança e consolidação por LLM.
Deduplicação
Conteúdo é hasheado em SHA-256 na gravação. Duplicatas exatas são pegas; a consolidação ainda captura quase-duplicatas a 92% de similaridade semântica.
Cadeia de supersedes
Gravou um fato com a mesma key? O antigo é marcado inativo e o novo aponta de volta. Histórico de versões de graça, sem trabalho manual.
Decaimento de confiança
Fatos e status perdem ~2%/dia se ninguém acessa. A busca ranqueia por similaridade × confiança. Conhecimento velho afunda sozinho; acessar reseta o relógio. Eventos e decisões não decaem — são histórico.
Consolidação por LLM (a cada 6h)
Um processo de fundo analisa as memórias novas: funde duplicatas, sinaliza contradições, descobre conexões e extrai insights cruzados. É um bibliotecário que organiza o conhecimento em vez de deixá-lo empilhar.
💡 O cérebro melhora enquanto você dorme
A consolidação periódica é o diferencial. Enquanto sistemas comuns só acumulam, este reorganiza: a primeira passada após um upgrade chegou a limpar centenas de memórias-lixo automaticamente. Decay + consolidação = memória que envelhece como a humana, esquecendo o irrelevante.
🛡️ Segurança e isolamento
Memória compartilhada por agentes que rodam sem supervisão só é viável com um porteiro bem desenhado. A API é o gatekeeper: nenhum agente toca o banco direto. Eles podem guardar e buscar — e só.
✓ O que um agente PODE
- ✓Gravar e buscar memórias por endpoints validados.
- ✓Ler briefings, stats e entidades.
✗ O que NÃO pode
- ✗Apagar memórias ou dropar tabelas.
- ✗Burlar a limpeza de credenciais.
- ✗Acessar o banco direto ou alterar memória alheia.
🔐 Credential scrubbing
Todo conteúdo é limpo antes de armazenar: API keys, JWTs, chaves SSH, senhas e segredos em base64 são redigidos automaticamente. Os agentes compartilham contexto livremente sem vazar credenciais para a memória de longo prazo.
⚠️ O pior caso é bom dado, não destruição
É por design: se um agente autônomo alucina ou sai do script, o pior que ele faz é gravar dado ruim — não consegue destruir dado bom. Soma-se a auth timing-safe e rate limiting (10 falhas/min = lockout). O básico bem feito.
API valida tudo.
Sem credenciais.
Não toca o banco.
Timing-safe + limite.
📊 Briefings de sessão
É aqui que a coordenação entre agentes realmente acontece — de forma passiva. Toda sessão começa com uma pergunta: "o que houve desde a última vez que estive aqui?". O endpoint de briefing devolve as novidades de todos os outros agentes, excluindo as suas próprias.
Recriação ilustrativa de uma chamada de briefing (não é um screenshot real):
Na prática: o agente de dev abre uma sessão na sexta de manhã e já sabe que um workflow falhou na quinta à noite e que outro agente descobriu algo sobre o ranking de um cliente — sem checar logs, sem lembrar de olhar. O sistema traz à tona.
✓ Boas práticas de briefing
- ✓Chamar no início de cada sessão.
- ✓Excluir as próprias entradas (já são conhecidas).
- ✓Ordenar por importância e depois recência.
✗ Antipadrões
- ✗Confiar na memória humana para "ir olhar os logs".
- ✗Trazer tudo sem filtro de importância — vira ruído.
- ✗Incluir as próprias entradas e poluir o briefing.
💡 Dica prática
Trate o briefing como o "bom dia" obrigatório do agente. Coloque a chamada no começo do seu fluxo de abertura de sessão — assim a coordenação entre agentes vira hábito do sistema, não algo que depende de você lembrar. É o par natural do /sessionend: um abre, o outro fecha.
Timestamp.
Exclui o próprio.
Por tipo.
Coordenação sem esforço.
🔥 O ritual /sessionend
O /sessionend é uma skill que fecha o loop de inteligência composta. Ao fim de cada sessão, ela transforma o que aconteceu em memória institucional. O ponto não é só resumir — é avaliar com honestidade e guardar de forma estruturada.
Gather — reunir os artefatos
Roda git log, diff, status e revisa o histórico da conversa: o que foi pedido, quais ferramentas, o que deu certo, o que precisou de retry.
Reflect — refletir com honestidade
O que foi bem, o que foi mal e como poderia ter sido melhor. "Correu tudo bem" não é reflexão válida — se algo foi subótimo, nomeie. É a regra que mais agrega valor.
Store — guardar no cérebro
Salva um resumo estruturado (o que foi feito · o que foi bem · o que foi mal · como melhorar · relevante para outros agentes) sob um tópico datado.
Update — atualizar a memória local
Só guarda o que é genuinamente novo: preferências, fatos de projeto, informações sobre o usuário. Atualiza o índice. Nada de re-salvar o que já foi capturado.
♾️ Por que isso compõe
O fim de sessão alimenta a consolidação, que alimenta o briefing da próxima sessão. Cada sessão deixa todas as futuras mais espertas — não só para aquele agente, mas para todos. É o mesmo loop de auto-melhoria de 6.1 (Workflow Spotter) e 6.2 (Taproot), agora no nível da memória do sistema.
"O que aconteceu desde a última vez que estive aqui? Traga o briefing de todos os outros agentes desde ontem, ordenado por importância. Exclua minhas próprias entradas."
/sessionend # (ou, sem a skill instalada:) "Encerre a sessão: reúna git log/diff, reflita com honestidade (o que foi bem, o que foi mal — 'tudo certo' NÃO vale), guarde um resumo estruturado e atualize a memória local só com o novo."
📤 Exemplo de saída
Recriação ilustrativa do resumo final que o /sessionend imprime ao usuário (não é um screenshot real):
🏋️ Exercícios práticos
Classifique 5 memórias
Pegue 5 informações do seu trabalho recente e classifique cada uma como event, fact, status ou decision. Justifique por que o tipo importa em cada caso.
Desenhe seu briefing
Liste seus agentes/ferramentas e escreva a pergunta de briefing que cada um faria ao iniciar. Defina o critério de ordenação (importância × recência).
Crie um SKILL.md de /sessionend rodável
Escreva uma skill de encerramento adaptável a qualquer backend de memória. Esqueleto:
Salve em ~/.claude/skills/sessionend/SKILL.md e teste digitando "/sessionend" ao fim de um trabalho. Funciona com qualquer backend de memória (ou só localmente).
📌 Resumo do módulo
Você chegou ao fim
Esta é a última aula do curso. Da anatomia do SKILL.md (T1) à memória multi-agente, você percorreu o caminho completo de Claude Skills na Prática.