Agent'ınızın Bir Yuvaya İhtiyacı Var: Memory, State ve Governance Verinin Yanında

Tipik bir üretim Agent'ında tek bir kullanıcı isteği şu yolu izler: Redis'ten son 20 mesaj okunur, vector database'den 5 doküman parçası getirilir, ayrı bir memory servisinden kullanıcı tercihleri çekilir, sonuç bir gözlem aracına yazılır, yetki kontrolü de uygulama kodunda yapılır. Beş sistem, beş bağlantı havuzu, beş ayrı kimlik ve yedekleme politikası.

Asıl sorun gecikmeden çok tutarsızlık. Müşteri kaydı ana veritabanında güncellenir ama embedding kopyası bir gün geride kalır; Agent eski adresle cevap verir. Yetki ana sistemde geri alınır ama vector index'te o dokümanın kopyası durur. MIT NANDA'nın 2025 raporu, kurumsal GenAI pilotlarının yaklaşık yüzde 95'inin ölçülebilir getiri üretmediğini ve temel nedenin sistemlerin geri bildirimi tutamaması, bağlama uyum sağlayamaması olduğunu söylüyordu. Bu bir 'learning gap'; altında çoğu zaman Agent'ın kalıcı, tutarlı ve yetkiyle korunan bir hafızasının olmaması yatıyor.

Son on iki ayda veri platformları Agent'ı birinci sınıf kullanıcı olarak ele almaya başladı. Databricks, 2025'te satın aldığı Neon teknolojisi üzerine kurulu Lakebase'i 3 Şubat 2026'da AWS'de genel kullanıma açtı; Şubat 2026'da yayımladığı rapora göre platformdaki veritabanlarının yüzde 80'ini, branch'lerin yüzde 97'sini artık Agent'lar oluşturuyor (şirketin kendi verisi). Snowflake, Crunchy Data satın alımının ardından Snowflake Postgres'i 24 Şubat 2026'da GA yaptı. Tiger Data Aralık 2025'te zero-copy fork, MCP sunucusu ve BM25 araması içeren 'Agentic Postgres'i duyurdu. EDB 23 Haziran 2026'da 200'den fazla metriği izleyip politikaya göre değişiklik uygulayan bir 'agentic database' ile Postgres rolleri ve RLS üzerinden Agent erişimi denetleyen bir governance özelliğini (preview) açıkladı. Oracle AI Database 26ai Ekim 2025'te Agent iş akışlarını veritabanının içine taşıyan bir sürüm olarak çıktı.

Güvenlik tarafında Temmuz 2025'teki Supabase MCP gösterimi hâlâ referans vaka: RLS'i atlayan bir rolle çalışan asistan, bir destek talebine gömülü talimatla gizli tabloyu dışarı sızdırdı.

'Ev' metaforunu somutlaştırmak için Agent'ın kalıcı tutması gereken dört şeyi ayırmak gerekiyor. State: çalışmakta olan görevin anlık görüntüsü; hangi adımdayız, hangi Tool Call bekliyor, insan onayı geldi mi. LangGraph bunu thread bazlı checkpointer ile tutuyor ve production için PostgresSaver öneriyor. Memory: thread'ler arasında yaşayan bilgi; kullanıcının tercihi, önceki kararlar, öğrenilmiş kısa notlar. Knowledge: RAG için dokümanlar ve embedding'ler. Audit: Agent'ın kim adına, hangi amaçla, hangi veriye eriştiğinin kaydı.

MemGPT (2023) bu ayrımı işletim sistemi benzetmesiyle kurdu: Context Window hızlı bellek, kalıcı depo yavaş bellek, Agent ikisi arasında veri taşıyor. Mem0 makalesi (2025) seçici uzun dönem hafızanın tüm geçmişi Context Window'a basmaya göre token maliyetini yüzde 90'dan fazla düşürdüğünü raporladı. Ortak çıkarım: hafıza bir depolama problemi, depolama problemleri de onlarca yıldır veritabanlarında çözülüyor.

Agent hafızasını operasyonel veritabanına koymanın üç somut kazancı var. Birincisi atomiklik: Agent bir siparişi güncelleyip aynı anda hafızasına 'müşteri iade istedi' notunu yazıyorsa ikisi aynı transaction'da ya birlikte olur ya hiç olmaz. Ayrı sistemlerde biri yazılır, diğeri yarıda kalır.

İkincisi birleşik sorgu: pgvector ile embedding benzerliği, müşterinin segmenti, sözleşme tarihi ve kullanıcının yetkisi tek SQL sorgusunda filtrelenir. Ayrı vector database'de önce 50 sonuç getirip sonra uygulamada yetkiye göre elemek hem yavaş hem de yetkisiz verinin bir an için belleğe girmesi demek.

Üçüncüsü yetki ve kayıt zaten orada: rol, row-level security, audit log, yedekleme, şifreleme, replikasyon. Ekip bunları Agent için yeniden icat etmez. Anti-pattern: Agent'a 'kolay olsun' diye tek bir süper kullanıcı bağlantısı verip yetkiyi prompt'a yazmak. Prompt yetki değildir; veritabanı rolü yetkidir.

