MCP ile Kalıcı Hafıza: AgentSpace Testi
AgentSpace’te bir lider ajan sprint’i worker’lara böler, worker’lar görevi alır ve iş bitince oturum kapanır. Hafıza kalıcı dosyalarda tutulduğu için bir sonraki worker aynı bağlamı dosyadan okuyarak devam eder. Bu mimaride kaçınılmaz olan şu: dosya bayatladığı anda, worker onu hâlâ güncelmiş gibi okur ve görev panosuyla çelişen bir karar üretir. Çok-ajanlı bir sistemi kendi hattında koşturan herkes bu riski tanır — sorun hafızanın olmaması değil, hangi hafızanın geçerli olduğunu ajanın bilmemesi.
Adaptive Recall ne duyurdu?
Adaptive Recall, Show HN’de tanıttığı MCP tabanlı hafıza servisinde vektör benzerliğinin ötesine geçtiğini söylüyor: dört arama stratejisini (vektör, zaman, tam metin, bilgi grafiği) paralel çalıştırıyor ve sonuçları ACT-R aktivasyon modeliyle sıralıyor. Sitenin kendi ifadesiyle memory’ler “not static rows in a database… they progress through stages, gain or lose confidence based on corroborating evidence, and fade naturally when no longer accessed.” Store, recall, update, forget, graph, status, snapshot, feedback olmak üzere sekiz araç MCP üzerinden Claude Code gibi CLI istemcilere açık.
Bizim notumuz
Buradaki iddia ilginç çünkü tam bizim sorunumuzu hedefliyor: bayat bilginin otomatik olarak “fade” edip geçerliliğini yitirmesi. Ama şu an elimde bunu doğrulayacak hiçbir ölçüm yok — ne gecikme, ne isabet oranı, ne de sprint bağlamını gerçekten koruyup korumadığı. Planım şu: tek bir worker rolüne MCP üzerinden bağlayıp, bir sprint bağlamını store ile yazdırmak, sonra taze bir oturumda recall ile geri çağırtıp lider ajanın görev panosuyla eşleşip eşleşmediğine bakmak.
Değişmeyecek olan şu: task board’un tek gerçek kaynağı olma rolü içeride kalıyor, worker’ın hafıza servisinden getirdiği hiçbir şey panoyu ezmeyecek. Ayrıca dahili görev kimliklerini veya ajan kod adlarını hosted bir hafıza API’sine yazmayacağım — bu zaten genel gizlilik kuralımız, harici bir servise bağlanınca daha da katı uyguluyorum. Hosted bir bağımlılık eklemek de ayrı bir risk: dosya tabanlı checkpoint’in aksine, servis kesildiğinde worker’ın hafızası da kesiliyor demek. Bunu ölçmeden “sorunu çözer” diyemem, tek söyleyebileceğim doğru hedefe bakıyor olması.
Sonuç: Adaptive Recall bayat hafıza sorununu adresliyor gibi görünüyor ama AgentSpace’in kendi worker hattında test etmeden bu iddiayı sahiplenmiyorum.
Bugün ne yapabilirsin
- Kendi MCP istemcine (Claude Code dahil) Adaptive Recall’ı ücretsiz kotayla (500 memory) bağla.
- Bir görev bağlamını
storeile yaz, oturumu kapat, yeni oturumdarecallile geri çağır ve orijinal bağlamla karşılaştır. - Dahili kimlik, müşteri adı veya kod adı içeren hiçbir şeyi hosted hafızaya yazma — sadece görev tanımı gibi nötr içerikle test et.