Yapay Zeka Ajanlarında Bellek Mimarileri: Oturumlar Arası Hatırlayan Ajanlar Kurmak

TL;DR — Yapay zeka ajanlarında bellek, 2026 itibarıyla artık "daha uzun bir bağlam penceresi" meselesi değil; modelin bağlam penceresinden bağımsız, mimari olarak tasarlanan kalıcı bir katman. Bu yazıda kısa vadeli ve uzun vadeli belleği, Letta'nın işletim sistemi esinli katmanlı yaklaşımını, Mem0'ın iki fazlı boru hattını, Cognee'nin graf tabanlı kalıcı belleğini ve Zep ile Redis gibi seçenekleri sahadan gözlemlerle karşılaştırıyorum. Ardından üretim ortamında saklama, özetleme (memory consolidation), maliyet ve değerlendirme kararlarını; en önemlisi de KVKK ve EU AI Act ile uyumlu bir bellek mimarisini nasıl kurarsınız, adım adım anlatıyorum.

Son bir yılda kurumsal müşterilerimle yaptığım neredeyse her ajan projesinde aynı duvara tosladık: Demo muhteşem çalışıyor, sonra kullanıcı ertesi gün geri geliyor ve ajan hiçbir şey hatırlamıyor. Adını, tercihlerini, dün yarım bıraktığınız işi, hatta beş dakika önce düzelttiğiniz bir hatayı bile. Bu, teknik bir kusurdan çok mimari bir eksiklik. Çünkü bir dil modeli, tanımı gereği durumsuzdur (stateless). Her çağrı, geçmişi olmayan yeni bir sayfadır.

2026'da olgunlaşan fikir tam da bu: Bellek, modelin içinde değil, modelin etrafında yaşayan ayrı bir bileşendir. Uzun süre "bağlam penceresini büyütürsek sorun çözülür" diye düşünüldü. Bağlam pencereleri gerçekten de büyüdü. Ama daha uzun bir prompt, hatırlayan bir sistem değildir. Bağlam penceresi geçici bir çalışma alanıdır; her oturum sonunda buharlaşır. Oysa bellek, oturumlar arasında kalıcı olarak bilgiyi saklayan, gerektiğinde geri çağıran, çelişkileri çözen ve zamanla öğrenen bir katmandır.

Bu ayrımı bir cümleyle netleştireyim, çünkü projelerin çoğu burada tökezliyor:

"

Bağlam penceresi ajanın kısa süreli dikkatidir; bellek ise ajanın hayat boyu biriktirdiği deneyimdir. Birincisi RAM gibi uçucudur, ikincisi disk gibi kalıcıdır.

İnsan bilişinden ödünç alınan bu ayrım, ajan tasarımında son derece pratik sonuçlar doğuruyor. İkisini karıştırdığınızda ya maliyetiniz patlıyor ya da ajanınız aptallaşıyor.

Kısa vadeli bellek, mevcut yürütmedeki (execution) son etkileşimleri tutar. Konuşmanın akışını, az önce çağrılan aracın çıktısını, kullanıcının iki mesaj önce söylediği şeyi kapsar. CrewAI gibi çerçeveler bunu tipik olarak ChromaDB ve yerel bir gömme (embedding) modeliyle çözüyor: etkileşimler vektörleştirilip geçici bir depoda tutuluyor, oturum bitince ilgisi kalmıyor. Amaç, tek bir görevin içinde tutarlılık.

Uzun vadeli bellek ise geçmiş görevlerden öğrenilen kalıcı bilgidir. Kullanıcının üç hafta önce belirttiği "faturaları her zaman PDF olarak isterim" tercihi, geçen ay çözülen bir destek talebinin sonucu, ajanın kendi hatalarından çıkardığı dersler. CrewAI bunun için sıklıkla SQLite gibi kalıcı bir depo kullanıyor. Buradaki amaç, oturumlar arası süreklilik ve kişiselleştirmedir.

Sahada gördüğüm en yaygın hata, her şeyi uzun vadeli belleğe yazmak. Ajan, "kullanıcı 'merhaba' dedi" gibi değersiz bir cümleyi bile kalıcı hafızaya kaydediyor, birkaç hafta sonra hafıza deposu binlerce anlamsız kayıtla şişiyor ve geri çağırma (retrieval) kalitesi çöküyor. Bellek, çöp kutusu değildir; neyin hatırlanmaya değer olduğuna karar veren bir süzgeç gerektirir.

