Yapay zeka bellek sistemlerine başlarken çoğu ekip aynı basit cazibeye kapılır: 'Sadece işe yarayan şeyi kaydet.' Bu masum görünen yaklaşım, kısa sürede bilgi tabanını kullanılamaz bir çekmeceye dönüştürür. Kayıtların yarısı fazla spesifiktir, bir kısmı kopyadır, bazıları güncelliğini yitirmiştir ve hiç kimse hangi bilginin güvenilir olduğunu bilemez. ai-assistant-dot-files projesinde ise bellek sistemi bilinçli olarak yavaş çalışır. Bu sistem, 'Yakala -> Aday -> Denetle -> Onayla -> Dizine Ekle -> Eriş -> Sonlandır' adımlarından oluşan bir terfi yaşam döngüsü kullanır. Bu döngüdeki en kritik kelime 'aday'dır, çünkü hiçbir şey doğrudan belleğe yazılmaz.
Peki bu yaşam döngüsü nasıl işler? Bir teslimattan çıkarılan ders, doğrudan paylaşılan bilgi havuzuna atlamaz. Önce bir Aday Kaydı haline gelir. Bu kayıt; kaynak, tür, kanıt, etiketler ve son kullanma koşulu gibi zorunlu alanlar içerir. Ardından bellek mühendisi şu sorularla denetleme yapar: Tekrar kullanılabilir mi? Zaten mevcut mu? Çok spekülatif mi? Bir Bilgi Öğesi mi olmalı, yoksa kural değişikliği, prompt düzenlemesi veya mimari karar kaydı (ADR) olarak mı ele alınmalı? Ancak bu denetimden sonra bir insan onayı devreye girer. Tasarım, kod incelemesine benzetilmiş: Kalıcı bellek değişiklikleri gelecekteki davranışı etkilediği için izlenebilir bir kayıt gerektirir.
Sistemin en sevdiğim yanlarından biri, açık reddedilme kurallarına sahip olması. Bir anı şu durumlarda terfi ettirilmez: tek seferlikse, zaten kapsanmışsa veya çok spekülatifse. Bu sayede 'bu döngüde hiç aday terfi etmedi' sonucu bir başarısızlık değil, sağlıklı bir durum olarak görülür. Bellek mühendisliği böylece not tutmaktan çok bahçıvanlığa benzer: Amaç her yaprağı korumak değil, toprağı verimli tutmaktır. Yaşam döngüsü ayrıca sonlandırmayı da içerir. Bir Bilgi Öğesi, alttaki kod, ajan veya desen değiştiğinde bayatlayabilir, daha iyisiyle değiştirilebilir veya kullanım analitiği sayesinde işe yaramadığı anlaşılabilir. Bu durumda öğeler silinmez, 'expired/' klasörüne taşınır ve bir not eklenir. Çünkü yanlış bir anı bile ekibin geçmişte neye inandığını gösteren bir kanıttır.
Peki neden şimdi büyük bir erişim sistemi kurulmuyor? Projede LightRAG entegrasyonu için bir runbook var ama uygulaması yok. Bu bir eksiklik değil, YAGNI (İhtiyacın Olmayana Yatırım Yapma) kararı. Mevcut erişim yolu daha küçük: 'search-ki' Bilgi Öğeleri ve ADR'leri arar; 'query-memory' daha geniş bellek kaydında çalışır. Şu anda sadece 4 taşınabilir Bilgi Öğesi olduğu için, henüz ihtiyaç duyulmayan bir alt sistem eklemek gereksiz karmaşıklık yaratırdı. Runbook, gelecekte ihtiyaç doğarsa diye belgelenmiş, niyetli ve geri alınabilir bir şekilde bekliyor. Bu bellek sistemi aynı zamanda daha büyük bir yönetişim modeline oturuyor. docs/AGENT_REFERENCE.md dosyası, 24 ajandan her birini ve çalışmalarını hangi mekanizmanın denetlediğini listeliyor: yapısal sözleşme, alt akış denetçisi, insan onay kapısı veya toplu metrik. Bazı boşluklar açıkça belirtilmiş; örneğin test-driven-developer ajansı hız için tam inceleme zincirini atlıyor. Bellek sistemi de aynı dürüstlükle, hatırlanan her şeyin sonsuza kadar doğru olmadığını kabul ediyor. Bunun yerine şu basit soruları soruyor: Bu nereden geldi? Hangi kanıt destekliyor? Kim onayladı? Hangi koşulda sona erer? Bu küçük sorular, sistemin şeklini tamamen değiştiriyor.
