Tool Calling, Planning ve Memory: Güvenilir AI Agent Mimarisi Nasıl Kurulur?

AI agent sistemleri üzerine yapılan tartışmaların önemli bir bölümü, kavramın popülerleşme hızına kıyasla mimari derinlik açısından hâlâ yüzeysel kalıyor. Birçok ekip agent kavramını, büyük dil modeline birkaç araç bağlamak ve çok adımlı akış yürütmek olarak yorumluyor. Oysa üretim seviyesinde güvenilir bir agent sistemi kurmak bundan çok daha fazlasını gerektirir. Asıl mesele, modelin araç çağırabilmesi değil; hangi aracı ne zaman, hangi amaçla, hangi güvenlik sınırları içinde ve hangi karar mantığıyla çağıracağını tasarlamaktır.

Bir agent sisteminin güvenilirliği çoğu zaman üç temel katmanda kırılır veya güçlenir: tool calling, planning ve memory. Tool calling agent’ın eylem kapasitesini belirler. Planning, hedefe ulaşmak için yol seçme mantığını oluşturur. Memory ise agent’ın bağlamsal sürekliliğini, önceki adımları, kullanıcı tercihlerini ve ara çıktıları nasıl taşıyacağını belirler. Bu üç katman doğru kurulmadığında agent ya kontrolsüz davranır, ya gereksiz maliyet üretir, ya da çok adımlı görevlerde tutarsız hale gelir.

Kurumsal yapılarda bu sorun daha da büyür. Çünkü burada agent yalnızca cevap veren bir sistem değildir; bazen CRM’i sorgular, bazen bilet açar, bazen kurumsal bilgi tabanından veri çeker, bazen karar desteği sunar, bazen de kullanıcı adına işlem başlatmaya yaklaşır. Bu yüzden güvenilir agent mimarisi, sadece akıllı görünen değil; denetlenebilir, izlenebilir, sınırları tanımlı ve kontrollü hareket eden bir sistem tasarımı gerektirir.

Bu yazıda, tool calling, planning ve memory katmanlarını kurumsal mimari perspektifiyle detaylı biçimde ele alacağım. Amaç; bu kavramları yalnızca teknik terimler olarak değil, üretimde gerçekten çalışan agent sistemlerinin çekirdeği olarak konumlandırmaktır.

Birçok AI agent demosu ilk bakışta etkileyici görünür. Sistem soru sorar, araç çağırır, ara sonuçlar toplar, kullanıcıya akıcı ve ikna edici cevaplar verir. Ancak üretimde karşılaşılan gerçek soru şudur: Bu agent yanlış bir aracı çağırdığında ne olacak? Yetersiz bilgiyle karar verdiğinde ne olacak? Aynı görevi gereksiz yere tekrar ettiğinde ne olacak? Geçmiş bir oturumdan hatalı bilgi taşıdığında ne olacak? Belirsizlik durumunda insana ne zaman duracak?

İşte güvenilirlik tam burada devreye girer. Kurumsal ortamda bir agent sisteminin değeri yalnızca “görevi tamamlamasıyla” değil; görevi güvenli, kontrollü, açıklanabilir ve tekrar edilebilir biçimde tamamlamasıyla ölçülür.

Bu nedenle agent tasarımında hedef maksimum otonomi değil; doğru otonomi seviyesi olmalıdır.

"

Kritik gerçek: Güçlü bir AI agent, her şeyi kendi başına yapan değil; neyi ne zaman kendi başına yapacağını bilen sistemdir.

Bu üç katman birbirinden bağımsız modüller değildir. Aralarında doğrudan nedensel ilişki vardır. Agent bir plan oluştururken hangi araçlara sahip olduğunu bilir. Hangi aracı çağıracağına karar verirken mevcut state ve memory içeriğini kullanır. Araçlardan dönen sonuçlar yeni state üretir, bu state planning mantığını etkiler ve bazı bilgilerin memory’ye yazılıp yazılmayacağını belirler.

Başka bir ifadeyle:

• Planning ne yapılacağını belirler.
• Tool calling nasıl yapılacağını işletir.
• Memory önceki bağlamı ve sürekliliği taşır.

Bu zincirin bir halkası zayıfsa, agent güvenilirliği hızla bozulur. Planning yoksa agent rastgele araç çağırır. Tool calling disiplinsizse plan iyi olsa bile risk büyür. Memory kontrolsüzse geçmiş bağlam yanlış kararlar üretir.