Aşağıdaki tabloyu müşteri atölyelerimde beyaz tahtaya çizdiğim halin sadeleştirilmiş versiyonu olarak düşünün. Bir ajan tasarlarken hangi bellek türünün nereye oturduğunu netleştirmeden kod yazmaya başlamayın.

Bellek türü	Kapsam / süre	Tipik depo	Ne işe yarar	Riski
Kısa vadeli (çalışma)	Tek oturum / yürütme	ChromaDB + yerel embedding, bağlam penceresi	Konuşma tutarlılığı, araç çıktılarını izleme	Oturum bitince kaybolur
Uzun vadeli (epizodik)	Oturumlar arası, olay bazlı	SQLite, vektör DB	"Geçen sefer şunu yapmıştık" türü hatırlama	Şişme, alaka kaybı
Anlamsal (semantik)	Kalıcı, gerçek/olgu bazlı	Bilgi grafiği, vektör DB	Kullanıcı hakkında sabit gerçekler, tercihler	Çelişki yönetimi zor
Prosedürel	Kalıcı, beceri bazlı	Sistem promptu, araç tanımları	"Nasıl yapılır" bilgisi, iş akışları	Güncelleme disiplini ister
Kısa özet (consolidated)	Sıkıştırılmış geçmiş	Özet metin + vektör	Maliyet düşürme, uzun geçmişi taşıma	Detay kaybı

Bu beş türü tek bir üründe birden kullanmak zorunda değilsiniz. Çoğu kurumsal ajan için kısa vadeli + anlamsal (tercihler) + epizodik (geçmiş görevler) üçlüsü fazlasıyla yeterli. Prosedürel belleği çoğu zaman sistem promptu ve araç kataloğu üstleniyor zaten.

Letta'nın (eski adıyla MemGPT projesinden doğan yaklaşımın) bana en çekici gelen tarafı, belleği bir işletim sistemi metaforuyla ele alması. Fikir basit ama güçlü: Bir bilgisayarda RAM sınırlıdır, disk ise geniştir. İşletim sistemi, o an gereken sayfaları RAM'e taşır, gerekmeyeni diske geri yazar. Letta da tam olarak bunu yapıyor.

Burada ana bağlam (main context) RAM gibidir: modelin o anda gördüğü, sınırlı ve pahalı alan. Harici depolama ise disk gibidir: sınırsıza yakın ama erişmek için açık bir "sayfalama" işlemi gerektirir. Ajan, konuşma uzadıkça kendi belleğini yönetir; önemli bilgiyi harici depoya yazar, gerektiğinde geri çağırır, ana bağlamı temiz tutar. Yani model, kendi hafıza yöneticisi haline gelir.

Bu yaklaşımın sahadaki avantajı, uzun ve sürekli devam eden ilişkilerde (örneğin bir kurumsal asistanın aynı çalışanla aylarca çalışması) bağlam taşmasını zarifçe yönetmesi. Dezavantajı ise, ajanın kendi bellek operasyonlarını yürütmesi için ekstra model çağrıları harcaması; yani gizli bir maliyet kalemi doğurması. Küçük ve tek seferlik görevlerde bu ağırlık gereksiz.

Nisan 2026'da yayımlanan çalışmasıyla Mem0, belleği "yaz-oku" basitliğinden çıkarıp gerçek bir bilgi yönetim boru hattına dönüştürüyor. Beni en çok etkileyen tarafı, çelişkileri ciddiye alması.

Mem0'ın çalışma mantığı iki fazlı:

1. Çıkarım fazı (extraction): Bir etkileşim gerçekleştiğinde, bir dil modeli konuşmadan hatırlanmaya değer bilgiyi çıkarır. Ham metni olduğu gibi saklamaz; "kullanıcı İstanbul'da yaşıyor", "toplantıları sabah tercih ediyor" gibi damıtılmış olgular üretir.
2. Güncelleme fazı (update): Yeni çıkarılan bilgi, mevcut belleğe karşı sınanır. Burada kritik adım çelişki tespiti: Kullanıcı önceden "Ankara'da yaşıyorum" demişse ve şimdi "İstanbul'a taşındım" diyorsa, sistem eski kaydı körü körüne saklamaz; çelişkiyi fark eder ve graf güncellemesi yapar. Eski gerçek geçersizleşir, yenisi geçerli olur.

