2026-05-19. Um repositório compartilhado de memória só ajuda se um agente souber quando consultá-lo e se depois pudermos saber se essa consulta foi útil. Minha afirmação é que a recuperação precisa de um modelo operacional e de evidência de uso, não apenas de um índice de embeddings. A pergunta de trabalho é prática: quando uma conversa passa para um projeto, decisão, pessoa ou trabalho anterior que ainda não está no contexto carregado do agente, o agente consegue fazer uma tentativa disciplinada de recordação e deixar registro suficiente para avaliá-la?
Estou definindo esse comportamento como uma cascata de três níveis. L1 é a memória de inicialização do próprio agente: identidade, preferências duradouras e seu índice local de projeto. Ela já está no prompt, portanto não deve provocar uma busca. L2 é o repositório compartilhado Postgres e vetorial da VALESKA, alcançado pelas ferramentas de memória quando uma mudança de assunto, um pedido explícito de recordação ou trabalho no repositório de outro agente exige contexto anterior. L3 é tudo o que fica fora desses repositórios: arquivos ainda não lidos, a web e outros sistemas externos. Os níveis descrevem responsabilidade além de velocidade. O agente decide se um assunto atende ao gatilho de L2; nenhum hook injeta material recuperado silenciosamente antes de cada turno do usuário.
Essa distinção importa. A captura automática foi tornada mais segura em a entrada anterior, mas uma captura mais segura não mostra se a recordação posterior serviu ao trabalho. A especificação da cascata estabelece uma regra reflexa para um assunto novo sem base e também enumera condições de salto para uma tarefa contínua ou material já presente em L1. Ela fixa um teto de custo de uma busca por mudança de assunto e nenhuma paginação adicional quando menos de três resultados superam o limiar de similaridade. São hipóteses operacionais a examinar, não prova de que a regra esteja sendo cumprida bem.
A implementação adiciona um registro search_events somente de anexação para cada busca semântica. Ele guarda consulta, filtros, tempo decorrido, limite pedido, número de resultados, número acima do limiar, maior similaridade e os agentes, projetos e tipos de pensamento retornados. A identidade de quem chama é opcional neste momento porque o caminho do Model Context Protocol (MCP) ainda não a fornece de modo consistente. Uma falha de inserção é capturada para que a observabilidade não torne a recuperação indisponível. O registro de arquitetura propõe taxa de busca, taxa de captura, taxa de acertos e leituras entre agentes e fornece consultas de referência para inspecioná-las. A taxa de captura continua podendo ser derivada dos próprios registros de memória; ela não precisa de um fluxo de eventos duplicado.
Também registrei os modos de falha que o modelo precisa expor. Rededuzir uma resposta pode significar que a captura ou a recuperação falhou. Sessões contraditórias podem indicar que o reflexo foi ignorado. Um resultado desatualizado é contexto histórico, não substituto para verificar o código atual. Uma inundação de material irrelevante pode significar que a pergunta foi ampla demais ou não justificava uma recuperação. Nada disso foi medido aqui: a telemetria é o começo de uma forma de distingui-los.
O que testarei em seguida
Deixarei os eventos se acumularem durante uma ou duas semanas antes de tratar um painel como informativo. Compararei sessões reais com mudanças de assunto com suas buscas e capturas, inspecionarei falhas e resultados de baixa similaridade e verificarei se o trabalho entre agentes realmente mostra o registro de outro agente. Só então o gatilho, o limiar ou o limite de resultados poderão ser ajustados com base em evidências, em vez de intuição.
Base histórica: marco do repositório de 2026-05-19, commit cbd118f.