Stash - Yapay zeka ajanları için kalıcı bellek katmanı

• Oturum değişse bile konuşma ve görev bağlamını sürdüren bir kalıcı bellek katmanı; ham gözlemleri episode olarak kaydedip bunları yapılandırılmış bilgiye dönüştürerek biriktirir
• Modelden bağımsız mimari kullanır; Claude, GPT, yerel LLM'ler ve özel ajanların aynı bellek katmanına bağlanmasını sağlar, altyapı olarak PostgreSQL ve pgvector üzerinde çalışır
• RAG'den farklı bir rol üstlenir; belge aramayla sınırlı kalmaz, konuşmalardan yeni olgular, ilişkiler, hedefler, başarısızlıklar ve hipotezler biriktirir; RAG ile birlikte de kullanılabilir
• Namespace ve hiyerarşik yollarla kullanıcı, proje ve ajanın öz-bilgisi ayrılır; consolidation pipeline ile facts, relationships, causal links, patterns, contradictions sürekli sentezlenir
• MCP yerel entegrasyonu, /self tabanlı öz-model ve yinelenen araştırma döngülerini içererek belleği olmayan oturumluk ajanları uzun vadeli sürekliliğe sahip iş aktörlerine dönüştürmeyi amaçlar

---

Stash genel bakış

• AI ajanları ile dış dünya arasında yer alan bir kalıcı bellek katmanıdır; oturum değişse bile önceki bağlamın sürmesini sağlar
• Ham gözlemleri episodes olarak kaydeder ve bunları facts, relationships, patterns, goals, failures, hypotheses gibi yapılandırılmış bilgi biçiminde biriktirir
• Modelin kendisinin yerini almaz; sürekliliği güçlendirir ve Claude, GPT, yerel modeller gibi herhangi bir ajana bağlanabilecek şekilde tasarlanmıştır
• Depolama temeli olarak PostgreSQL + pgvector kullanır
• GitHub

Belleğin yapılandırılma biçimi

• namespace ile kullanıcı, proje ve ajanın öz-bilgisi gibi bellekler ayrılır
• Her namespace hiyerarşik yollardan oluşur; /projects okunduğunda /projects/stash, /projects/cartona gibi alt yollar da birlikte dahil edilir
• Yazma işlemi yalnızca tek bir kesin namespace'e kaydedilir; böylece bellek kirlenmesi önlenir
• Kullanıcıyla ilgili bellek, proje belleği ve /self altındaki öz-bilgi birbirine karışmadan korunur
• Örnek yapı olarak /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences verilir

RAG'den farkı

• RAG, belgelerden ilgili içeriği getiren bir erişim katmanına daha yakındır; konuşmanın kendisini hatırlamaz ve ondan öğrenmez
• RAG yalnızca belgelerde zaten bulunan içerikle çalışabilir; konuşmadan yeni bilgi üretemez
• Hedef takibi, niyet anlama, zaman içindeki çelişkileri tespit etme, neden-sonuç ilişkisi üzerine akıl yürütme RAG kapsamı dışında konumlandırılır
• Stash, konuşmalardan, kararlardan, başarılardan ve başarısızlıklardan otomatik öğrenir, zamanla bir bilgi grafiği oluşturur
• Belge arama ile deneyim belleği farklı problemleri çözdüğü için RAG ve Stash birlikte kullanılabilir

Mevcut AI belleğinden farkı

• Claude.ai ve ChatGPT'de de bellek vardır, ancak bu işlevler kendi platformlarına ve kendi modellerine bağlıdır
• Stash modelden bağımsız çalışır; yerel ve özel modellere de bağlanabilir
• Veri sahipliğini kullanıcı tarafında tutar ve açık kaynak olarak sunulur
• Arka plan consolidation, goals ve intent takibi, failures öğrenimi, causal reasoning, agent self-model gibi bileşenleri içerir
• Karşılaştırma tablosunda ChatGPT Memory ve Claude.ai Memory bir “not defteri”, Stash ise bir “zihin” olarak ayrıştırılır

Çözmeyi hedeflediği sorun