Mem0 ayrıca üç kapsamlı bir hiyerarşi sunuyor: kullanıcı düzeyi (bir kişi hakkında kalıcı gerçekler), oturum düzeyi (o görüşmeye özel), ve ajan düzeyi (ajanın kendi öğrendikleri). Bu ayrım kurumsal senaryolarda altın değerinde, çünkü bir sonraki başlıkta anlatacağım KVKK erişim kapsamı sorusuna doğrudan cevap veriyor.

Arka uçta Mem0 hibrit çalışıyor: vektör benzerliği (anlamsal yakınlık için) ve bilgi grafiği (varlıklar arası ilişkiler için) birlikte. Salt vektör aramanın kaçırdığı "kim kiminle ilişkili, hangi gerçek hangisini geçersiz kılar" sorularını graf tarafı yakalıyor.

Cognee, ayrımı yine netleştiren bir başka çerçeve. Burada oturum belleği kısa olanı, o anki görüşmeyi kapsar; kalıcı bellek ise uzun vadeliyi temsil eder ve bir grafta çapraz bağlı olarak tutulur. Grafın değeri şu: Tekil gerçekleri değil, gerçekler arasındaki ilişkileri saklarsınız. "Ahmet, X projesinin sahibi; X projesi Y departmanına bağlı; Y departmanı KVKK açısından hassas veri işliyor" gibi bir bilgi ağı, düz bir vektör deposunda kaybolur ama grafta canlı kalır ve akıl yürütmeye açılır.

Alanın tamamı bu üç isimden ibaret değil. Zep, konuşma geçmişini otomatik özetleyip zaman damgalı bir bellek deposuna dönüştürmesiyle, özellikle sohbet ağırlıklı ürünlerde pratik. Redis tabanlı çözümler ise düşük gecikmeli, yüksek hacimli uzun vadeli bellek isteyen ekiplerde tercih ediliyor; Redis'in hız avantajı, gerçek zamanlı ajanlarda geri çağırma darboğazını açıyor.

Benim müşterilere önerim genelde şu: Çerçeveye evlenmeyin. Bellek katmanını, altındaki depodan soyutlayacak bir arayüz (interface) tasarlayın. Bugün Mem0, yarın Redis, öbür gün kendi çözümünüz; iş mantığınız bundan etkilenmesin.

Teoriyi bir kenara bırakıp pratiğe gelelim. Bana en çok sorulan soru bu, o yüzden net konuşayım:

• Tek seferlik, kısa görevler (bir belgeyi özetle, bir formu doldur): Uzun vadeli belleğe hiç girmeyin. Kısa vadeli bağlam yeter. Bellek eklemek burada sadece karmaşıklık ve maliyettir.
• Kişiselleştirilmiş, sürekli asistanlar (aynı kullanıcıyla aylarca): Anlamsal bellek (tercihler) + epizodik bellek (geçmiş) şart. Mem0'ın kullanıcı-düzeyi kapsamı burada çok yerinde.
• İlişki-yoğun, kurumsal bilgi (departmanlar, projeler, kişiler arası bağlar): Graf tabanlı bir yaklaşım (Cognee tarzı) düz vektörden çok daha iyi akıl yürütür.
• Yüksek hacim, düşük gecikme (canlı müşteri hizmetleri): Redis tabanlı uzun vadeli bellek gecikmeyi kurtarır.
• Uzun, kesintisiz oturumlar (bağlam taşması riski): Letta'nın işletim sistemi esinli sayfalaması zarif bir çözüm.

Bir ajanı demoda çalıştırmak ile üretimde aylarca ayakta tutmak çok farklı iki iş. Üretimde belleğin en kritik problemi büyümedir. Her etkileşim yeni kayıt üretirse, birkaç ay sonra elinizde geri çağırması yavaş, alakası düşük, maliyeti yüksek bir bellek yığını olur.

Çözüm, insan beyninin uykuda yaptığına benzeyen bellek pekiştirme (memory consolidation): Ham, dağınık kısa vadeli kayıtları periyodik olarak damıtıp özet, kalıcı gerçeklere dönüştürmek. Pratikte şöyle uyguluyorum:

