Geçen ay, yani 2026 Ocak ortasında, bir ürün demosunu izlerken yine aynı duvara tosladım. Tek model. Tek yanıt. Tek oturum. Ve sonra gerçek hayatın o can sıkıcı kısmı devreye giriyor: müşteri “şunu da yapıyor mu?” diyor, ekip “peki bunu tool ile bağlayınca ne oluyor?” diye soruyor — ve tam orada işin rengi değişiyor, hem de nasıl.
Orijinal yazının ana fikri bence şuydu: demo yapmak kolay, üretim ortamında çalışan bir ajan kurmak ise bambaşka bir hikâye (bu konuda ikircikliyim). Hani vitrinle mutfak arasındaki fark gibi düşünün. Vitrinde her şey pırıl pırıl; mutfakta ise sipariş kağıtları, yarım kalmış işler, paralel akan süreçler ve ufak bir state kaybıyla resmen dağılan akışlar var.
İşte tam da bu noktada devreye giriyor.
Bu yazıyı hazırlarken aklıma 2024 sonbaharında Kadıköy’de yaptığım küçük bir test geldi (bu beni çok şaşırttı). Bir araştırma asistanını üç araçla koşturuyorduk: arama, kullanıcı sorgusu çekme ve özet çıkarma. Kağıt üstünde fena değildi açıkçası. Ama ikinci turda tool sonucu kaybolunca sistem resmen afalladı — ne yapacağını bilemez hale geldi. Yani mesele “model konuşuyor mu?” değil; “model, araçlarla kavga etmeden yola devam edebiliyor mu?” Tamamen farklı bir soru bu.
Demo Biter, Asıl Sınav Burada Başlar
İnsanların çoğu ilk aşamada modeli metin üreten bir kutu sanıyor (evet, doğru duydunuz). Normal tabii; kısa demo senaryolarında her şey (belki yanılıyorum ama) akıyor gibi görünür. Bir soru sorarsınız, cevap gelir. Bir örnek verirsiniz, model onu açar. Sonra bir anda aynı sistemden web araması yapmasını, veri tabanına bakmasını ya da e-posta göndermesini istersiniz… işte tam orada taşlar yerinden oynar, sarsıla sarsıla.
Tool calling dediğimiz şey aslında çok basit: model sana doğrudan cevap vermek yerine “dur bakalım, önce şu fonksiyonu çalıştır” der. Bir tür iş bölümü var yani. Model düşünür, sen dış dünyayla temas eden işi yaparsın, sonra sonucu geri verirsin. Bu kadar. Kulağa basit geliyor ama pratikte zincirin her halkası hassas — birinde bir şey kayarsa domino gibi devrilir.
Bir de stateless meselesi var. İşin can sıkıcı kısmı tam burası. Modelin hafızası yoksa — ya da sen ona her seferinde pek çok geçmişi yeniden taşımazsan — önceki adımlar buhar olur gider. Açık konuşayım: küçük bir botta bu idare eder, geçer. Ama birkaç tool adımı sonrası olay çorba oluyor.
Peki neden?
Ben bunu ilk kez 2025 Mart’ta Beşiktaş’taki bir SaaS ekibinde gördüm. Arka arkaya üç tool çağrısı yapan ajanımız vardı; ilk ikisi tamamdı ama üçüncüde context eksildiği için model sanki ilk kez konuşuyormuş gibi davrandı. Ekipteki arkadaşlardan biri “bu niye unutmuş şimdi?” diye sorduğunda cevabım netti: çünkü state bizdeydi. Biz onu yanlış taşımıştık. Hata sistemde değil, bizde.
Tool Calling Nedir, Neyi Değiştiriyor?
Şimdi bakın: normal sohbet ile tool calling arasındaki farkı market listesiyle anlatayım. Normal sohbet sadece “şunları al” demek gibidir. Tool calling ise listeden domatesi seçip sepete atmak, sonra kasaya yürümek, ödeme yapmak gibi daha işlemli bir şeydir — model sadece konuşmuyor; karar veriyor ve aksiyon istiyor.
Bu yapı özellikle araştırma asistanlarında işe yarıyor. Neden? Çünkü modelin elindeki bilgi yetmeyebilir. Güncel fiyat bakacaksa başka kaynak gerekir; kullanıcı hesabını kontrol edecekse API gerekir; dosya oluşturacaksa farklı bir servis gerekir. Kısacası model zekâsını kullanır ama ellerini sen uzatırsın. Güzel bir iş bölümü aslında, doğru kurulursa. Bu konuyla ilgili Kiro CLI ve ArgoCD MCP: Terminalden GitOps Yönetimi yazımıza da göz atmanızı tavsiye ederim.
Tool calling’in kritik tarafı şu: sonuçların hepsi sırayla geri dönmeli ve hiçbir ara adım kaybolmamalı. Aksi halde ajan “ne yapıyordum ben?” moduna girer.
Neden zorlaşıyor?
Çünkü tek adımlı akışlarda hata alanınız geniştir — ama çok adımlı agent’larda daralır, ciddi biçimde. Bir tool gecikirse bütün plan bozulabilir; iki paralel görevden biri patlarsa diğerinin çıktısı da anlamsızlaşabilir; model farklı versiyonlara geçerse context uyumu yerle bir olabilir (eh, fena değil). Bu ne anlama geliyor? Kulağa küçük geliyor olabilir ama üretimde bayağı can yakıyor, inanın.
Bence en rahatsız edici taraf şu: hata sessizce geliyor. Sistem neredeyse tamamen çökmez. Bazen sadece yanlış cevap verir, bazen eksik veriyle devam eder, bazen de mantıklı görünen ama temeli tamamen boş bir çıktı üretir. İşte hayal kırıklığı tam burada başlıyor — siz her şeyin yolunda gittiğini sanıyorsunuz, oysa gitmemiş.
Saklama Katmanı Olan Sistemlerin Gücü
Raw API’de state yönetimi tamamen sizde olduğu için her round trip ayrı dert. Tool çıktısını tekrar yollamanız gerekir; hangi mesajın hangi adımdan geldiğini takip etmeniz gerekir; paralel thread’leri birbirine karıştırmamanız gerekir. Şey yani, bunlar teoride düzenli durur. Ama pratikte? Log dosyaları uzadıkça uzar, uzadıkça uzar.
| Konu | Stateless Raw API | State Tutan Yapı |
|---|---|---|
| Tool sonucu saklama | Siz yönetirsiniz | Otomatik tutulur |
| Paralel görevler | Zor ve kırılgan | Daha düzenli izlenir |
| Tarihçe taşıma | Tam geçmişi yeniden gönderirsiniz | Sistem halleder |
| Ajan davranışı | Karmaşık workflow’da zorlanır | Daha sürdürülebilir olur |
Küçük startup tarafında bu fark bazen hemen görünmez; kullanım azdır, işler biraz el yordamıyla yürür. Ama enterprise seviyede tablo değişir. Müşteri destek botu, iç arama asistanı ve raporlama ajanı aynı anda çalışıyorsa state’i elle taşımak resmen kumdan kale yapmak gibi olur. Sağlam görünür, bir dokunuşta dağılır.
Benzerini 2025 Ağustos’ta İzmir merkezli orta ölçekli bir fintech projesinde gördüm, isim vermeyeyim. Ekip ilk başta raw endpoint ile ilerledi ve maliyet düşük göründü… ta ki paralel agent sayısı artana kadar (inanın bana). Sonra message replay mantığı yüzünden hem — ki bu tartışılır — bakım arttı hem de debug süresi uzadı. E peki, sonuç ne oldu? Öngöremediler, çoğumuz öngöremeyiz zaten başta. Daha fazla bilgi için SteamGPT Sessizce Geliyor: Valve’ın Yeni AI Hamlesi yazımıza bakabilirsiniz.
Evet, doğru duydunuz.
Kime göre iyi?
Araya gireyim: Yalnızca tek soruluk mini bot yapıyorsanız raw yaklaşım hâlâ iş görebilir. Tamam. Ama çok araçlı araştırma ajanı kuruyorsanız ya da günler boyunca süren görevler planlıyorsanız state yöneten yapı ciddi avantaj sağlıyor. Mesele lüks değil — operasyonel rahatlık.
- Küçük proje için: hızlı başlangıç ve düşük karmaşıklık yeterli olabilir.
- Büyüyen ekip için: audit trail ve tekrar oynatma önemli hale gelir.
- Kritik süreçlerde: tool sonuçlarının kaybolmaması şart olur.
- Uzun soluklu ajanlarda: thread yapısı neredeyse mecburi hale gelir. (bu kritik)
Tasarımda Dikkat Edilecek İnce Ayarlar
Neyse, uzatmayayım — ama sanmayın ki çözüm sadece “bir thread açıp rahatlamak”. Değil tabii! Ara katman doğru kurulmazsa state tutan sistem de saçmalar. Mesela token bütçesi yönetimi önemli; geçmiş büyüdükçe maliyet de şişer, farkında bile olmazsınız. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Pratikte en iyi yaklaşım bana göre şu: kısa vadeli mesajları açık tutup eski adımları özetlemek (buna dikkat edin). Yani modeli ham hafızaya boğmak yerine kontrollü biçimde beslemek gerekiyor. Bu biraz mutfakta tencereyi sürekli ağzına kadar doldurmamaya benziyor — taşarsa kim temizleyecek, değil mi? WhatsApp’ın Kullanıcı Adı Hamlesi: Numara Dönemi Bitiyor mu? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
# Basit akış mantığı
assistant = client.create_assistant(
name="Research Assistant",
system_prompt="Use tools when needed."
)
thread = assistant.start_thread(user_id="123")
thread.send("En güncel güvenlik trendlerini araştır")
# model tool call üretir
# uygulama aracı çalıştırır
# sonuç tekrar thread'e yazılır
# model devam eder
Tuhaf ama, Açıkçası ben burada en büyük kazanımı debug tarafında görüyorum. Hangi adımda ne olmuş görmek kolaylaşıyor; denetim izi çıkıyor; hatalı cevabı geriye sarıp incelemek mümkün oluyor. Eski usulde ise log peşinde koşarken öğlen kahvesi soğuyordu — hatta çoğu zaman ikinci kahve gerekiyordu, yemin ederim.
Peki Eksileri Yok mu?
İşin garibi, Var elbette. Her güzel mimarinin yanında ufak çaplı baş ağrıları da gelir — bu değişmez bir kural gibi. State yöneten yapı daha konforlu olabilir ama soyutlama katmanı yükseldikçe sistemi anlamak zorlaşır. Yeni gelen ekip üyeleri için öğrenme eğrisi biraz dikleşebilir. Biraz değil, bazen epey.
Bir de vendor bağımlılığı konusu var. Bilhassa de platform sizin yerinize tarihçe tutuyorsa dışarı çıkmak daha zahmetli olabilir. Kağıt üstünde süper görünen bazı çözümler pratikte migration sırasında insanı terletiyor. Ben bunu dürüst söyleyeyim — beklediğim kadar temiz değildi. Hiç.
Denge nasıl kurulur?
Bence cevap siyah-beyaz değil. Kritik olmayan işleri sade tutun, ama çok adımlı agent akışlarını state bilen katmana taşıyın. Mesela müşteri destek botu ile iç bilgi asistanını aynı mimariye koymayın; biri hızlı yanıt ister, diğeri uzun zincirli karar ister. İkisine aynı gömlek olmaz.
Sıkça Sorulan Sorular
Tool calling neden bu kadar önemli?
Çünkü AI artık sadece konuşmuyor, işlem de yapıyor. Arama yapmak, veri çekmek da mail göndermek gibi işler ancak tool calling ile düzgün ilerliyor.
Stateless API neden sorun çıkarıyor?
Çok adımlı işlemlerde önceki sonuçları hatırlamadığı için sorun çıkarıyor. Her şeyi yeniden göndermeniz gerekiyor ve bu da karmaşıklığı artırıyor. Küçük işlerde tolere edilir ama büyüyünce can sıkar.
Küçük startup için böyle bir sistem gerekli mi?
Yani, Eğer ürününüz tek aşamalıysa şart değil. Ama ajanın gün içinde birçok araç çağırması gerekiyorsa erken yatırım yapmak ileride çok vakit kazandırır. Ben olsam en azından temel state takibini kurarım.
Büyük ekipler neye dikkat etmeli?
Audit trail, hata ayıklama,paralel task yönetimi ve token maliyeti öncelik olmalı. Ayrıca eski konuşmaları nasıl özetleyeceğinizi baştan planlamanız lazım.
Kaynaklar ve İleri Okuma
Anthropic API Resmi Dokümantasyonu
Anthropic TypeScript SDK GitHub Sayfası
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