• Güncel AI modelleri akıl yürütmede iyi olsa da oturumlar arası hafızaları yoktur; bu yüzden kullanıcı her seferinde kendisini ve proje bağlamını yeniden anlatmak zorunda kalır
• Her seferinde uzun konuşma geçmişini prompt'a koymak yavaş ve pahalıdır; ayrıca context window sınırı devam eder
• Başarısız denemelerin sonraki oturumlarda tekrarlanmasını önleyecek bir ders aktarma mekanizması eksiktir
• Bellek özellikleri yalnızca bazı platformların özel işlevi olarak sunulduğu için özel ajanlar ve yerel LLM'ler bağlamsız şekilde sıfırdan başlamak zorunda kalır

Entegrasyon pipeline'ı

• Arka plan süreçleri deneyimleri sürekli sentezleyerek ham belleği yapılandırılmış bilgiye dönüştürür
• Episodes aşamasında gözlemler append-only biçimde kaydedilir
• Facts aşamasında episode kümeleri LLM ile sentezlenir
• Relationships aşamasında fact'ler arasındaki varlık ilişkileri çıkarılır
• Causal Links aşamasında fact'ler arasındaki neden-sonuç çiftleri bağlanır
• Patterns aşamasında daha yüksek seviyeli soyut örüntüler çıkarılır
• Contradictions aşamasında öz-düzeltme ve confidence decay uygulanır
• Goal Inference, etkin hedeflerle ilgili olguları otomatik olarak izler; ilerlemeyi ve çatışmaları görünür kılar
• Failure Patterns, yinelenen hataları tespit edip bunları yeni fact'ler olarak çıkarır; böylece aynı başarısızlıkların tekrarı azaltılır
• Hypothesis Scan, yeni kanıtların açık hipotezleri manuel müdahale olmadan doğrulamasını veya çürütmesini sağlar

MCP entegrasyonu

• MCP yerel olarak çalışır; Claude Desktop, Cursor, OpenCode, özel ajanlar, yerel LLM'ler ve diğer MCP istemcilerine bağlanabilir
• SDK olmadan bağlanabilir ve vendor lock-in olmadan her yerde aynı bellek katmanının kullanılmasını sağlar
• Toplam 28 araç sunar; remember, recall, forget, init'ten causal links, contradictions ve hypotheses'e kadar uzanır
• ./stash mcp execute --with-consolidation ile stdio MCP sunucusu ve consolidation birlikte başlatılabilir
• ./stash mcp serve --port 8080 --with-consolidation ile uzak ajanlar için SSE sunucusu açılabilir

Ajan öz-modeli

• init çağrısında /self namespace iskeleti oluşturularak öz-modelin kurulumu başlatılır
• /self/capabilities altında ajanın iyi yaptığı işler hatırlanır ve görev planlamasında kullanılır
• /self/limits altında hata kayıtları ve zayıflıklar tutulur; böylece aynı hataların tekrarı engellenmeye çalışılır
• /self/preferences altında en iyi çalışan işletim biçimleri öğrenilir ve uzun vadede çalışma tarzı şekillenir

Otonom öğrenme döngüsü

• 5 dakikalık bir research loop çalıştırıldığında geçmiş bellekten mevcut bağlam çekilir, ajan kendi başına konu seçip araştırır, yeni bağlantılar kurar, yeniden birleştirir ve sonra durur
• Orient aşamasında geçmiş bağlam, etkin hedefler, açık hipotezler ve geçmiş başarısızlıklar çağrılır
• Research aşamasında ajan kendi seçtiği konu üzerinde web araması yapar
• Think aşamasında halihazırda bilinenler içindeki gerilimler, boşluklar ve çelişkiler açığa çıkarılır
• Invent aşamasında hipotez, örüntü ve keşif gibi yeni çıktılar üretilir
• Consolidate aşamasında pipeline çalıştırılarak ham episode'lar yapılandırılmış bilgiye dönüştürülür
• Reflect + Sleep aşamasında oturum özeti bırakılır, bir sonraki çalıştırma için bağlam ayarlanır ve süreç durur
• Döngü prompt'unu görüntüle

Model ve altyapı uyumluluğu

