Deep Agents + Cosmos DB: Operasyonel Veride Plan-Eylem-Doğrulama
Birkaç haftadır LangGraph üstünde dolaşan ajan mimarilerine kafa yoruyorum. Açık konuşayım, “tek prompt-tek cevap” devri yavaş yavaş geride kalıyor gibi geliyor bana. Artık mesele, bir LLM’in sırayla düşünüp araç çağırması, çıktıyı okuması, kararını yeniden tartması ve sonra bir araç daha çalıştırması. E peki, sonuç ne öldü? İşte Deep Agents tam bu noktada devreye giriyor — Azure Cosmos DB ile yan yana gelince de işin rengi baya değişiyor.
Lafı dolandırmayayım: Microsoft DevBlogs’ta Abhishek Gupta’nın yayınladığı “Support Ops Agent” örneği — yanı destek bileti kuyruğunu yöneten ajan — pratikte gördüğüm en derli toplu “operasyonel veriyle çalışan ajan” demosu olabilir. Bugün hem bu yapıya dürüst gözle bakacağım hem de Türkiye’deki kurumsal müşterilerde nasıl karşılık bulur, ona değineceğim.
Evet, doğru duydunuz.
Deep Agents Tam Olarak Ne, Neden Önemli?
Klasik bir LangChain ajanını düşünün (bizzat test ettim). Tool çağırıyor, sonucu alıyor, sonraki adımı seçiyor. Güzel. Ama iş uzayınca tablo biraz dağılıyor; context window doluyor, ajan az önce ne yaptığını unutabiliyor, tool çıktıları prompt’u şişiriyor ve en kötüsü de kilit bir veri değişikliği öncesinde “dur bakalım” diyebileceğiniz net bir kapı olmuyor.
Şunu fark ettim: Deep Agents, LangGraph üstüne kurulmuş bir agent harness. Yanı ajanın etrafına geçirilen, ona biraz disiplin veren bir iskelet gibi düşünebilirsiniz. Üç tane işe yarar parçası var:
- Skills: Talimatları prompt’a boca etmek yerine ihtiyaç anında yüklüyor. Token tarafında baya iş görüyor.
- Offload: Büyük tool çıktıları context’i boğmasın diye dışarı taşıyor. (bu kritik)
- Human-in-the-loop onay: Veri değiştirecek bir adımdan önce ajan dürüyor, “bunu yapayım mı?” diye soruyor. — bunu es geçmeyin
Bir de kendi içinde todo listesi tutuyor; küçük gibi dürüyor ama sahada etkisi büyük. Evet. Multi-step iş yapan ajanların 5-6 adımdan sonra “ben neyi çözüyordum?” moduna girdiğini ben de çok gördüm. Bu liste o hafıza kaymasını epey azaltıyor.
Support Ops Agent: Demo Senaryosu
Peki demo ne yapıyor? Bir müşteri destek bileti kuyruğu üzerinde çalışıyor. Şöyle sorular sorabiliyorsunuz:
- Hangi biletler riskli? SLA kaçırma ihtimali olanlar hangileri?”
- Kim şu an fazla yük altında?”
- Son 2 saatte gelen 7 benzer şikayet var; burada outage kokusu var mı?”
- Bu bileti çöz, kapat ve ilgili tarafları logla.” — bunu es geçmeyin
Bilet verisi Azure Cosmos DB for NoSQL’de tutuluyor. Ekip zaten operasyonel veritabanını orada kullanıyor. Ajan da gidip yan tarafta ayrı bir indeks aramıyor; doğrudan canlı veriyle konuşuyor. Bence burada asıl kıymet pek konuşulmuyor: birçok ajan demosunda “önce vektör DB’ye senkronlayalım, sonra oradan okuyalım” yaklaşımı var. Ama destek operasyonu gibi taze verinin kilit olduğu yerlerde ayrı indeks = gecikme = yanlış karar riski demek.
Hangi İstek, Hangi Cosmos Operasyonuna Düşüyor?
Aşağıdaki tablo ajanın yaptığı işleri Cosmos DB tarafındaki karşılığıyla özetliyor (ciddiyim). Bakınca aslında ortada sihir değil, düzgün tool tasarımı olduğunu görüyorsunuz.
| İstek | Ajanın Yaptığı | Cosmos DB Operasyonu |
|---|---|---|
| Kuyruk triyajı | Riskli biletleri bul, gerçekten önemli olanları raporla | Cross-partition query, ORDER BY |
| Bilet çözümü | Point read yap, ilgili biletleri ara, durum/sahip/history güncelle, sonra tekrar oku doğrula | Point read + query + patch + verify read |
| Outage tespiti | Müşteriler arasında benzer sorun kümesi bul, “known issue” etiketi baş | Multi-step query + tekrarlı patch |
| Kuyruk sağlığı | Status, alan ve sorumlu kişi bazında özet çıkar | Aggregation query |
Neden Cosmos DB Bu İşe Yakışıyor?
Bak şimdi, burada atlanmaması gereken birkaç teknik nokta var. Cosmos DB’nın bu senaryoya uymasının üç ana nedeni var:
Şunu söyleyeyim, Birincisi, esnek şema (evet, doğru duydunuz). Ajan bir bilete yeni etiket ekleyebilmeli ya da history dizisine kayıt iliştirebilmeli; yoksa her seferinde ilişkisel tarafta ekstra uğraş çıkıyor. JSON document yapısı sayesinde bu iş çok daha rahat ilerliyor.
Doğrusu, İkincisi, partition key disiplini. Müşteri bazlı sorgular ve point read’ler ucuz kalıyor; yanı “şu müşterinin son 10 bileti” sorusu birkaç RU ile dönebiliyor. Ama dikkat: kuyruk geneline yayılan sorular (“bütün açık high-priority biletler”) cross-partition’a düştüğü için RU faturasını kabartabiliyor. O yüzden ajanın kullandığı tool’lar projection yapıyor; sadece lazım olan alanlar çekiliyor. Daha fazla bilgi için Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor? yazımıza bakabilirsiniz.
Küçük bir detay: Üçüncüsü, patch API. Partial Document Update burada baya kurtarıcı oluyor. Tüm dokümanı okuyup değiştirip geri yazmak yerine sadece değişen alanı patch’liyorsunuz. Hem RU tarafında nefes aldırıyor hem de concurrency açısından daha temiz ilerliyor. Daha fazla bilgi için Kubernetes CVE Kayıt Düzeltmesi: Tarayıcılarınız Şaşıracak yazımıza bakabilirsiniz. Daha fazla bilgi için TypeScript 7.0 RC: Go ile Yeniden Yazıldı, 10 Kat Hızlandı yazımıza bakabilirsiniz.
Ajan dünyasında “doğru veritabanını seçmek” çoğu zaman geçiştiriliyor gibi geliyor bana. Hâlbuki ajanın davranışını en çok şekillendiren şeylerden biri veri katmanı oluyor. Yanlış DB seçimi ajanı yavaşlatıyor, pahalılaştırıyor ve güvenilirlik tarafında da işi zora sokuyor.
Ajanın Kullandığı Tool’lar: Tasarım Felsefesi
İnanın, Burada önemli detay şu: tool’lar geniş kapsamlı değil, amaca özel tasarlanmış durumda. Yanı “execute_query(sql)” gibi her şeyi yapan tek araç yok. Onun yerine şöyle parçalar var:
get_ticket(ticket_id, customer_id)— point read, ucuz.find_at_risk_tickets(threshold_hours)— filtreli cross-partition query.find_related_tickets(customer_id, keywords)— müşteri scope’lu arama.update_ticket_status(ticket_id, status, note)— patch operasyonu.verify_ticket(ticket_id)— değişiklikten sonra tekrar okuyup doğrulama.
Bunun güzel tarafı şu: ajan SQL yazmıyor (ben de ilk duyduğumda şaşırmıştım). Gerçekten SQL yazmaması iyi haber olabilir mi? Bence evet; çünkü prompt injection ile “DROP CONTAINER” gibi saçma sapan bir yere gitme riski azalıyor (tabiî sıfırlanmıyor). Sınırı tool seviyesinde çiziyorsunuz ve ajan o sınır içinde hareket ediyor. Kurumsal güvenlik açısından bu oldukça değerli bir yaklaşım.
Bunu Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü yazımda da başka açıdan ele almıştım — katmanlı tool tasarımı kurumsal ajanlarda boş geçilecek konu değil.
İşte tam da bu noktada devreye giriyor. Bu konuyla ilgili Binlog MCP Server: Build Sorunlarını Copilot’a Çözdürmek yazımıza da göz atmanızı tavsiye ederim.
Verify-After-Write Deseni
Bence örneğin en iyi mühendislik kararı şu: ajan yazdıktan sonra dönüp kontrol ediyor. Yanı alert_ticket_status()-vari bir işlem yaptıysa hemen ardından taggeris verify_ticket()? Yok yok… doğru söyleyeyim: update çağrısından sonra otomatik olarak <verify_ticket>-benzeri okuma geliyor demek istiyorum.
Niye? Çünkü LLM’in “yaptım” demesi yetmiyor ki zaten.
Sahada çok oluyor bu; ajan kendini ikna ediyor ama veri tarafında hiçbir şey değişmemiş olabiliyor — race condition çıkabiliyor, ETag çakışabiliyor ya da RU throttle yüzünden işlem yarıda kalabiliyor.
Verify adımı bu illüzyonu kırıyor.
# Pseudo-code: ajanın iç döngüsü
def resolve_ticket_flow(ticket_id, customer_id):
ticket = get_ticket(ticket_id, customer_id) # point read
related = find_related_tickets(customer_id, ticket.keywords)
# human-in-the-loop: kullanıcıdan onay iste
if requires_approval(ticket):
wait_for_human_approval()
update_ticket_status(ticket_id, "resolved", note) # patch
verified = verify_ticket(ticket_id) # tekrar oku
assert verified.status == "resolved" # gerçekten oldu mu?
return verified
}Peki Günlük Hayatta Nasıl Kullanılır?
Sabah Triyajı
Sız sabah masaya oturunca destek lideri gelip “kuyrukta bana bakman gerekenleri çıkar” diyor ya hani; işte ajan tam orada devreye giriyor.
Önce cross-partition query atıyor (yüksek öncelikli + açık + son N saattir hareket etmemiş biletler), sonra LLM listeyi okuyup gerçekten önemli olan beş tanesini ayıklıyor.
Yanı önce veri erişimi geliyor, ardından yorumlama katmanı devreye giriyor.
Bu ikili yapı kuyruktaki gürültüyü baya azaltıyor.
Durun, bir saniye.
Bilet Çözümü
Evet.
“Şu bileti çöz” dediğiniz anda ajan önce kaydın tam halini okuyor.
Sonra aynı müşterinin geçmiş biletlerine bakıp context kuruyor; böylece “bunu daha önce yaşamışız galiba”” hissi oluşuyor.
Status’u değiştiriyor,history’ye not ekliyor,kapatıyor.
Ardından tekrar okuyup doğruluyor.
Tek bir kullanıcı isteği arka planda 4-5 Cosmos operasyonuna dönüşüyor ama her biri amaç odaklı olduğu için iş görüyor.
Neyse uzatmayayım.
” ChatGPT’de Sağlık Zekası: GPT-5.5 Ne Kadar Güvenli? yazımızda bu konuya da değinmiştik.
Outage Tespiti
Tam da öyle.
“
Aynı anda farklı müşterilerden gelen benzer şikayetleri düşünün — kelimeler farklı olsa bile anlam aynı kalabiliyor (“login olamıyorum”, “auth hatası”, “giriş yapamıyorum”).
Ajan keyword cluster’larını tarayıp ortak paterni yakalarsa bunları topluca “known issue”-vari bir etiketle işaretleyebiliyor.
Böylece destek ekibi elli ayrı bilete tek tek cevap yazmak yerine tek incident üstünden ilerleyebiliyor.
Kısacası gürültü azalıyor.
Production’da bu tip sorguları rate-limit etmek veya continuation token ile sayfalama yapmak iyi fikir olabilir.
Aksi hâlde tek bir “ajanı boş bırak” anı ay sonunda faturayı beklenmedik biçimde büyütebilir.
“>
Türkiye’deki Kurumsal Gerçeklik: Bu Yapı Bize Uyar mı?
Lokal tarafa geçeyim biraz.
Yıllardır bulut göç projelerinde gördüğüm şey şu:
Türkiye’deki kurumlar ajan teknolojisine meraklı. Üç temel kaygıyla yaklaşıyorlar:
“Bizim veri içeride kalsın”, “halüsinasyon olmasın”, “audit trail olsun”.
Deep Agents ile Cosmos DB kombinasyonu bu üç kaygıyı da fena olmayan şekilde adresliyor:
- |Veri yerinde kalmaya devam ediyor| ayrı vektör DB senkronu gerekmiyor | bilet veritabanına doğrudan erişiliyor.|
Sıkça Sorulan Sorular
Deep Agents, LangChain’in yerini mi alıyor?
Hayır, aslında tam tersi. Deep Agents, LangGraph’ın üstüne kurulu bir harness — yanı LangChain ekosisteminin doğal bir uzantısı gibi düşünebilirsiniz. Hani tek seferlik basit ajan işleri için biraz fazla ağır kaçıyor. Çok adımlı, uzun süreli, veri yazma içeren işlerde gerçekten fark yaratıyor.
Cosmos DB yerine PostgreSQL kullansam ne kaybederim?
JSON esnekliği ve global dağıtım kolaylığını kaybedersiniz. PostgreSQL’in JSONB desteği fena değil aslında, ama document-first bir yapı değil. Bir de patch API muadili biraz daha zahmetli oluyor. Yine de küçük ölçekte PostgreSQL pekâlâ yapar bu işi — özellikle ekibiniz SQL’e hâkimse bence makul bir tercih.
Approval gate olmadan production’a çıkmak güvenli mi?
Açıkçası bence değil. En azından can alıcı alanlar için — mesela status değişimi, ticket silme, müşteriye gönderilen mesajlar — human-in-the-loop olmadan canlıya almak ciddi risk taşıyor. LLM halüsinasyonu gerçek bir şey ve tecrübeme göre beklenmedik anlarda karşınıza çıkıyor (bizzat test ettim). Approval gate’i her şeye değil, kritik aksiyonlara akıllıca konumlandırın.
RU maliyeti tahmin edilebilir mi?
Bence, Tam değil, ama yaklaşık bir fikir verebilirim: point read ~1 RU, küçük patch ~10 RU, filtreli cross-partition query işe 50-500 RU arası gidiyor. Ajan başına günlük 1000 etkileşim varsayarsak kabaca 100K-500K RU/gün çıkıyor. Serverless modda bu birkaç dolar/gün ediyor yanı. Provisioned’a geçmeyi düşünüyorsanız autoscale max RU cap’i genelde kullanın — bence bu konuda gevşek davranmamak lazım.
Türkçe destek biletleriyle çalışır mı?
Evet çalışıyor, ama LLM seçimi burada gerçekten önemli. GPT-4 sınıfı modeller Türkçe’de gayet iyi iş çıkarıyor. Hani embedding modeli kullanacaksanız Türkçe’ye uyumlu olmasına dikkat edin — bu noktayı atlamamak lazım. Hani ne farkı var diyorsunuz, değil mi? Keyword arama tarafı zaten Cosmos üzerinde dil bağımsız çalışıyor.
Kaynaklar ve İleri Okuma
Orijinal makale: How to Use Deep Agents with Azure Cosmos DB (Microsoft DevBlogs)
Azure Cosmos DB Partial Document Update (Patch API) Dokümantasyonu
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.
2 comments