Tool calling, agent’ın harici sistemler, servisler, veri kaynakları veya fonksiyonlarla etkileşime girmesini sağlayan katmandır. Bu araçlar veri çekme, kayıt güncelleme, arama yapma, hesaplama yürütme, iş akışı başlatma veya başka sistemlerden durum sorgulama gibi görevler üstlenebilir.

Bir agent için tool calling yalnızca “ek özellik” değildir. Bu katman sayesinde agent, pasif metin üreticiden aktif görev yürütücüsüne yaklaşır.

Tool Calling’in Tipik Kullanım Alanları

• CRM veya ERP’den kayıt çekmek
• Takvim, e-posta veya ticket sistemiyle etkileşmek
• Bilgi tabanında arama yapmak
• Kurumsal API’lerden durum almak
• Hesaplama, doğrulama veya veri dönüştürme işlemleri yapmak
• Bir işlemi başlatmak, taslak oluşturmak veya öneri üretmek

Tool Calling Neden Risklidir?

Çünkü bu katmanla birlikte sistem artık sadece cevap üretmez; çevre üzerinde etki oluşturmaya başlar. Yanlış araç çağrısı, yanlış sistemde işlem, gereksiz tekrar, kötü niyetli girdiyle suistimal veya yetkisiz erişim gibi riskler doğar. Kurumsal ortamda bu risklerin etkisi metin hatasından çok daha büyüktür.

1. Araç Kataloğu Net Olmalı

Agent’ın hangi araçlara erişebileceği açık ve sınırlı tanımlanmalıdır. Belirsiz veya aşırı geniş tool seti, yanlış seçim ve güvenlik riski üretir.

2. Her Aracın Yetki Alanı Ayrı Düşünülmeli

Tüm araçlar aynı risk seviyesinde değildir. Bilgi okuyan araç ile kayıt güncelleyen aracın kontrol düzeyi aynı olmamalıdır.

3. Tool Kullanımı Politika ile Çerçevelenmeli

Agent hangi durumda aracı çağırabilir, hangi durumda çağırmamalıdır, hangi eşiklerde insana durmalıdır; bunlar prompt içinde değil sistem seviyesinde kural olarak tanımlanmalıdır.

4. Tool Sonuçları Körlemesine Kabul Edilmemeli

Araçtan dönen veri doğrulanmalı, beklenen formatta mı, eksik mi, çelişkili mi bakılmalıdır. Tool sonucu da yeni hata kaynağı olabilir.

5. Side-Effect İçeren Araçlar İçin Ek Kontrol Gerekir

Öneri üretmek başka, işlem yaratmak başkadır. Kayıt açma, güncelleme, silme, ödeme başlatma veya kullanıcıya dış iletişim gönderme gibi aksiyonlar daha sıkı kontrol gerektirir.

Planning, agent’ın bir hedefe ulaşmak için hangi adımları izleyeceğini belirleme mantığıdır. Ancak burada da kavramsal netlik önemlidir. Planning her zaman uzun ve karmaşık planlar üretmek anlamına gelmez. Bazen sadece doğru sırada üç araç çağırmak da planning’dir. Bazen de agent’ın önce bilgi toplaması, sonra doğrulaması, sonra karar üretmesi gerekir. Önemli olan, planlamanın hedefe bağlı ve kontrollü ilerlemesidir.

Planning Ne Tür Soruları Cevaplar?

• Bu görevi tamamlamak için kaç adım gerekiyor?
• Önce hangi bilgiyi toplamalıyım?
• Hangi araçları hangi sırada kullanmalıyım?
• Eksik bilgi varsa kullanıcıya soru sormalı mıyım?
• Başarısız olan adım sonrası alternatif yol var mı?

Her Agent Karmaşık Planning Gerektirir mi?

Hayır. Bu en sık yapılan hatalardan biridir. Planning ihtiyacı problem yapısına göre belirlenmelidir. Sabit kurallı, dar kapsamlı süreçlerde karmaşık planlama sadece ek gecikme ve ek hata yüzeyi üretir. Dinamik, çok araçlı, belirsizlik içeren görevlerde ise planning kritik hale gelir.

Kural Tabanlı Planning

Belirli görev tipleri için önceden tanımlı yol haritaları vardır. Esneklik sınırlıdır ama güvenilirlik yüksektir. Birçok kurumsal kullanım senaryosunda ilk tercih bu olur.

LLM Destekli Dynamic Planning

Agent, görev bağlamına göre hangi adımların gerektiğini kendisi önerir. Daha esnektir; ancak gözlemlenebilirlik, kontrol ve tutarlılık ihtiyacı artar.