• Hem embedding hem reasoning için OpenAI uyumlu API kullanan tek bir provider yapılandırması varsayılır
• Bulut, yerel ve self-hosted kurulumları desteklediğini ve vendor lock-in olmadığını belirtir
• OpenRouter'ın yerelde bağlı kullanıldığı, yüzlerce modele tek bir API anahtarıyla erişim sağladığı belirtilir
• Ollama ile de doğrudan çalışır; Qwen, Llama, Mistral gibi yerel modellerle çevrimdışı bellek kurulumu mümkündür
• vLLM, LM Studio, llama.cpp server, Together AI, Groq gibi OpenAI API biçimini kullanan arka uçlar da desteklenir
• Varsayılan embedding modeli openai/text-embedding-3-small'dır ve bu kombinasyonda STASH_VECTOR_DIM=1536 kullanılır
• STASH_VECTOR_DIM yalnızca ilk çalıştırmadan önce ayarlanabilir; başlatmadan sonra değiştirilirse tüm veritabanının sıfırlanması gerekir

Dağıtım ve kullanım bilgisi

• Docker Compose ile Postgres, pgvector ve Stash'ı birlikte ayağa kaldıran bir yapı sunulur
• Çalıştırma süreci; depoyu clone etmek, .env.example dosyasını .env olarak kopyalamak, ardından API anahtarı ile modeli ayarlayıp docker compose up çalıştırmak şeklinde 3 adımda anlatılır
• İlk çalıştırmadan sonra postgres + pgvector hazırlığı, migration'ların uygulanması, MCP sunucusunun beklemesi ve arka planda consolidation'ın çalışması beklenir
• Proje Apache 2.0 lisansı ile yayımlanır
• GitHub Repository
• alash3al.com

[GN⁺]

Hacker News yorumları

• Sonunda Claude.ai bellek sistemi gibi bir şeyi taşınabilir hale getirmişler sanıp tıkladım, ama hiç öyle değilmiş
  Buradaki şey sadece store/remember yaklaşımı; bence daha iyi olan, arka plandaki modelin sohbet geçmişini özetleyip bellek oluşturması
  O tarafta modelin belleği doğrudan yazması gerekmiyor, bu yüzden çok daha iyi çalışıyordu; bu nedenle bunu Claude.ai ile aynı seviyede tanıtmak biraz misleading görünüyor
  Ben de LibreChat gibi bir şeye geçmek için aynı tarz bir bellek sistemini sürekli arıyorum ama henüz bulamadım; şu an Claude.ai’de kalmamın neredeyse tek nedeni bu özellik
  Bu arada o sistem sadece Claude.ai’de var, Claude Code’da yok

  • Yakın tarihli bir Claude Code leak’ine göre autoDream diye bir şey varmış ve burada background memory consolidation engine olarak açıklanıyor: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
  • Bu yaklaşımı gerçekten denemek isterim
    Benim deneyimim tam tersi; https://github.com/flippyhead/ai-brain projesini esasen kendim için yaptım, birkaç arkadaşım da kullanıyor
    Şimdiye kadar CLAUDE.md üzerinden yapay zekaya ilgili anıları buldurup, ne zaman ve nasıl saklayacağını düşündürtmek oldukça iyi işledi
    Bu yöntem önceliğe göre yapı kurabiliyor ve gelecek için notlar bırakabiliyor; bu yüzden sadece her şeyi özetlemekten epey farklı hissettiriyor
  • Ben otomatik recall’ın ajana görünmeden çalışmasını tercih ederim
    Bellek oluşturma için tool call da oldukça iyi iş görüyor; bağlam sıkıştırması sırasında otomatik olarak bellek üretmek de bence fena değil
    Ama otomatik üretim olacaksa eşzamansız consolidation gerekir; buna dreaming demek biraz abartı gibi geliyor
    Benim implementasyonum Elroy.bot’ta; farklı yaklaşımları da burada derledim: https://tombedor.dev/approaches-to-agent-memory/
  • Bunun nasıl benchmark edildiğini merak ediyorum
    Arka planda bellek çıkarınca, bunu prefix cache ile uyumlu hale getirmek zor oluyor
    Basit bir iki aşamalı LOG.md (işlerin ve çıkarılan derslerin ayrıntılı günlüğü) + MEMORY.md (günlük budandığında terfi ettirilen maddelerin kaydı) + tur sonunda çalışan bir stop hook bile oldukça ileri götürebilir
  • Bu fikir epey ilginç
    Kullanıcıyla konuşan ajanın arkasında yardımcı ekipler varmış da, konuşmayı dinleyip önemli gerçekleri not ediyor ya da veritabanında ilgili bilgileri arayıp bu X belleği alakalı görünüyor diye araya giriyorlarmış gibi hissettiriyor
    Token’lar bedava olsa kolay görünürdü, ama bunu verimli hale getirmek oldukça ilginç bir problem