Temmuz 2025'teki Supabase MCP gösterimi problemi tek örnekte özetliyor. Geliştiricinin asistanı veritabanına RLS'i atlayan `service_role` ile bağlıydı. Saldırgan bir destek talebine gizli talimat yazdı; asistan talebi okurken talimatı uyguladı, gizli token tablosunu okuyup cevabı talebin içine yazdı. Teknik olarak hiçbir izin ihlal edilmedi, çünkü rol her şeye izinliydi. Bu, Simon Willison'ın 'lethal trifecta' dediği üçlü: özel veriye erişim, güvenilmeyen içerik, dışarıya veri yazabilme.

Veritabanını Agent'ın evi yapmanın güvenlik karşılığı şu kurallar: her Agent için ayrı, dar bir rol; okuma işleri için read replica; hassas tablolar o role hiç görünmez; yazma gereken her işlem ya ayrı bir Tool ya da insan onayı arkasında. PlanetScale'in Temmuz 2026'da MCP sunucusuna eklediği özellik iyi bir örnek: okumalar varsayılan olarak replikaya gidiyor ve RLS satırları gizliyorsa Agent'a 'boş sonuç politika yüzünden olabilir' uyarısı dönüyor.

Agent'lar şema migration'ı, veri düzeltme betiği ya da sorgu optimizasyonu önerdiğinde riskli olan kısım bunu nerede denedikleri. Temmuz 2025'te Replit'in kodlama Agent'ı, kod dondurma talimatına rağmen bir kullanıcının üretim veritabanını sildi ve vaka sektörde uyarı örneğine dönüştü. Çözüm olarak copy-on-write branching yaygınlaştı: üretim verisinin kopyası saniyeler içinde, depolama paylaşılarak açılıyor; Agent orada çalışıyor, sonuç beğenilmezse branch atılıyor.

Databricks'in Şubat 2026 verisinde branch'lerin yüzde 97'sini Agent'ların açtığı iddiası, bu kullanımın ne kadar hızlı yerleştiğini gösteriyor. Tiger Data'nın Agentic Postgres'i ve Neon tabanlı Lakebase bu modeli ürünün merkezine koyuyor. Pratik kural: Agent'ın üretim primary'sine yazma yetkisi olmasın; branch'te çalışsın, fark (diff) insan tarafından incelensin, migration normal deploy hattından geçsin. Bankacılıkta burada ek bir dikkat var: üretim kopyası kişisel veri taşır, branch'ler de maskeleme ve erişim kurallarına tabi olmalı.

Bu iki sektörde 'Agent'ın evi neresi' sorusu önce hukuki bir soru. BDDK'nın 2020 tarihli Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Yönetmeliği bankaların birincil ve ikincil sistemlerini yurt içinde tutmasını şart koşuyor; kamu tarafında 2019/12 sayılı Cumhurbaşkanlığı Genelgesi kamu verilerinin, kurumun kendi sistemleri ve kontrolündeki yerli sağlayıcılar dışında, bulut depolama hizmetlerinde saklanmamasını istiyor. Hafızasını yurt dışındaki bir SaaS memory servisinde tutan Agent bu çerçeveye baştan takılır.

Haziran 2026'da basına yansıyan, henüz resmi olmayan BDDK yapay zekâ düzenlemesi taslağının başlıkları açıklanabilirlik, insan onayı, model riski ve teknolojik bağımsızlık. KVKK'nın Kasım 2025'te yayımladığı üretken yapay zekâ rehberi de veri sorumlusu rolünü ve insan doğrulamasını vurguluyor. Senaryo: kredi başvurusu ön inceleme Agent'ı. Hafızası ve state'i bankanın kendi Postgres kümesinde, her sorgusu Agent'a özel bir rol ve RLS ile kısıtlı, her erişim audit tablosunda. Denetçi 'Agent bu kararı hangi veriyle verdi' diye sorduğunda cevap bir SQL sorgusu uzaklıkta.

Tezin karşı tarafı da güçlü. Yüz milyonlarca vektör, yüksek QPS ve düşük gecikme isteyen bir arama yükü operasyonel veritabanını yorabilir; OLTP işlemleriyle aynı makinede yarışan vektör sorguları müşteri işlemlerini yavaşlatır. Bu yüzden 'ev' tek bir instance değil, aynı veri modelini ve yetki kurallarını paylaşan bir aile olmalı: primary'de state ve transaction, replica'da okuma ve retrieval, gerekirse analitik için ayrı bir kopya.

İkinci sınır satıcı bağımlılığı. 'Agentic database' etiketli özelliklerin çoğu (otomatik tuning, amaç beyanlı erişim, Agent memory API'leri) ürüne özgü ve 2026'da hâlâ preview aşamasında. Taşınabilir olan kısım açık Postgres'in kendisi: roller, RLS, pgvector, transaction. Karar kuralı: hafıza ve state için standart Postgres özelliklerini kullanın, ürün özgü katmanı ancak ölçtüğünüz bir kazanç varsa ekleyin. Gartner'ın 2025 öngörüsüne göre Agent projelerinin yüzde 40'tan fazlası maliyet, belirsiz değer ve zayıf risk kontrolü yüzünden 2027 sonuna kadar iptal edilecek; yeni bir sistem eklemek bu üç riskin üçünü de artırır.