Plan + Doğrulama Katmanı

Plan agent tarafından üretilir ama ikinci bir kural veya doğrulama katmanı tarafından kontrol edilir. Üretim kalitesi için çoğu zaman en dengeli yaklaşımlardan biridir.

Hierarchical Planning

Üst düzey hedef, alt görevlere ayrılır. Özellikle geniş ve çok adımlı use-case’lerde kullanışlıdır; ancak gereksiz kullanılırsa karmaşıklık hızla büyür.

1. Hedefi Daralt

Belirsiz hedefler belirsiz plan üretir. “Süreci yönet” gibi hedefler yerine, sınırları net görev tanımı yapılmalıdır.

2. Maksimum Adım Sayısını Sınırla

Sonsuz döngü, tekrar eden planlar veya gereksiz araç çağrıları engellenmelidir. Agent’ın ne kadar derine gidebileceği tanımlanmalıdır.

3. Başarısızlık Sonrası Davranışı Tanımla

Araç başarısızsa tekrar mı deneyecek, alternatif mi seçecek, kullanıcıya mı soracak, insana mı eskale edecek? Bunlar tasarım seviyesinde net olmalıdır.

4. Belirsizliği Cezalandırma, Yönlendir

Agent’ın emin olmadığı durumda tahmin yürütmek yerine bilgi istemesi veya insana durması daha güvenli olabilir.

5. Planı İzlenebilir Kıl

Planning mantığı kara kutu haline gelirse, agent neden belirli bir yolu seçti anlaşılmaz. Özellikle kurumsal sistemlerde plan izi tutulmalıdır.

Memory, agent’ın önceki etkileşimlerden, aynı görev içindeki ara adımlardan, kullanıcı tercihlerinden veya sistem içi bağlamdan yararlanmasını sağlayan yapıdır. Ancak memory çoğu zaman aşırı basitleştirilir. “Sohbet geçmişi tutmak” memory’nin yalnızca küçük bir parçasıdır.

Güvenilir bir agent için memory şu tür bilgileri taşıyabilir:

• Mevcut görevde toplanan ara bilgiler
• Kullanıcının bu görev için verdiği kısıtlar
• Daha önce çağrılan araçların sonuç özetleri
• Kullanıcının kalıcı tercihleri
• Tekrar eden süreçlerde faydalı olan kalıcı bağlamlar

Memory Neden Faydalıdır?

Çünkü çok adımlı görevler tek seferlik yanıt mantığıyla yönetilemez. Agent, hangi bilgiyi topladığını, hangi aracın ne döndürdüğünü ve hangi kararların alındığını hatırlayabilmelidir. Aksi halde aynı işi tekrar eder, bağlamı kaybeder ve kullanıcıyı yorar.

Memory Neden Risklidir?

Yanlış veya eski bilginin taşınması, kullanıcılar arası veri sızıntısı, hassas verinin gereksiz saklanması, gereksiz kalıcılık ve bağlam kirliliği memory kaynaklı temel risklerdir. Kurumsal yapılarda memory disiplinsiz bırakılırsa güvenlik ve doğruluk problemi büyür.

Short-Term Memory

Tek bir görev veya oturum içindeki geçici bağlamı taşır. En güvenli ve en çok kullanılan memory türüdür.

Session Memory

Aynı kullanıcı oturumu içindeki sürekliliği korur. Uzayan etkileşimlerde tekrar soruları azaltır.

Long-Term Memory

Kullanıcının tekrar eden tercihleri, kalıcı bağlamları veya zaman içinde anlamlı hale gelen örüntüleri taşır. En dikkatli yönetilmesi gereken memory türüdür.

Task Memory

Belirli bir işin tamamlanması sürecinde oluşan state ve ara kararları saklar. Agentik sistemlerde çoğu zaman kritik önemdedir.

1. Her Şeyi Hatırlamaya Çalışma

Memory, maksimum veri biriktirme alanı değildir. Sadece gerçekten görev kalitesine katkı sağlayacak bilgiler tutulmalıdır.

2. Kalıcılık Sınırlarını Belirle

Hangi bilgi ne kadar süre tutulacak, hangi koşulda silinecek, hangisi session ile sınırlı kalacak; bunlar net olmalıdır.

3. Hassas Veriyi Ayrıştır

Kişisel veri, finansal bilgi, sağlık verisi veya kurumsal gizli içerik memory’de kontrolsüz tutulmamalıdır.

4. Memory’yi Kaynak Değil Destek Katmanı Gibi Kullan