• Nasıl implement edildiğini neredeyse hiç açıklamadan bir şeyler vaat eden projeler bana hep büyük bir red flag gibi gelir
  Biraz daha kazıyınca aslında pg_vector üzerine mcp ve recall/remember adlı iki fonksiyon eklenmiş bir yapı çıkıyor
  Sonuçta bu daha çok RAG’e yakın; veri yapısının önemli olduğu söylenebilir ama şimdiye kadar çıkan bu tür bellek sistemlerinin neredeyse hepsi benzer şekilde çalıştı
  Henüz temel bir vector DB search’ten daha iyi arama yaptığını kanıtlayan bir örnek görmedim

  • Site şık, üstünde memory yazıyor ve LLM’ler berbat ama bu ürün sihirli şekilde çözüyor gibi gösteriliyor
    Eğer gerçekten bunu yapıyorsa, sonuçta sadece vectordb’nin iyi paketlenmiş bir hali sayılır

• Bununla ilgili zaten bir inceleme var: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
  Diğer pek çok LLM memory system de burada toplanmış: https://zby.github.io/commonplace/agent-memory-systems/
  Ve bu tür sistemlerden ne beklendiğini de burada yazmışlar: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

• Bu agent memory systems hem aşırı tasarlanmış gibi geliyor hem de aynı anda yetersiz tasarlanmış; ayrıca biraz çıkmaz sokak gibi görünüyor
  Güncel modellerin ihtiyaçlarından hızla kopmayacak ve çürümeyecek bir gerçeklik pek hayal edemiyorum
  Örneğin bir kez ödeme özelliği yapıldı diye, don't use stripe gibi bir bellek yüzünden sonraki birçok oturumun gereksiz yere ödeme tarafına kayması mümkün

  • Daha kötüsü, yazarın bunu bizzat kullanmış olduğuna dair iz çok az
    Tamamen unproven memory layer gibi; gerçek kullanım görüntüsü olmadan, şık bir pazarlama sitesine abartılı iddialar konmuş hissi veriyor
  • Ben bunu bir bilgi problemi olarak görüyorum ve çoğu şeyi saklamamaya odaklanan küçük bir araç yaptım: https://github.com/skorokithakis/gnosis
    Varsayım basit: LLM zaten bildiğini bilmeye devam edecek, dolayısıyla LLM’in söylediklerini saklamıyorum; kodla ilgili şeyler de kodda ve yorumlarda kalmalı
    Ama bunların dışında olup da yine de asla yakalanmayan şeyler var
    Bir şey geliştirirken, fiilen yaptıklarınızdan çok yapmamaya karar verdikleriniz önemli olabiliyor; bu araç oturum sonunda elenen alternatifleri ve nedenlerini yakalayıp system knowledge olarak saklıyor
    Sonuçta sadece kodda grep yaparak bulunamayacak, ekip arkadaşlarının kafasında kalan bilgiyi korumak istiyorum; şu ana kadar epey iyi çalışıyor ama daha erken
  • Benim kullandığım bespoke memory system bu sorunu, tüm anıları bağlama göre ayrı arama alanları haline getirerek çözüyor
    don't use stripe gibi bir anı, ancak modele payment processing ile ilgili bir görev verildiğinde bağlama giriyor