1. Ham kayıt tutma: Etkileşimler önce ham haliyle kısa vadeli depoya girer.
2. Periyodik damıtma: Belirli aralıklarla (oturum sonu ya da gecelik bir iş) bir model, ham kayıtları okuyup kalıcı olgulara indirger. "20 mesajlık konuşma" -> "kullanıcı X'i tercih ediyor, Y'den şikayetçi" gibi.
3. Çelişki çözümü: Mem0'ın yaptığı gibi, yeni damıtılan bilgi eskiyle çelişiyorsa eskisi geçersizlenir.
4. Arşivleme/silme: Ham kayıtlar, damıtıldıktan ve yasal saklama süreleri gözetildikten sonra arşivlenir ya da silinir.

Bu döngü hem maliyeti hem de geri çağırma kalitesini aynı anda iyileştirir. Bir müşterimde ham kayıtları haftalık pekiştirmeye aldığımızda, bellek deposu boyutu üçte bire düştü ve ajan cevap kalitesi gözle görülür arttı; çünkü artık gürültü içinde doğru gerçeği bulmak kolaylaşmıştı.

Bellek bedava değil. Üç ayrı maliyet kalemi doğar ve çoğu ekip bunları planlamaya dahil etmeyi unutuyor:

• Depolama maliyeti: Vektörler ve graf düğümleri yer kaplar. Milyonlarca kullanıcıda bu ciddi bir rakama ulaşır.
• Gömme (embedding) maliyeti: Her yeni bilgiyi vektörlemek model çağrısıdır. Yerel bir embedding modeliyle bunu ciddi ölçüde düşürebilirsiniz; CrewAI'ın yerel embedding tercihi tam da bu yüzden mantıklı.
• Çıkarım ve pekiştirme maliyeti: Mem0 tarzı çıkarım fazı ve Letta tarzı öz-yönetim, ekstra model çağrıları harcar. Bu gizli kalem, hacim büyüdükçe faturanın önemli bir dilimi olabilir.

Önerim: Belleği bir maliyet merkezi gibi izleyin. Kullanıcı başına aylık bellek maliyetini bir metrik olarak takip edin. "Her şeyi hatırla" iştahı, kontrolsüzce büyüyen bir bulut faturasına dönüşür.

Klasik LLM değerlendirmesi tek bir soru-cevabı ölçer. Ama bellek, tanımı gereği zaman içinde ve oturumlar arasında test edilmek zorundadır. Sahada kullandığım pratik yaklaşımlar:

• Geri çağırma doğruluğu: Ajana daha önce söylenen bir gerçeği, birkaç oturum sonra doğru hatırlayıp hatırlamadığını ölçen senaryolar kurun.
• Çelişki testi: Kullanıcının fikrini değiştirdiği durumları simüle edin; ajan eski mi yoksa yeni gerçeği mi kullanıyor?
• Gürültü direnci: Bellek binlerce kayıtla dolduğunda geri çağırma kalitesi düşüyor mu?
• Sızıntı testi (kritik): A kullanıcısının bilgisi, B kullanıcısının oturumunda asla görünmemeli. Bu hem bir kalite hem de bir KVKK meselesi.

İşte burası, Türkiye'de kurumsal bir ajan kurarken çoğu ekibin geç fark ettiği ama en pahalıya patlayan kısım. Şunu net söyleyeyim: Kullanıcı belleği, tanımı gereği kişisel veridir. Bir kullanıcının tercihlerini, geçmişini, davranışlarını kalıcı olarak saklıyorsanız, KVKK'nın (6698 sayılı kanun) kapsamındasınız demektir. Bu, sonradan yamayla çözülecek bir konu değil; mimarinin ilk gününden itibaren tasarıma girmeli.

Somut gereklilikler ve benim önerdiğim uygulama karşılıkları:

Hukuki dayanak ve rıza. Belleğe kişisel veri yazmadan önce bunun hangi hukuki sebebe dayandığını netleştirin. Çoğu senaryoda açık rıza ya da meşru menfaat gerekir; kullanıcıya "sizi hatırlayacağım" dediğinizde bunu şeffafça bildirin.

Saklama süresi ve amaçla sınırlılık. KVKK, veriyi süresiz saklamanıza izin vermez. Her bellek kaydına bir yaşam süresi (TTL) ve bir amaç etiketi iliştirin. Amaç ortadan kalktığında ya da süre dolduğunda kaydın otomatik silinmesini sağlayın. Yukarıda anlattığım pekiştirme döngüsü, bunu doğal bir noktaya oturtur.