Memory, doğrulanmamış kesin bilgi deposu olmamalıdır. Özellikle kritik senaryolarda kalıcı memory ile canlı bilgi kaynakları karıştırılmamalıdır.

5. Yanlış Hafızayı Temizleme Mekanizması Kur

Agent yanlış bir ara bilgi sakladıysa bunun nasıl düzeltileceği veya geçersiz kılınacağı tasarlanmalıdır.

Tool calling, planning ve memory birlikte çalışırken hepsinin ortak zemini state management olur. State, agent’ın hangi aşamada olduğunu, hangi araçların çağrıldığını, hangi sonuçların döndüğünü, hangi belirsizliklerin kaldığını ve hangi kararların alındığını taşır.

İyi state management şu problemleri çözer:

• Tekrar eden araç çağrılarını azaltır
• Agent’ın süreç içinde nerede olduğunu görünür kılar
• İnsan eskalasyonu sırasında bağlamı korur
• Observability ve audit için iz bırakır
• Planning ile execution arasındaki bağlantıyı netleştirir

State yönetimi zayıf olduğunda agent sistemleri “unutkan ama iddialı” hale gelir. Bu da kurumsal güveni hızla bozar.

Güvenilir agent mimarisi, her şeyi otonom hale getirmeye çalışmaz. Tam tersine, hangi kararların insana bırakılması gerektiğini baştan tanımlar. Tool calling, planning ve memory katmanları ne kadar iyi olursa olsun bazı kararlar doğası gereği insan denetimi gerektirir.

Özellikle şu tür durumlarda human-in-the-loop kritikleşir:

• Dış müşteriye giden metinler
• Finansal işlem veya onaylar
• Hukuki veya uyum riski taşıyan aksiyonlar
• Kayıt silme veya güncelleme gibi geri dönüşü zor işlemler
• Belirsizlik seviyesi yüksek kararlar

Güvenilir mimaride insana eskalasyon “başarısızlık” değil, bilinçli kontrol mekanizmasıdır.

Bu tür agent mimarilerinde gözlemlenebilirlik klasik chatbot sistemlerinden çok daha kritik hale gelir. Çünkü hata yalnızca yanlış cevap değildir. Hata, yanlış plan, gereksiz tool çağrısı, eski memory kullanımı, gereksiz tekrar, eksik eskalasyon veya yanlış state geçişi de olabilir.

İyi bir observability katmanı en az şu sorulara cevap verebilmelidir:

• Agent hedefi nasıl yorumladı?
• Hangi planı oluşturdu?
• Hangi araçları hangi sırayla çağırdı?
• Araç sonuçları ne döndürdü?
• Hangi bilgi memory’ye yazıldı?
• Hangi noktada insana eskale etti ya da etmedi?
• Toplam latency ve maliyet nasıl oluştu?

Observability olmadan agent sistemleri etkileyici ama açıklanamaz hale gelir. Kurumsal dünyada bu, sürdürülebilir olmayan bir durumdur.

Agent sistemlerinde başarıyı yalnızca “görevi tamamladı mı?” sorusuyla ölçmek yetersizdir. Çünkü görev tamamlanmış görünse bile izlenen yol yanlış, pahalı, riskli veya denetimsiz olabilir. Bu nedenle evaluation hem sonuç hem süreç odaklı yapılmalıdır.

Ölçülmesi gereken temel boyutlar şunlardır:

• Task completion rate
• Tool selection accuracy
• Planning correctness
• Recovery from failure
• Memory usefulness ve error rate
• Escalation correctness
• Latency ve cost
• Security / policy compliance
• Human override frequency

Bu ölçümler yapılmadan agent sistemi yalnızca gösteri düzeyinde kalır; üretim kalitesi ise görünmez olur.

Tool calling, planning ve memory katmanları bir araya geldiğinde güvenlik yüzeyi büyür. Agent artık yalnızca cevap vermez; veri toplar, karar alır, araç kullanır, bağlam saklar ve bazen aksiyon üretir. Bu da governance gereksinimini klasik LLM uygulamalarına göre çok daha kritik hale getirir.

Bu nedenle şu başlıklar baştan tasarlanmalıdır:

• Araç erişim yetkileri
• Aksiyon bazlı onay seviyeleri
• Memory saklama politikaları
• Audit trail
• Risk sınıflandırması
• Rollback ve incident yönetimi
• Prompt injection ve kötü niyetli tool yönlendirmelerine karşı koruma

Kurumsal agent sistemlerinde güvenlik, sonradan eklenecek katman değil; temel mimari karardır.

1. İç Operasyon Agent’ı