• Uzun süredir böyle bir şey arıyordum ve hesabın LLM patlamasından önce de yazılım yayımladığını görmek hoş
  Yine de keşke projelere LLM kullanım kaydı gibi bir şey eklense
  LLM ile mi üretildi, üretildiyse ne kadar, hangi aşamalarda kullanıldı, çıktı ne kadar dikkatle incelendi, kalite açısından tek başına yapmaya göre en azından aynı mı ya da daha iyi mi görüldü; bunları bilmek güzel olurdu
  Belirli bir kişiden şüphe etmek için değil, tüm projelerde ortak bir bilgi olarak görmek isterdim; ben de bunu yapmayı düşünüyorum

  • Açıkçası bu biraz entitled geliyor
    Kimse seni bu projeyi kullanmaya zorlamıyor; kodu açıp okuyabilir, inceleyebilir ve kullanıp kullanmayacağına kendin karar verebilirsin
  • Soru kendi içinde makul, ama bunun cevabını sadece ilgili kişinin öz beyanına bırakamayız diye düşünüyorum
    Tasarımı ve testi neredeyse hiç yapmadığını, kod kalitesinin de düşük olduğunu dürüstçe kabul edecek çok kişi sanmıyorum
    Hatta bu soruya yanıt vermeye çalışan üçüncü taraf bir sistem gerekebilir; tabii o da LLM tabanlı olursa epey öznel olabilir
  • LLM ile yazılım üretmenin gerçekten çok farklı yolları var
    Ben bu aralar çoğu projeyi bir dizi Markdown dosyası etrafında yürütüyorum; önce yapay zekayla araştırma yapıyor, plan çıkarıyor ve implementasyon ilerleyişini takip ediyorum
    Geliştirmeyi plana göre aşamalı yapıyor ve her aşamada incelemeye devam ediyorum
    İş akışımı belgele derseniz, o dosyalar zaten bunun kendisi
    Kodun %99’u üretilmiş oluyor ama bunu benim tatmin olduğum şekilde ürettirmeye dikkat ediyorum; sonuç da çoğu zaman tek başıma yapacağımdan daha iyi geliyor
  • Bunun neden önemli olduğunu pek anlamıyorum
    İyi yazılım da kötü yazılım da hem LLM’siz hem LLM’le üretilebilir
    Bir marangozdan çekiç mi kullandığını yoksa nail gun mı kullandığını, çatıyla güvertede hangisini tercih ettiğini sormayız
    Güvene dayalı bir temel yoksa, sonunda ya kaliteyi kendin doğrulaman gerekir ya da baştan kendin yaparsın; onun dışı biraz umutla karışık beklenti gibi

• Hâlâ işe yarar bir memory bulamadım
  Bir uçta agents.md gibi sadece üst düzey özet bırakan şeyler var; bunlar bu öğeyi değiştirirsen şu öğeyi draft olarak işaretlemelisin gibi somut detaylarda pek işe yaramıyor
  Öbür uçta ise aşırı ayrıntılı yaklaşımlar var; detay o kadar fazla oluyor ki ya göz ardı ediliyor ya da bir özellik alanının ayrıntısı başka alanlardaki değişiklikleri kirletiyor
  Sonuç olarak şimdiye kadar en iyi çalışan yöntem, belleksiz gidip sadece ilgili oturum/prompt için önemli bağlamı elle seçmek oldu

  • Bellekle çok ilgileniyorum ama en azından kodlama araçları açısından çok faydalı bulmuyorum
    Bir deponun ne yaptığı ve ne yapması gerektiği konusunda gerçek source of truth sonuçta repo itself
    Anlattığın şey daha çok kod inceleme yönergesi gibi; böyle şeyleri zaten değişiklik anında açıkça bağlama koyabilirsin
    Bellek sistemi buna göre fazla karmaşık ve doğruluğu da daha düşük
  • Bu tür sistemler için bir istek listesi burada: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
  • Ben de benzer hissediyorum
    Acaba bir gün bu modeller gerçekten continual learning kazanacak mı diye merak ediyorum
    Zaten yeterince zekiler ama gerçek hafızaları olmadığından kullanması hantal geliyor
  • Claude’un oluşturduğu anılar neredeyse tamamen remember-to-not-forget türündeydi; sonunda özelliği kapattım