Silme hakkı (unutulma hakkı). Kullanıcı "beni unut" dediğinde, sistem o kişiye ait tüm bellek kayıtlarını, vektörleri ve graf düğümlerini gerçekten silebilmeli. Mem0'ın kullanıcı-düzeyi kapsamı gibi bir hiyerarşi burada hayat kurtarır: Tek bir kullanıcı kimliğine bağlı her şeyi tek operasyonla temizleyebilirsiniz. Verileriniz düz, ayrımsız bir vektör deposundaysa bu neredeyse imkânsız hale gelir.

Erişim kapsamı ayrımı (multi-tenancy). Kurumsal ajanda A departmanının belleği B departmanına, bir kullanıcının belleği başka kullanıcıya sızmamalı. Bellek hiyerarşisini kullanıcı/oturum/ajan olarak ayırmak yalnızca teknik zarafet değil, doğrudan bir veri güvenliği ve KVKK gerekliliği. Yukarıda bahsettiğim sızıntı testini bu yüzden şart koşuyorum.

Veri ikametgahı. Bellek deponuz nerede fiziksel olarak duruyor? Yurt dışına veri aktarımı KVKK açısından ek yükümlülükler doğurur. Kurumsal müşterilerde bu, bazen self-hosted bir vektör DB ya da yurt içi barındırma tercihini zorunlu kılar.

EU AI Act tarafı. Avrupa pazarına dokunuyorsanız, AI Act'in risk temelli yaklaşımı devreye girer. Kalıcı bellek, ajanı daha "özerk" ve etkili kılar; bu da kullanıcı üzerinde daha fazla etki demektir. Şeffaflık yükümlülükleri (kullanıcının bir yapay zeka ile konuştuğunu ve hakkında bilgi saklandığını bilmesi), yüksek riskli kullanımlarda kayıt tutma ve insan gözetimi gibi maddeler, bellek tasarımınızı doğrudan etkiler. Belleğin ne sakladığını açıklayabilmek (açıklanabilirlik) artık bir lüks değil, uyum gerekliliği.

Teoriyi somuta indirmek için, geçen ay bir sigorta şirketiyle kurduğumuz asistanın bellek mimarisini sadeleştirerek paylaşayım. Amaç, aynı sigorta acentesiyle aylarca çalışan, poliçe geçmişini, müşteri tercihlerini ve geçmiş taleplerini hatırlayan bir ajan kurmaktı.

İlk kararımız, belleği üç ayrı yola bölmek oldu. Konuşma sırasında geçen anlık bağlam (hangi poliçeye bakıyoruz, hangi adımdayız) kısa vadeli katmanda tutuldu; oturum bitince silindi. Acentenin kalıcı tercihleri (dil, iletişim saati, hangi raporları istediği) anlamsal katmana yazıldı; kullanıcı kimliğine bağlandı. Geçmiş talepler ve bunların sonuçları ise epizodik katmana, zaman damgalı olarak kaydedildi.

İkinci kritik karar geri çağırma stratejisiydi. Her yeni soruda üç katmanı da körü körüne sorgulamak yerine, önce sorunun türünü sınıflandıran hafif bir adım koyduk: Soru anlık bağlamla mı ilgili, kalıcı bir tercihle mi, yoksa geçmiş bir olayla mı? Bu sınıflandırma, gereksiz sorguları eledi; hem gecikmeyi hem de maliyeti düşürdü. Sahada öğrendiğim şu: Her belleği her sorguda okumak, hem pahalı hem de gürültü yaratan bir alışkanlıktır. Belleğin gücü, ne zaman sessiz kalacağını bilmesindedir.

Mem0 ve Cognee'nin ortak noktası hibrit arka uç kullanmaları. Bu tercihi neden önemsediğimi somutlaştırayım, çünkü çoğu ekip yalnızca vektör aramayla başlıyor ve bir duvara tosluyor.

Vektör araması anlamsal benzerlik için mükemmeldir: "müşteri araç sigortası hakkında ne demişti?" gibi bulanık, anlam odaklı sorularda ilgili kayıtları getirir. Ama vektör araması ilişkileri bilmez. "Bu müşterinin eşinin poliçesi hangisiydi ve o poliçe bu talebi nasıl etkiler?" gibi çok adımlı, ilişkisel bir soruda vektör tek başına yetersiz kalır; çünkü her kaydı bağımsız bir nokta olarak görür, aralarındaki bağı değil.