Çalışan talebini anlayan, gerekli sistemlerden bilgi toplayan, uygun aracı seçen ve kritik durumlarda insana duran yapı.

2. Destek ve Teşhis Agent’ı

Kullanıcı sorunu için bilgi tabanını, log sistemini ve ticket geçmişini birlikte değerlendiren; çözüm öneren veya eskale eden agent mimarisi.

3. Seyahat ve Uyum Agent’ı

Seyahat talebini, bütçe, politika, onay akışı ve rezervasyon araçlarıyla birlikte yöneten sistem.

4. Analiz ve Karar Destek Agent’ı

Veri çekme, özetleme, anomali açıklama, rapor hazırlama ve karar notu taslağı üretme gibi çok adımlı akışları yürüten agent yapısı.

1. Agent gerekmeyen probleme agent kurmak
2. Tool setini aşırı geniş bırakmak
3. Riskli araçlarla risksiz araçları aynı seviyede değerlendirmek
4. Planning ihtiyacını abartmak veya yok saymak
5. State yönetimini ihmal etmek
6. Memory’yi sınırsız ve kontrolsüz kullanmak
7. Human-in-the-loop tasarımını sona bırakmak
8. Observability olmadan canlıya çıkmak
9. Evaluation’ı yalnızca görev başarısına indirgemek
10. Security ve governance katmanını prompt içinde çözmeye çalışmak
11. Escalation mantığını net tanımlamamak
12. Agent davranışını tekrarlanabilir ve denetlenebilir hale getirmemek

İlk 30 Gün: Problemi ve Sınırları Tanımla

• Use-case’i netleştir
• Agent gerekip gerekmediğini doğrula
• Tool setini ve risk seviyelerini sınıflandır
• İlk state ve memory sınırlarını tanımla

31-60 Gün: Kontrollü Agent Akışını Kur

• Planning mantığını basit ama izlenebilir şekilde tasarla
• Tool calling kurallarını sistem seviyesinde tanımla
• Memory yazma ve silme ilkelerini belirle
• Human approval noktalarını yerleştir

61-90 Gün: Üretim Disiplini Kur

• Observability ve execution trace yapısını kur
• Evaluation benchmark’ını oluştur
• Security ve governance kurallarını devreye al
• İlk referans güvenilir agent mimarisini kurum standardı haline getir

Tool calling, planning ve memory; agent sistemlerinin en güçlü ama aynı zamanda en riskli katmanlarıdır. Bu katmanlar sayesinde agent statik otomasyondan çıkar, hedefe yönelik çok adımlı sistem davranışına yaklaşır. Ancak gerçek kurumsal değer, bu davranışın ne kadar “akıllı” göründüğünden çok, ne kadar kontrollü, izlenebilir ve güvenli olduğuyla belirlenir.

Bu nedenle güvenilir AI agent mimarisi kurmak, yalnızca LLM’e araç vermek değildir. Hangi aracın ne zaman çağrılacağı, hangi planın kabul edilebilir olduğu, hangi bilginin ne kadar hatırlanacağı, ne zaman insana durulacağı ve tüm bunların nasıl ölçüleceği birlikte tasarlanmalıdır. Uzun vadede güven kazanan agent sistemleri, en otonom olanlar değil; otonomiyi en doğru sınırlarla kullanan sistemler olacaktır.

Tool calling olan her sistem agent midir?

Hayır. Tool calling, agentic sistemlerin önemli bir bileşenidir ama tek başına yeterli değildir. Hedef odaklı çok adımlı ilerleme, karar mantığı ve state yönetimi de genellikle gerekir.

Planning olmadan agent kurulabilir mi?

Evet, bazı dar ve sabit use-case’lerde çok sınırlı planning ile çalışılabilir. Ancak görev dinamikleştikçe planning katmanı daha önemli hale gelir.

Memory şart mı?

Her zaman değil. Tek adımlı veya dar akışlarda gerekmeyebilir. Ancak çok adımlı görev, kullanıcı tercihi veya süreç sürekliliği varsa memory ciddi değer yaratır.

Human-in-the-loop agent başarısızlığı mı gösterir?

Hayır. Kurumsal yapılarda bu çoğu zaman bilinçli güvenlik ve kalite tasarımıdır. Özellikle riskli aksiyonlarda doğru yaklaşımdır.

En kritik katman hangisi?

Tek bir katman seçmek doğru değildir. Ancak tool calling kontrolü, state yönetimi, human approval ve observability çoğu zaman güvenilirliğin omurgasını oluşturur.