# AI Agent Belleği: Kısa, Uzun ve Graph Bellek Mimarileri ve Üretim Desenleri (2026) > Source: https://sukruyusufkaya.com/blog/ai-agent-bellegi-memory-mimarileri-2026 > Updated: 2026-07-22T00:06:13.169Z > Type: blog > Category: yapay-zeka **TLDR:** AI ajanlarının bir numaralı başarısızlık sebebi bellek. Kısa/uzun/graph bellek mimarileri, multi-scope desen, LangGraph ve KVKK uyumlu saklama için sahadan 2026 rehberi. **TL;DR —** Bir AI ajanının başarısız olmasının bir numaralı sebebi, doğru anda doğru bağlama sahip olmamasıdır. 2026'da agent memory (ajan belleği), bir "güzel özellik" olmaktan çıkıp üretim ajanlarının temel mimari katmanı haline geldi. Bu yazıda kısa süreli, uzun süreli ve yapısal bellek türlerini, çok kapsamlı (multi-scope) bellek desenini, vektör benzerliğinin ötesine geçen graph memory'yi, ve KVKK uyumlu bellek saklama stratejilerini sahadan anlatıyorum. LangGraph checkpointer, Redis/Postgres seçimleri ve bellek yönetiminde en sık yapılan hatalar dahil. ## Neden ajanların belleğe ihtiyacı var? Basit bir chatbot her mesajı sıfırdan işleyebilir. Ama bir ajan — çok adımlı görevleri yürüten, araçları çağıran, kararlar zincirleyen bir sistem — hafızasız çalışamaz. Bir önceki adımda ne yaptığını, kullanıcının daha önce ne söylediğini, hangi kararı neden verdiğini hatırlamak zorunda. Belleksiz bir ajan, her turda amnezi geçiren bir asistan gibidir: teknik olarak çalışır ama pratikte işe yaramaz. Sahada gördüğüm ajan başarısızlıklarının büyük çoğunluğu, modelin zekâsıyla değil, belleğin yanlış yönetilmesiyle ilgili. Model doğru cevabı verebilecek kapasitede ama gereken bağlam ona ulaşmıyor; ya da tam tersi, alakasız geçmiş bilgiyle bağlam kirleniyor ve model kayboluyor. Bellek mimarisi, ajanın gerçek dünyada güvenilir olup olmayacağını belirleyen asıl faktör. > Üretim ajanlarının en çok başarısız olduğu tek sebep: ajan, doğru anda doğru bağlama sahip değil. Bunu bir kez kabul ettiğinizde, mühendislik enerjinizi modeli değiştirmeye değil, bellek katmanını doğru kurmaya yönlendirirsiniz. ## Üç bellek türü: kısa, uzun ve yapısal Olgun ajan mimarileri üç bellek türünü ayırır. Kısa süreli bellek (short-term), o anki konuşma bağlamıdır — genellikle bağlam penceresine sığan, aktif görev boyunca tutulan bilgi. Uzun süreli bellek (long-term), geçmiş etkileşimlerden damıtılan ve vektör veritabanında semantik arama için gömülen bilgi. Yapısal bellek (structured) ise olguların ilişkisel bir veritabanında saklandığı katman — kullanıcının adı, tercihleri, hesap durumu gibi kesin, sorgulanabilir veriler. Bu üçlü ayrım kritik çünkü her tür farklı bir erişim deseni gerektirir. Kısa süreli belleği doğrudan bağlama koyarsınız; uzun süreli belleği semantik aramayla getirirsiniz; yapısal belleği ise net sorgularla (kullanıcı kimliği ile) çekersiniz. Bu üçünü tek bir mekanizmaya sıkıştırmaya çalışmak — örneğin her şeyi vektör aramasına yıkmak — hem verimsiz hem hataya açık. ## Kısa süreli bellek: bağlam penceresini yönetmek Kısa süreli bellek göründüğünden zordur çünkü bağlam penceresi sınırlıdır. Uzun bir görev boyunca konuşma büyüdükçe, her şeyi bağlamda tutmak hem pahalı hem de "lost in the middle" riskini artırır. Bu yüzden kısa süreli belleği aktif olarak yönetmek gerekir: eski turları özetlemek, alakasız ayrıntıları budamak, sadece görev için gerekli olanı tutmak. Yaygın bir teknik, kayan pencere (sliding window) ile özetlemeyi birleştirmek. Son birkaç tur tam metin olarak tutulur; daha eski turlar bir özete sıkıştırılır. Böylece model hem yakın bağlamı ayrıntılı görür hem de uzak geçmişin özünü kaybetmez. Türkçe için ek bir dikkat: özetleme sırasında Türkçe'nin token maliyeti daha yüksek olduğundan, özet bütçesini biraz daha cömert planlamak gerekir. ## Uzun süreli bellek: neyi hatırlamalı, neyi unutmalı? Uzun süreli belleğin asıl zorluğu, neyin saklanmaya değer olduğuna karar vermek. Her etkileşimi saklamak, belleği gürültüyle doldurur ve retrieval kalitesini düşürür. İyi bir ajan, önemli olanı (kullanıcının kalıcı tercihleri, tekrar eden sorunlar, önemli kararlar) damıtıp saklar; geçici, önemsiz ayrıntıları ise unutur. Bu "neyi hatırla" kararı genellikle bir LLM'e verilir: her etkileşim sonunda model, "bu konuşmadan gelecekte hatırlanmaya değer ne var?" diye değerlendirir ve sadece o özü belleğe yazar. Bu, insan belleğinin çalışma şekline benzer — her anı değil, önemli olanı saklarız. Unutma da bir özellik olmalı: eskiyen, artık geçerli olmayan bilgiler zamanla soldurulmalı ya da silinmeli. ## Multi-scope bellek: kimliğe göre etiketleme 2026'nın en güçlü bellek desenlerinden biri çok kapsamlı (multi-scope) bellek. Fikir şu: her bellek yazımı, kimlik kapsamlarıyla etiketlenir — kullanıcı kimliği, ajan kimliği, oturum/çalışma kimliği, uygulama/organizasyon kimliği. Bu kapsamlar, erişim anında birleştirilerek sonuçları otomatik olarak harmanlar ve sıralar. Bunun pratik değeri büyük. Bir kurumsal ajan, aynı anda birden fazla kullanıcıya hizmet eder; her kullanıcının belleği ayrı tutulmalı ama organizasyon düzeyindeki ortak bilgi (şirket politikaları, ürün bilgisi) paylaşılmalı. Multi-scope etiketleme, bu ayrımı temiz biçimde yapar: kişisel belleği kullanıcı kapsamında, ortak belleği organizasyon kapsamında tutar. KVKK açısından da kritik — bir kullanıcının belleği, kapsam filtresiyle asla başka bir kullanıcıya sızmaz. ## Graph memory: vektör benzerliğinin ötesi 2024'te deneysel olan graph memory, 2026'da üretime geçti. Saf vektör benzerliğinin bir sınırı var: "Ahmet, Ayşe'nin yöneticisi" gibi ilişkisel bilgiyi vektör uzayında iyi temsil edemezsiniz. Graph memory, varlıkları (kişiler, projeler, kavramlar) düğüm, ilişkileri ise kenar olarak saklar. Böylece ajan, "Ahmet'in raporladığı kişi kim?" gibi ilişkisel soruları gerçek bir grafik üzerinde gezinerek cevaplar. Graph memory'nin gücü, çok adımlı çıkarımda ortaya çıkar. Bir kullanıcı hakkında biriken bilgiler bir graf oluşturur; ajan bu grafı gezerek dolaylı bağlantıları keşfeder. Bugün 13'ten fazla ajan çerçevesi graph memory entegrasyonunu destekliyor. Ama graph memory ücretsiz değil: kurulumu ve bakımı vektör belleğinden karmaşık. Çoğu ajan için vektör + yapısal bellek yeterli; graph memory, ilişki-yoğun alanlarda (kurumsal bilgi grafları, müşteri ağları) değerini gösterir. ## Bellek altyapısı: in-memory, Redis, Postgres Ajan belleğini nerede saklarsınız? Üç ana seçenek var, her biri farklı ölçek ve gereksinim için. In-memory (bellekte) saklama, geliştirme ve prototipleme için idealdir — hızlı ama kalıcı değil, süreç yeniden başlayınca uçar. Redis, orta ölçek için (yaklaşık 100 binden az aktif oturum) mükemmel — hızlı, kalıcı ve dağıtık. Postgres ise kalıcılık ve denetim gerektiren durumlar için — daha yavaş ama sağlam, ilişkisel sorgular ve tam denetim izi sunar. LangGraph gibi olgun ajan çerçeveleri, checkpointer soyutlamasıyla bu üçünü de destekler. Yani belleği in-memory ile geliştirir, sonra tek satır değişiklikle Redis ya da Postgres'e taşırsınız. Bu esneklik önemli çünkü ölçek büyüdükçe altyapı gereksinimi değişir. Küçük başlayıp gerektiğinde büyümek, baştan Postgres'e yatırım yapmaktan daha akıllıca. | Altyapı | Ne zaman? | Artı / Eksi | |---|---|---| | In-memory | Geliştirme, prototip | Hızlı ama kalıcı değil | | Redis | Orta ölçek, <100K aktif oturum | Hızlı, dağıtık; kalıcılık sınırlı | | Postgres | Kalıcı, denetim gerektiren | Sağlam, sorgulanabilir; daha yavaş | ## Multi-agent orkestrasyon: hiyerarşik desen Tek bir ajan yerine birden fazla ajanın işbirliği yaptığı sistemlerde bellek daha da kritikleşir. En yaygın üretim deseni hiyerarşik orkestrasyon: bir orkestratör ajan, görevi uzmanlaşmış alt ajanlara dağıtır. Bu desen popüler çünkü kararları zincir boyunca geriye izlemek mümkün — hangi alt ajan neyi neden yaptı, takip edilebilir. Ama çoklu ajan sistemleri bir tehlike taşır: bağlam kaybı. Bir ajan diğerine görev devrederken, gereken bağlamı eksik aktarırsa, alt ajan yanlış varsayımlarla çalışır ve hata sessizce yayılır. Bu yüzden ajanlar arası açık "devir sözleşmeleri" (handoff contracts) şart. Yani bir ajan diğerine ne aktardığını, hangi formatta, hangi bağlamla aktardığını netleştiren yapılandırılmış bir arayüz. Bu sözleşmeler olmadan, çoklu ajan sistemlerinde sessiz bağlam kaybını ayıklamak haftalar alır. ## Retrieval optimizasyonu: belleği doğru getirmek Bellek yazmak yeterli değil; doğru anda doğru belleği getirmek gerekir. Üretim ajanları hibrit dense-artı-sparse retrieval kullanır: semantik benzerlik için yoğun gömme, anahtar kelime hassasiyeti için BM25 tarzı seyrek eşleşme. Belirsiz niyetler için sorgu yeniden yazma, ve gerçek sorgu dağılımına göre ayarlanmış top-k kalibrasyonu. Bellek retrieval'ında özel bir zorluk, zamansal alaka. En yeni bellek her zaman en alakalı değildir; ama çok eski bir bellek de artık geçerli olmayabilir. İyi bir bellek sistemi, semantik alaka ile zamansal tazelik arasında denge kurar — örneğin skorlamada hem benzerliği hem de yeniliği hesaba katar. Bu incelik, ajanın "kullanıcının geçen ay değiştirdiği tercihi" doğru hatırlamasını sağlar. ## KVKK ve bellek: kişisel verinin saklanması Ajan belleği, doğası gereği kişisel veri biriktirir — kullanıcının söyledikleri, tercihleri, davranış kalıpları. Bu, KVKK açısından ciddi bir sorumluluk. Belleğe yazılan her kişisel veri için bir hukuki dayanak, bir saklama süresi ve bir silme mekanizması olmalı. "Kullanıcı sildirmek isterse ne olacak?" sorusunu sistem tasarlanırken cevaplamak gerekir, sonradan değil. Pratik bir yaklaşım, belleği kapsamlara ayırırken KVKK sınıflandırmasını da gömmek: hangi bellek parçası kişisel veri içeriyor, hangi hukuki dayanağa dayanıyor, ne zaman silinmeli. Bir kullanıcı "beni unut" dediğinde, multi-scope etiketleme sayesinde o kullanıcının kapsamındaki tüm bellek temiz biçimde silinebilir. Bu "unutulma hakkı"nı teknik olarak uygulanabilir kılmak, KVKK uyumunun ajan mimarisindeki karşılığıdır. ## Bellek zehirlenmesi ve güvenlik Bir güvenlik boyutu sık atlanır: bellek zehirlenmesi (memory poisoning). Eğer bir ajan, kullanıcı girdisinden öğrendiklerini eleştirisizce belleğe yazıyorsa, kötü niyetli bir kullanıcı belleğe yanlış ya da zararlı bilgi enjekte edebilir. Bu enjekte edilen bilgi, sonraki etkileşimlerde ajanın davranışını bozar — bir tür kalıcı prompt injection. Korunmak için, belleğe yazmadan önce bir doğrulama katmanı koyun. Kullanıcının iddia ettiği her şeyi olgu olarak saklamayın; özellikle güvenlik-kritik bilgileri (yetkiler, kimlik) bellekten değil, güvenilir kaynaklardan doğrulayın. Bellek, ajanın hafızasıdır ama aynı zamanda bir saldırı yüzeyidir; bu ikili doğayı tasarımda hesaba katmak, olgun ajan mühendisliğinin işaretidir. ## Bellek değerlendirmesi: nasıl ölçülür? Belleğin çalışıp çalışmadığını nasıl bilirsiniz? Bu, ajan geliştirmenin en ihmal edilen tarafı. Bellek değerlendirmesi için senaryo temelli testler kurun: çok turlu diyaloglar tasarlayın ve ajanın önceki turlarda verilen bilgiyi doğru hatırlayıp hatırlamadığını ölçün. Örneğin, ilk turda kullanıcı bir tercih belirtir; beşinci turda ajan bu tercihi uygulamalı. Bunu ölçmezseniz, belleğin ne zaman bozulduğunu fark edemezsiniz. 2026'da ajan belleği için ilerleme kaydeden benchmark'lar ortaya çıktı; bunlar bellek doğruluğunu, geri çağırma tutarlılığını ve uzun diyaloglarda dayanıklılığı ölçüyor. Ama en değerli değerlendirme, kendi kullanım senaryolarınıza özel olanıdır. Gerçek kullanıcı diyaloglarından türetilmiş bir bellek testi kümesi, ajanınızın gerçekte ne kadar iyi hatırladığını gösterir — genel benchmark'lar bunu yapamaz. ## Yaygın hatalar ve nasıl kaçınılır **Her şeyi hatırlamaya çalışmak.** En sık hata, ajanı bir dijital biriktiriciye çevirmek. Aşırı bellek, retrieval'ı gürültüyle boğar ve maliyeti şişirir. Çözüm, seçici olmak: sadece gerçekten önemli olanı sakla. **Belleği tek bir mekanizmaya yıkmak.** Her şeyi vektör aramasına ya da her şeyi bağlam penceresine sıkıştırmak yerine, üç bellek türünü doğru kullanın. Yapısal veri ilişkisel veritabanında, semantik bilgi vektörde, aktif bağlam pencerede. **Devir sözleşmelerini atlamak.** Çoklu ajan sistemlerinde ajanlar arası bağlam aktarımını netleştirmemek, sessiz hatalara yol açar. Her devirde ne aktarıldığını açıkça tanımlayın. **KVKK'yı sonraya bırakmak.** Belleği kişisel veri toplayan bir sistem olarak baştan tasarlayın; silme ve saklama süresini sonradan eklemeye çalışmak çok daha pahalı. ## Nereden başlamalı: pratik bir yol haritası Yeni bir ajan kuruyorsanız, önerdiğim sıralama şu: Önce basit bir kısa süreli bellek ile başlayın — kayan pencere ve özetleme. Çoğu ajan için bu, ilk üretim sürümü için yeterli. Ardından, kullanıcılar arası kalıcılık gerektiğinde uzun süreli bellek ekleyin; multi-scope etiketleme ile kullanıcı ve organizasyon kapsamlarını ayırın. Yapısal veriyi (kullanıcı profili, tercihler) ilişkisel bir veritabanında tutun. Graph memory'yi ancak ilişki-yoğun bir ihtiyaç ortaya çıktığında ekleyin — çoğu ajan buna asla ihtiyaç duymaz. Altyapıda in-memory ile geliştirin, Redis ile ölçekleyin, denetim gerektiğinde Postgres'e geçin. Ve en baştan bir bellek değerlendirme kümesi kurun; belleği ölçmeden geliştirmek, karanlıkta yürümektir. Bu kademeli yaklaşım, hem gereksiz karmaşıklıktan kaçınmanızı hem de sisteminizi ihtiyaç büyüdükçe sağlıklı biçimde büyütmenizi sağlar. Ajan belleği, 2026'da artık isteğe bağlı bir eklenti değil; güvenilir bir ajanın belkemiği. ## Bellek sıkıştırma: token bütçesini korumak Uzun süreli bir ajan, zamanla devasa bir bellek birikimi oluşturur. Bu belleğin tamamını her sorguda getirmek imkânsız — hem token bütçesini aşar hem de modeli boğar. Bu yüzden bellek sıkıştırma (memory compaction) kritik bir mekanizma haline gelir. Fikir şu: biriken ham anıları periyodik olarak damıtıp özetlere dönüştürmek, ayrıntıyı azaltıp özü korumak. Sahada işe yarayan yaklaşım, katmanlı özetleme. En yeni anılar tam ayrıntıyla tutulur; orta yaştaki anılar özetlere sıkıştırılır; en eski anılar ise ya çok yüksek seviyeli özetlere indirgenip ya da tümüyle arşivlenir. Bu, insan belleğinin çalışma şekline benzer: dünkü toplantıyı ayrıntısıyla, geçen yılki projeyi ise ana hatlarıyla hatırlarız. Ajan belleğini bu insan benzeri katmanlı yapıya oturtmak, hem token verimliliğini hem de erişim kalitesini artırır. Türkçe bağlamında sıkıştırma özellikle değerli çünkü Türkçe token maliyeti daha yüksek. Aynı miktarda bilgiyi daha az token'da tutmanın yolu, agresif ama akıllı özetlemedir. Ancak dikkat: aşırı sıkıştırma, gelecekte gerekebilecek bir ayrıntıyı yok edebilir. Denge, "neyi kaybetmeyi göze alabilirim?" sorusuyla kurulur; kritik olgular yapısal bellekte kesin biçimde tutulurken, konuşma bağlamı daha rahat sıkıştırılabilir. ## Episodik ve semantik bellek ayrımı Bilişsel bilimden ödünç alınan bir ayrım, ajan mimarisinde giderek yaygınlaşıyor: episodik bellek ve semantik bellek. Episodik bellek, belirli olayların kaydıdır — "3 Mart'ta kullanıcı şu hatayı bildirdi." Semantik bellek ise olaylardan damıtılan genel bilgidir — "bu kullanıcı genellikle mobil cihazdan bağlanıyor." Ajan, episodik anılardan zamanla semantik bilgi çıkarır. Bu ayrım pratik bir tasarım deseni sunar. Ham etkileşimleri episodik bellek olarak kaydedersiniz; sonra periyodik bir "yansıtma" (reflection) süreci bu episodik anıları tarayıp semantik içgörüler çıkarır. Örneğin, kullanıcının son on etkileşiminin hepsinde belirli bir konuda zorlandığını fark eden ajan, "bu kullanıcı X konusunda ek desteğe ihtiyaç duyuyor" gibi bir semantik anı oluşturur. Bu içgörü, gelecekteki etkileşimleri kişiselleştirir. Yansıtma süreci, ajanı reaktif bir araçtan proaktif bir asistana dönüştüren şeydir. Ama maliyeti var: her yansıtma bir LLM çağrısıdır. Bu yüzden yansıtmayı sürekli değil, tetiklenmiş biçimde çalıştırmak akıllıca — belirli sayıda yeni etkileşim biriktikten sonra ya da boş zamanlarda. Sürekli yansıtma, çoğu ajan için gereksiz maliyet demektir. ## Bellek ve kişiselleştirme: sınırlar nerede? Ajan belleği kişiselleştirmenin motorudur — kullanıcıyı hatırlamak, tercihlerini uygulamak, geçmişe atıfta bulunmak. Ama kişiselleştirmenin bir sınırı var; aşırıya kaçtığında "ürkütücü" (creepy) bölgeye girer. Kullanıcının aylar önce geçici olarak bahsettiği bir ayrıntıyı beklenmedik bir anda hatırlatmak, yardımcı olmaktan çok rahatsız edici olabilir. İyi bir bellek tasarımı, neyi hatırlayacağı kadar neyi hatırlatacağına da dikkat eder. Bir bilgiyi saklamak, onu her fırsatta gündeme getirmek anlamına gelmez. Ajan, belleğini bağlama uygun biçimde, kullanıcının beklediği ölçüde kullanmalı. Bu incelik, teknik bir mesele olduğu kadar bir ürün tasarımı meselesi — ve KVKK açısından da önemli, çünkü kişisel veriyi işlemenin ölçülü ve amaca uygun olması gerekir. Şeffaflık burada güven inşa eder. Kullanıcıya ajanın ne hatırladığını görme ve düzenleme imkânı vermek — bir "bellek paneli" — hem KVKK'nın şeffaflık ilkesine hizmet eder hem de kullanıcının kontrol hissini güçlendirir. En olgun ajan ürünleri, belleği gizli bir mekanizma değil, kullanıcının görebildiği ve yönetebildiği açık bir özellik olarak sunuyor. ## Dağıtık bellek: birden fazla ajan, tek gerçek kaynağı Kurumsal ortamlarda genellikle tek bir ajan değil, bir ajan filosu çalışır — müşteri hizmetleri ajanı, satış ajanı, teknik destek ajanı. Bu ajanların bir kısmı aynı kullanıcıyla farklı bağlamlarda etkileşir. Soru şu: bu ajanlar belleği paylaşmalı mı, yoksa her biri kendi belleğini mi tutmalı? Cevap, dikkatli bir mimari kararıdır. Tümüyle ayrı bellekler, tutarsızlığa yol açar — kullanıcı bir ajana söylediğini diğerinin bilmemesi. Tümüyle paylaşılan bellek ise gizlilik ve kapsam sorunları doğurur. Pratik çözüm, katmanlı paylaşım: kullanıcıya dair temel, kalıcı bilgiler (kimlik, tercihler) paylaşılan bir katmanda tutulur; her ajanın kendi göreve özel belleği ise ayrı kalır. Bu, hem tutarlılık hem de ayrışma sağlar. Bu dağıtık mimaride "tek gerçek kaynağı" (single source of truth) ilkesi kritik. Aynı olgunun (örneğin kullanıcının e-posta adresi) birden fazla yerde farklı değerlerle tutulması, kaosun reçetesidir. Yapısal, paylaşılan bir kimlik katmanı bu olguları tek yerde tutar; ajanlar bu katmandan okur, kendi yerel kopyalarını üretmez. Bu disiplin, ajan filosunun tutarlı davranmasının temeli. ## Maliyet ve gecikme: belleğin gizli faturası Bellek, ajanı akıllı kılar ama bedava değil. Her bellek yazımı, her retrieval, her özetleme ve yansıtma çağrısı hem para hem gecikme ekler. Bir ajanı üretime alırken bu gizli faturayı görmezden gelmek, sonradan sürpriz maliyetlerle karşılaşmaya yol açar. Özellikle yüksek hacimli ajanlarda, bellek işlemleri toplam maliyetin belirgin bir kısmını oluşturabilir. Optimizasyonun anahtarı, her bellek işleminin marjinal değerini sorgulamak. Her etkileşimde yansıtma çalıştırmak gerekli mi, yoksa periyodik yeterli mi? Her sorguda tam bellek retrieval'ı mı, yoksa çoğu sorgu için hafif bir arama mı? Gecikme açısından da bellek retrieval'ı, ajanın yanıt süresine doğrudan eklenir; bu yüzden bellek aramasını hızlı tutmak (iyi indeksleme, uygun altyapı) kullanıcı deneyimini doğrudan etkiler. Sahada gördüğüm en olgun ekipler, belleği bir maliyet merkezi olarak izler: hangi bellek işlemi ne kadara mal oluyor, hangi retrieval ne kadar sürüyor, hangi özetleme ne kadar token harcıyor. Bu görünürlük, belleği hem akıllı hem ekonomik tutmanın temeli. Ölçmediğiniz maliyet, kontrol edemediğiniz maliyettir. ## Bağlam mühendisliği ile belleğin kesişimi Ajan belleği, daha geniş bir disiplinin — bağlam mühendisliğinin — parçası. Bellek, modele hangi bilginin, hangi anda, hangi sırayla iletileceği kararının bir bileşeni. İyi bir ajan mimarı, belleği izole bir modül olarak değil, bağlam bütçesinin bir parçası olarak düşünür. Bağlam penceresinde yer sınırlı; sistem promptu, araç tanımları, konuşma geçmişi ve getirilen bellek bu sınırlı alanı paylaşır. Bu paylaşımın optimizasyonu bir sanat. Getirilen belleğin çok fazla yer kaplaması, aktif göreve ayrılan alanı daraltır; çok az yer kaplaması ise ajanı bağlamsız bırakır. Denge, göreve göre dinamik olarak ayarlanmalı — basit görevlerde daha az bellek, karmaşık görevlerde daha çok. Belleği bağlam bütçesinin sabit bir kalemi değil, göreve uyarlanan esnek bir bileşen olarak tasarlamak, ajanın hem verimli hem etkili olmasını sağlar. ## Değerlendirmeden üretime: olgunluk yolculuğu Bir ajan bellek sistemini olgunlaştırmak kademeli bir yolculuk. Başlangıçta çoğu ekip belleği sonradan düşünülen bir eklenti olarak ele alır ve sorunlarla karşılaşınca fark eder ki bellek, ajanın kalbindeymiş. Olgunluk yolculuğu genellikle şöyle ilerler: önce naif bir yaklaşım (her şeyi bağlama koy), sonra seçici bellek (önemliyi sakla), sonra çok kapsamlı ve katmanlı mimari, ve nihayetinde ölçülen, izlenen, sürekli iyileştirilen bir bellek katmanı. Bu yolculukta atılacak en önemli adım, belleği baştan birinci sınıf bir mühendislik meselesi olarak görmek. Modeli seçmeye harcadığınız enerjinin en az yarısını bellek mimarisine ayırın; çünkü üretimde ajanınızın güvenilirliğini belirleyen şey, çoğu zaman modelin ham zekâsı değil, doğru bağlamı doğru anda sunabilme yeteneğidir. Bu bakış açısı, ajan projelerinin çoğunun neden başarısız olduğunu ve azınlığın neden başarılı olduğunu açıklıyor. Ajan belleğini doğru kurmak, tek bir kütüphaneyi kurmak ya da tek bir deseni uygulamak değil; ihtiyacınıza göre büyüyen, ölçülen ve sürdürülen bir sistem inşa etmektir. Basit başlayın, her katmanı gerçek ihtiyaç ortaya çıktığında ekleyin, ve en baştan ölçmeye başlayın. Bu disiplinle kurulan bir bellek katmanı, ajanınızı bir demo'dan gerçek dünyada güvenilir bir sisteme dönüştüren asıl fark yaratıcıdır. ## Bellek ve öğrenen ajanlar İleri seviye bir soru, ajanın belleğinden gerçekten "öğrenip öğrenmediği". Klasik bellek, bilgiyi saklar ve getirir; ama öğrenen bir ajan, geçmiş etkileşimlerinden davranışını uyarlar. Örneğin, belirli bir yaklaşımın bir kullanıcı için işe yaramadığını fark eden ajan, gelecekte farklı bir strateji dener. Bu, belleği pasif bir depo olmaktan çıkarıp aktif bir öğrenme mekanizmasına dönüştürür. Bu tür öğrenme, model ağırlıklarını değiştirmeden, yani fine-tuning olmadan gerçekleşebilir — bellek ve bağlam yoluyla. Ajan, "geçmişte şu yaklaşım başarısız oldu" bilgisini belleğinde tutar ve bu bilgiyi gelecekteki kararlarında bağlam olarak kullanır. Bu, "bağlam içi öğrenme"nin (in-context learning) bellek destekli bir uzantısı. Türkiye'deki ekipler için bunun cazip yanı, pahalı fine-tuning olmadan kişiselleşen ve zamanla iyileşen ajanlar kurabilmek. Belleği bir öğrenme aracı olarak tasarlamak, 2026'nın en umut vaat eden ajan mimarisi yönlerinden biri. Sonuç olarak ajan belleği, 2026 yapay zeka mühendisliğinin en belirleyici ama en az konuşulan katmanı. Onu doğru kuran ekip, güvenilir ajanlar üretir; ihmal eden ekip, ne kadar güçlü model kullanırsa kullansın, her turda amnezi geçiren bir sistemle uğraşır. Model gelir geçer; iyi kurulmuş bir bellek katmanı ise ajanınızın kalıcı rekabet avantajıdır. Bu bakışı benimseyen ekipler, rakiplerinin önüne geçer.