İşte bilgi grafiği tam da burada devreye giriyor. Graf, varlıkları (müşteri, poliçe, talep, departman) düğüm; aralarındaki ilişkileri kenar olarak tutar. Böylece "A müşterisinin B poliçesi, C talebini tetikledi" gibi bir zinciri gezinerek akıl yürütebilirsiniz. Benim pratik önerim şu:

"

Anlamsal, bulanık sorgular için vektör; ilişkisel, çok adımlı akıl yürütme için graf. İkisini birbirinin yerine değil, birbirini tamamlayan iki lens olarak düşünün.

Küçük başlıyorsanız salt vektörle yola çıkın; ilişkisel karmaşıklık arttığında grafı devreye alın. Baştan graf kurmak, ihtiyaç yoksa gereksiz bir mühendislik yüküdür.

Az konuşulan ama beni en çok endişelendiren konulardan biri bu. Bellek, tanımı gereği bir güven sınırını bulanıklaştırır: Ajan, geçmişte sakladığı bir bilgiyi genellikle "doğru" varsayar. Peki ya o bilgi kötü niyetle yerleştirilmişse?

Düşünün: Bir kullanıcı, bir konuşma sırasında ajana "her zaman şu talimatı uygula" gibi gizli bir yönerge fısıldıyor ve bu, kalıcı belleğe bir "tercih" olarak yazılıyor. Sonraki oturumlarda ajan, bu zehirlenmiş belleği geri çağırıp körü körüne uyguluyor. Buna bellek zehirlenmesi (memory poisoning) deniyor ve dolaylı prompt enjeksiyonunun kalıcı, sinsi bir türü.

Sahada aldığım önlemler şunlar: Belleğe yazılan her şeyi bir "veri" olarak işaretleyin, asla "talimat" olarak değil. Belleğe yazma anında bir doğrulama katmanı koyun; kullanıcı içeriğinin sistem talimatına dönüşmesini engelleyin. Ve en önemlisi, kritik eylemler (para transferi, poliçe iptali) için belleğe değil, o anki teyide ve insan onayına güvenin. Bellek hatırlatır, ama yetkilendirmez.

Türkçe ajan kurarken fark ettiğim ince bir konu var. Bellek çıkarımı bir dil modeliyle yapıldığında, modelin Türkçe nüansları ne kadar iyi yakaladığı doğrudan bellek kalitesini etkiliyor. "Beyefendi sabahları aranmak istemiyor" gibi bir tercihi model yanlış damıtırsa, o hata kalıcı belleğe yazılıp aylarca yanlış davranışa yol açabilir.

Bu yüzden Türkçe ağırlıklı ürünlerde, bellek çıkarım adımını ayrıca test ediyorum: Gerçek Türkçe konuşmalardan örnekler alıp, modelin ürettiği damıtılmış olguları elle denetliyoruz. Ayrıca kültürel bağlam da önemli; resmi/samimi hitap ayrımı, unvan kullanımı gibi tercihler Türk kullanıcılar için beklenenden daha kritik. Bunları anlamsal belleğe açıkça yazmak, ajanı gözle görülür biçimde daha "yerli" ve güven veren biçimde konuşturuyor.

Kapanışa geçmeden, sahada tekrar tekrar karşılaştığım hataları bir liste halinde bırakayım; kendi projenizde bunları erken yakalarsanız aylar kazanırsınız:

• Bellek eşittir bağlam penceresi sanmak. En temel ve en pahalı yanılgı. Uzun prompt, hatırlayan sistem değildir.
• Her şeyi kalıcı yazmak. Süzgeçsiz bellek, birkaç ay içinde işe yaramaz bir yığına döner.
• Silme yolunu baştan kurmamak. Unutulma hakkı geldiğinde, düz vektör deposundan kullanıcı bazında silme yapamayınca panikleyen ekipler gördüm.
• Çelişkiyi görmezden gelmek. Kullanıcı fikrini değiştirdiğinde eski gerçeği saklayan ajan, güveni hızla kaybeder.
• Belleği ölçmemek. Geri çağırma doğruluğunu ve maliyeti izlemeyen ekip, sorunu ancak kullanıcı şikayet edince fark eder.
• Güvenlik sınırını unutmak. Belleği talimat kaynağı olarak kullanmak, kalıcı bir enjeksiyon kapısı açar.