• Bende birkaç basit şey oldukça iyi çalışıyor; araç olarak Codex kullanıyorum

  1. Her zaman güncel, ayrıntılı bir functional specification
  2. Birden fazla proje halinde yapılandırılmış bir kod tabanı
  3. İyi adlandırılmış ve iyi belgelenmiş kod. Sınıf, değişken ve fonksiyon adları ne kadar uzun ya da komik görünürse görünsün amacı net olmalı; bu kuralları da Agent.md içindeki kodlama rehberine koyuyorum
     Benim functional spec’im ajan için Project.md işlevi görüyor
     Ayrıca her agentic code review öncesinde proje dizin ağacını çıkarıp kod tabanıyla birlikte tek bir dosyada birleştiriyor, dosya adına da timestamp ekliyorum
     Bu beklenmedik derecede önemli; LLM’in eski sürümlere referans verme ihtimalini azaltıyor ve git göndermeden hızlı diff bakmak için de işe yarıyor
     Şimdiye kadar büyük ve karmaşık kod tabanlarında bile bu basit iş akışı oldukça iyi çalıştı
     Token verimliliği kötü ama işe yarıyor
     Her seferinde tüm kod tabanını birleştirmek gerekmiyor; bitmiş, test edilmiş ya da mevcut işle ilgisiz projeleri çıkarabiliyorum
     Yine de printed directory tree içine koyuyorum, böylece ajan en azından onların varlığını biliyor ve gerekirse belirli dosyaları isteyebiliyor
  • İlginç bir yaklaşım
    Bu birleştirme işini nasıl yaptığını merak ediyorum
    Elle mi yapıyorsun, sadece değişen dosyaları mı birleştiriyorsun, yoksa hibrit bir yöntem mi kullanıyorsun bilmek isterim

• LLM memory teoride kulağa hoş geliyor ama pratikte büyüdükçe, belleksiz kullanım kadar dağınık hale geliyor
  İlk ekrandaki örnekteki gibi projem üzerinde çalışmaya devam et deseniz bile, gerçekte çoğu kişi tek bir proje üzerinde çalışmıyor
  Bellekte 5, 10 kadar proje olabilir ve kaydedildikleri sırada her birinin bir anlamı vardı
  Sonunda yine sass projesine devam et gibi daha spesifik olmanız gerekiyor; biraz detay bağlamı kazanırken bir yandan da LLM context dolduruyor ve ek MCP calls maliyeti çıkarıyor

  • Doğru ama bu çok naive implementation bir örnek
    Düzgün yapılmış bir implementasyon bu sınırların ötesine geçebilir
  • Sonuçta neyin hatırlanacağını tek tek belirtmeye başladığınızda, bu aslında yapay zekaya dosyaya write/read yaptırmaktan çok da farklı olmuyor

• Bu, yalnız çalışan vibecoder’lar içinmiş gibi geliyor
  Gerçek insanlarla, gerçek projelerde çalışırken bu sistem tüm projenin belleğine sahip olamaz; benim de tümüne hâkim bir hafızam yok
  Başka PR’lar merge edildiğinde elimdeki bilgi hemen eskiyor ve benim önemsediğim şey yalnızca kendi ticket’ım oluyor
  Bu yüzden giderek bunun o tür işbirlikçi çalışma için bir araç olmayabileceğini düşünüyorum

• Artık yazılım üretmenin maliyeti neredeyse sıfıra yaklaşmışken, hâlâ bunun gibi bir şeyi vibe-coded pazarlama sitesi ile satmaya çalışmaları şaşırtıcı
  Kim bunu deneyip haftalarca, aylarca bekleyerek gerçekten çalışıp çalışmadığını görmek için zaman ayırabilir ki?
  Sitede bunun RAG’den ya da sadece bellek dosyaları klasörü + grep yaklaşımından daha iyi olduğuna dair hiçbir kanıt yok
  Buna rağmen her yerde fantastik iddialar var ve sayfa kaydırması bile 14fps takılıyor
  Bu sanki 24 saat önce kodlanmış gibi duruyor; açıkçası fazla tembelce geliyor