Agent Memory Artık Ciddiye Alınmalı: Üretimde Güven, Şeffaflık, Kontrol
Neden “hafıza” konusu bir anda kilit öldü?
Yapay zekâ ajanları ilk çıktığında herkesin aklı hemen aynı yere kaydı: “Konuşsun, hatırlasın, işi çözsün.” Güzel fikir. Hatta ilk bakışta bayağı etkileyici. Ama sahaya inince tablo değişiyor; demo ortamında fena görünmeyen bir ajan, üretimde bazen basit bir prosedürü atlıyor, bazen aynı hatayı üç kez yineliyor, bazen de doğru bilgiyi biliyor ama adımları ters sırayla yapıyor. İşin aslı şu: hafıza dediğimiz şey sadece geçmişi tutmak değil, doğru davranışı sürdürebilmek.
Microsoft’un Foundry Agent Service tarafında anlattığı yeni yaklaşım tam da bu boşluğu hedefliyor. Ben bunu okurken aklıma 2024’te bir finans müşterisinde yaşadığımız olay geldi (şaşırtıcı ama gerçek). İstanbul’da çalışan ekip, çağrı özetleyen bir ajan deniyordu; bilgiler yerindeydi ama onay adımı atlanıyordu. Sonuç? Kağıt üstünde süper görünen sistem pratikte tökezledi. O gün anladım ki agent memory meselesi biraz “not defteri” değil, daha çok alışkanlık meselesi.
Hmm, bunu nasıl anlatsamdı…
Bir de şu var: Kurumsal tarafta güven olmadan hiçbir şey yürümüyor. Küçük bir startup iseniz hızlı deneyip geçersiniz; yanlışsa silersiniz. Ama enterprise dünyasında tek bir yanlış prosedür bile uyum ekibinin kaşını kaldırmaya yetiyor. Yanı hafıza artık tatlı bir özellik değil, üretim şartı (şaşırtıcı ama gerçek)
Bakın, Ben AZ-305 ve AZ-104 hazırlıkları sırasında da hep aynı şeyi düşündüm: mimariyi kurmak kolay, sürdürülebilir davranışı kurmak zor. Ajanlarda da durum farklı değil (ciddiyim). hatta daha çetrefilli.
Procedural memory neyi çözüyor?
Burada en önemli ayrım şu: Faktları hatırlamak başka şey, işi doğru yapmak başka şey. Procedural memory dediğimiz yapı, ajanın “hangi durumda hangi adımı atması gerektiğini” öğrenmesini sağlıyor. Yanı sadece bilgi saklamıyor; iş akışının ritmini de saklıyor gibi düşünün.
Bakın, Geçen sene Eylül 2025’te Logosoft tarafında yürüttüğümüz bir pilot çalışmada (bir perakende grubuyla), destek botu ürün iadesinde doğru politikayı biliyordu. Kontrol listesini karıştırıyordu. Ajanın elindeki veri eksik değildi; eksik olan şey sıralamaydı. Procedural memory bu tip durumlarda ciddi fark yaratabiliyor çünkü başarılı yürüyüş izlerini tekrar kullanıyor.
Bu yaklaşımın en hoş tarafı şu: Ajan her seferinde sıfırdan icat yapmaya çalışmıyor. Daha önce işe yarayan yolu alıp oradan devam ediyor. Bu kulağa küçük geliyor olabilir ama operasyonel tarafta fark bayağı büyük oluyor.
Ajanlar için mesele sadece “neyi biliyor?” sorusu değil; asıl soru “bildiğini hangi sırayla ve hangi kontrol noktalarıyla uyguluyor?”
İki aşamalı çalışma mantığı
Yanı, Önce ajan trajeleri toplanıyor ve inceleniyor. Burada başarılı örüntüler ayrıştırılıyor, gereksiz dolambaçlar ayıklanıyor, eksik adımlar görünür hâle geliyor… sonra bunlar yapılandırılmış procedural memory öğelerine dönüşüyor.
Bu öğeler iki parçalı düşünülüyor gibi:
- Kullanım zamanı: Hangi bağlamda devreye girecek?
- Eylem sırası: Hangi adımlar takip edilecek? (bence en önemlisi)
- Zorunlu kontroller: Hangi doğrulamalar atlanmayacak? — ciddi fark yaratıyor
- Araç kullanımı: Hangi tool hangi parametreyle çağrılacak?
Şunu söyleyeyim, Neyse uzatmayayım; bu aslında insan eğitimine çok benziyor. Yeni gelen çalışana doküman verirsiniz ama yetmez — yanında usta biri birkaç kez nasıl yapılacağını gösterir ya… burada da benzer şekilde sistem kendi iyi pratiklerini taşıyor.
Peki bu üretimde neden önemli?
Kâğıt üstünde çoğu AI demosu iyi görünür çünkü senaryolar kontrollüdür. Ama gerçek hayat kirli işler içerir: yarım kalmış kayıtlar, eksik alanlar, beklenmedik kullanıcı davranışları (kendi tecrübem). Policy çakışmaları… İşte orada prosedürel hafıza devreye giriyor.
Peki neden?
Benim gördüğüm kadarıyla Türkiye’de şirketler genelde önce veri katmanına odaklanıyor; haklılar da çünkü temel orasıdır. Fakat ajan projelerinde asıl sürpriz çoğu zaman veri kalitesinden çok süreç kalitesinde çıkıyor. Bir bankacılık projesinde Şubat 2026’da yaşadığımız hata bunu net gösterdi: model doğru cevabı biliyordu. KYC doğrulama adımı sıra dışı geldiğinde patladı! Çözüm veri eklemek değildi; karar ağacını daha disiplinli hâle getirmekti.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Sadece fakt hafızası | Daha basit yönetim | Süreç tekrarı zayıf kalır |
| Procedural memory | Daha tutarlı icra | Tuning ihtiyacı artar |
| Mecburi manuel guardrail | Kontrol hissi verir | Büyüdükçe yorucu olur |
Açık konuşayım, procedural memory henüz her problem için sihirli değnek değil. Yanlış trajelerden öğrenirse yanlış alışkanlığı büyütür — işte o zaman hayal kırıklığı yaşarsınız! O yüzden audit kısmını ciddiye almak lazım.
Küçük ekip mi büyük kurum mu?
Küçük ekipseniz önce dar kapsamda başlayın: tek süreç seçin, ölçün, sonra genişletin. Mesela ticket sınıflandırma veya iade onayı gibi tekrar eden işler iyi başlangıç olur.
Tuhaf ama, Büyük kurumsanız iş biraz değişiyor; burada rol tabanlı erişim, denetim izi ve TTL ayarları can alıcı hâle geliyor çünkü hafızanın sonsuza kadar şişmesi istemezsiniz (kim ister ki zaten?). Bilhassa regülasyon baskısı olan sektörlerde unutma mekanizması neredeyse hatırlama kadar değerli oluyor.
TLLL… yok yok TTL ve yönetim deneyimi ne getiriyor?
Tamam durun bir dakika — başlıkta az kalsın dil sürçmesi yaptım! Aslında kastettiğim TTL,. Time-to-live özelliği. Bu detay ufak görünür ama üretimde baya bir düşüneyim… işe yarar çünkü bazı anılar sonsuza kadar tutulmamalıdır. Her şeyi saklamak marifet değil; neyi ne kadar süre tutacağını bilmek marifettir.
Bunu Azure Cosmos DB’de partition tasarlarken de çok görürüz aslında: veriyi sadece koymak yetmez, yaşam döngüsünü de düşünmek gerekir. Aynı mantık burada da geçerli. Eğer agent memory katmanı büyüyorsa hem maliyet hem yönetişim baskısı artar.
Neden şeffaflık gerekiyor?
{
"memory_item": "refund_policy_step",
"ttl_days": 30,
"source": "successful_trajectory",
"type": "procedural"
}
İtiraf edeyim, Dikkat edin, burada mesele JSON yazmak değil; mesele operasyona görünürlük kazandırmak (ben de ilk duyduğumda şaşırmıştım). Portal içinde CRUD ile memori öğelerini görmek bence güzel adım,ama hâlâ biraz ham. Birkaç müşteri senaryosunda özellikle toplu arama,etiketleme ve versiyonlama tarafının daha güçlü olmasını isterdim.
Maliyet, risk ve benim saha gözlemim
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo netleşiyor:TL bazında bakınca küçük görünen tüketimler aylık kapanışta can sıkabiliyor. Mesela çok sayıda etkileşim üreten çağrı merkezî,e-ticaret destek botu ya da iç IT yardım masasında maliyet dalga dalga gelir.
E tabi burada alternatif de var. Bütçe sıkışıksa önce procedural memory yerine kural tabanlı guardrail + kısa süreli context cache ile başlayabilirsiniz. Sonra gerçek trafik oluşunca daha sofistike yapıya geçersiniz. Ben açıkçası böyle kademeli ilerlemeyi seviyorum;toplu giriş yapıp sonradan sökmek pahalıya patlıyor.
Ağustos 2025’te Ankara’daki bir kamu yan kuruluşunda benzer tartışmayı yaptık. Ekip “hepsini kaydedelim” diyordu,ben işe “önce işe yarayan yüzde yirmilik kısmı alın” dedim. Sonunda haklı çıkan taraf pek şaşırtıcı olmadı.
Nereden başlamalı？Pratik yol haritası
- Tekrarlayan ve ölçülebilir tek bir görev seçin.
- Başarılı trajeleri toplayıp elle inceleyin.
- Hataları ayrı etiketleyin:eksik kontrol,yanlış araç,sıradaki adımı kaçırma.
- TTL tanımlayın;her şeyi ömür boyu saklamayın.
- İlk hafta performansı pass rate yerine tekrar başarısı ile ölçün.
— bunu es geçmeyin
Bakın şimdi,bu tür projelerde en büyük hata modeli erken yargılamak oluyor. İlk denemede kusursuz beklemeyin. Ben AZ-500 çalışırken bile ilk lab kurulumlarında sürekli ufak sürprizlerle uğraşmıştım;AI ajanlarında da durum farklı değil, hatta daha nazlı diyebilirim.
Bir dakika,şunu da ekleyeyim:Foundry portalındaki yönetim ekranları güzel olsa da gerçek başarı yine gözlemlerden geliyor. Kullanıcıların nerede vazgeçtiğini görebiliyorsanız sorun çözmeye başlamışsınız demektir.
Sıkça Sorulan Sorular
Procedural memory ile klasik bellek arasındaki fark nedir?
Klasik bellek hani bilgiyi saklar; procedural memory işe bir işi nasıl yapacağını (inanın bana). Yanı biri sözlük gibi çalışıyor, diğeri tarif defteri gibi (inanın bana). Aslında bu ayrımı kavrayınca her şey çok daha net oturuyor.
Bu özellik küçük şirketler için de uygun mu?
Evet, ama bence dar kapsamla başlamak şart. Mesela tek bir (söylemesi ayıp) süreci seçip ölçerek ilerliyorsunuz, faydayı çok daha hızlı görürsünüz. Her şeyi aynı anda açmaya kalkarsanız gereksiz bir karmaşa çıkabiliyor, tecrübeme göre bu sık yapılan bir hata.
TTL neden önemli?
Vallahi, Açıkçası eski ya da gereksiz hafızayı sonsuza kadar tutmak hem maliyet hem de uyum açısından ciddi risk yaratıyor. TTL sayesinde belirlediğiniz süre dolunca veri otomatik temizleniyor. Basit ama çok kritik bir detay.
En büyük risk ne?
Yanlış örneklerden öğrenmek. Sistem kötü bir örneği iyi sanırsa davranışı bozuyor; o yüzden audit süreci gerçekten kritik. Bence bu adımı es geçmemek gerekiyor.
Kaynaklar ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
4 comments