Kurumsal projelerde en çok işime yarayan alışkanlık, belleği "havalı bir özellik" olmaktan çıkarıp bir birim ekonomisi kalemine dönüştürmek. Yani her bellek kararını, kullanıcı başına düşen aylık maliyet ve ürettiği somut değerle birlikte konuşmak. Bir asistanın bir kullanıcıyı hatırlaması hoş bir cümle; ama bu hatırlamanın aylık kaç kuruşa mal olduğunu ve karşılığında kaç dakikalık iş tasarrufu sağladığını bilmiyorsanız, kararınız duyguya dayanıyor demektir.

Sahada şöyle bir tablo çıkarıyorum: Kullanıcı başına saklanan ortalama kayıt sayısı, bu kayıtların gömme ve saklama maliyeti, pekiştirme adımının aylık model çağrısı maliyeti ve geri çağırmanın her istekteki ek yükü. Bu dört kalemi topladığınızda, "hatırlayan ajan" özelliğinin gerçek fiyat etiketini görürsünüz. Çoğu zaman şaşırtıcı derecede makul çıkar; ama ara sıra, kontrolsüz büyüyen bir bellekte kullanıcı başına maliyetin, ajanın ürettiği değeri aştığını da gördüm. İşte o an, pekiştirme ve budama disiplinini devreye almanın tam zamanıdır.

Bir diğer pratik ölçüt, belleğin isabet oranı. Geri çağrılan kayıtların kaçı gerçekten cevaba katkı sağladı? Eğer ajan her soruda on kayıt çekiyor ama bunların yalnızca ikisi işe yarıyorsa, hem para hem bağlam alanı israf ediyorsunuz demektir. Bu oranı ölçüp geri çağırma eşiğini sıkılaştırmak, çoğu zaman kaliteyi düşürmeden maliyeti ciddi biçimde azaltır.

Son olarak, belleğin değerini iş metriğine bağlamak gerekir. Sigorta asistanı örneğimde, hatırlayan sürüm ile hatırlamayan sürümü yan yana koyduk: Hatırlayan sürümde acenteler tekrar eden bilgileri baştan girmedikleri için işlem başına ortalama süre belirgin biçimde düştü. İşte belleğin gerçek gerekçesi budur; teknik zarafet değil, ölçülebilir bir iş kazanımı. Bir özelliği bu şekilde savunabiliyorsanız, yönetime de kendinize de dürüst olmuş olursunuz. Bir başka deyişle, belleği ölçmek yalnızca mühendislik disiplini değil, aynı zamanda projeyi yaşatan ticari argümandır; çünkü ölçülemeyen bir özellik, ilk bütçe kısıntısında elenmeye en yakın adaydır.

Bir sonraki ajan projenizde belleği baştan doğru kurmak isterseniz, benim sahada izlediğim sıralama şu:

1. İhtiyacı sınıflandırın. Görev tek seferlik mi, ilişkisel mi? Gereksiz belleği baştan reddedin; her ajanın kalıcı belleğe ihtiyacı yok.
2. Bellek türlerini ayırın. Kısa vadeli, anlamsal ve epizodik belleği ayrı ayrı tasarlayın; hepsini tek bir çöp deposuna atmayın.
3. Depoyu soyutlayın. Mem0, Cognee, Zep ya da Redis; hangisiyle başlarsanız başlayın, iş mantığınızı arayüzün arkasına saklayın.
4. Pekiştirme döngüsü kurun. Ham kayıtları periyodik damıtın, çelişkileri çözün, süresi dolanı silin. Bellek bir bahçedir, budanması gerekir.
5. KVKK'yı ilk gün tasarıma alın. TTL, amaç etiketi, kullanıcı bazında silme, kapsam ayrımı ve veri ikametgahı; bunları sonraya bırakmak en pahalı hatadır.
6. Ölçün. Geri çağırma doğruluğunu, çelişki yönetimini, sızıntı testini ve kullanıcı başına maliyeti düzenli izleyin.

Hatırlayan bir ajan kurmak, teknik olarak heyecan verici ama sorumluluğu ağır bir iş. Bir sistemin sizi hatırlaması güçlü bir kişiselleştirme vaadi; ama aynı vaat, yanlış tasarlandığında bir gizlilik yükümlülüğüne dönüşür. İyi haber şu: Doğru mimariyle ikisini aynı anda başarabilirsiniz. Belleği modelin içinde değil, etrafında; kontrollü, ölçülebilir ve silinebilir bir katman olarak kurduğunuzda, hem daha akıllı hem de daha güvenilir ajanlar elde edersiniz.