Handoff Orchestration: Ajanlar Topu Nasıl Devrediyor?
Bir çağrıyı kim taşıyacak?
İşin aslı şu: çok ajanlı sistemlerde ilk kurduğunuz şey çoğu zaman oldukça basit oluyor. Bir router ajan geliyor, kullanıcı isteğini kokluyor, “bu iş şuna gider” deyip topu başka bir uzmana atıyor (şaşırtıcı ama gerçek). Küçük demo’da bu model fena çalışmıyor. Hatta bayağı iş görüyor, açık konuşayım.
📋 İçindekiler
- Bir çağrıyı kim taşıyacak?
- Neden düz pipeline yetmiyor?
- Handoff nasıl çalışıyor?
- Nerede parlıyor, nerede biraz ham kalıyor?
- Pratikte nasıl yaklaşırım?
- Bence Türkiye’de kullanım şekli biraz farklı olacak
- Ekiplerin yaptığı tipik hata ne?
- Sizin için kısa karar rehberi
?>Eğer hızlıca karar vermek istiyorsanız şöyle düşünün:– Tek geçişli işler için klasik router yeterli.
– Konuşma sırasında soru sorma gerekiyorsa handoff daha uygundur.
– Regülasyonlu sektördeyseniz log. Guardrail olmadan başlamayın.
– Bütçe düşükse az sayıda agent ile pilot yapın.”Bir de dürüst olayım:
bazı senaryolarda geleneksel workflow engine hâlâ daha iyi seçim olabilir.
Her problemi LLM agent ile çözmeye çalışmak moda diye yapılacak iş değil.” - Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Gel gelelim, gerçek hayat öyle düz çizgi değil. Bir müşteri daha fazla bilgi ister, uzmanlardan biri ortada kalır ya da akışın yarısında anlarsınız ki istek bambaşka bir yere ait; işte tam orada klasik router modeli tökezliyor. Ben bunu ilk kez 2024 sonbaharında İstanbul’da bir finans müşterisinde gördüm; tek geçişli yönlendirme yetmedi ve ekip resmen “şimdi ne olacak?” diye birbirine baktı.
Microsoft Agent Framework içindeki Handoff Orchestration tam bu boşluğu dolduruyor. Mantık şu: geliştirici ajanları ve aralarındaki yönlü bağlantıları tanımlıyor, framework de her ajana uygun handoff araçlarını ekliyor. Yanı karar verme — en azından ben öyle düşünüyorum — kısmı modelde kalıyor; sınırlar, topoloji ve güvenlik çerçevesi sizde. Bence bu yaklaşımın en hoş tarafı da bu zaten: esneklik var ama kafaya göre saçmalama yok.
Neden düz pipeline yetmiyor?
Klasik pipeline’lar düzenlidir. Hatta bazen fazla düzenli olur. Bir görev başlar, sırayla ilerler, biter… ama kullanıcı sorusu çoğu zaman böyle tertemiz akmaz. Mesela 2025 Mart’ında Ankara’daki bir e-ticaret projesinde gördüğüm şey tam buydu: iade talebi önce destek ajanına gitti, sonra muhasebe detayı gerekti, sonra tekrar destek tarafına dönmek zorunda kaldı. Sabit sıra? Yok öyle bir dünya.
Handoff burada daha doğal dürüyor çünkü konuşma ortasında sahiplik değişebiliyor. Bir ajan “benim işim burada bitmedi” deyip başka uzmana bırakabiliyor ya da “durun bir dakika, bu aslında refund konusu” diye rotayı düzeltiyor. Bu bana Azure mimarisinde event-driven düşünmeyi hatırlatıyor; olay nerede oluşuyorsa işlem de oraya yakın olmalı,. Işin ruhu biraz bu.
Ve işler burada ilginçleşiyor.
Bir de back-edge meselesi var. Bazı işler ileri gitmekten çok geri dönmeyi gerektiriyor. Araştırma lazım oluyor, insan onayı gerekiyor veya eksik veri çıkıyor… Handoff modeli bunları doğal karşılıyor. Sız ne dersiniz? Açık konuşayım: her şeyi tek bir mega-agent ile çözmeye çalışmak çoğu zaman gösterişli ama yorucu oluyor.
Küçük ekip mi, kurumsal yapı mı?
Eh, Küçük startup ekibindeyseniz handoff’u çok katmanlı kurmayın derim; iki ya da üç uzman ajan yeterli olur. Fazlası kafa karıştırır, test yükünü artırır ve debug ederken insanın canını sıkar.
Büyük kurumsal tarafta işe durum farklı (ki bu çoğu kişinin gözünden kaçıyor). Banka, telekom ya da kamu gibi yapılarda görev ayrımı net olmak zorunda; burada handoff graph size hem kontrol hem denetlenebilirlik veriyor. Logosoft’ta 2024 yazında benzer bir senaryoda bunu tartıştığımızda güvenlik ekibi özellikle “kim kime neyi devretti?” sorusuna odaklanmıştı.
Handoff nasıl çalışıyor?
Mantığı sade anlatayım: Sız agent graph’ını tanımlıyorsunuz, framework her çıkış kenarı için sahte ama kontrollü bir handoff tool üretiyor. Ajan o tool’u çağırınca kontrol diğer ajana geçiyor; yanı routing kararı prompt içinde gömülü kalmıyor ama tamamen geliştiricinin elinden de çıkmıyor. Microsoft Agent Framework ve AGT: Ajanları Üretimde Güvende Tutmak yazımızda bu konuya da değinmiştik. Azure Functions’ta Retry Fırtınasını Durdurmak: Backoff ve Circuit Breaker yazımızda bu konuya da değinmiştik.
Hmm, bunu nasıl anlatsamdı… Bu konuyla ilgili Segment Heap: Visual Studio’da C++ Belleği Neden Değişti? yazımıza da göz atmanızı tavsiye ederim.
Bunu trafik ışığı gibi düşünün ama biraz daha akıllı… Işıkların nerede olacağı belli, fakat hangi araç hangi şeride girecek kararını sürücüler veriyor gibi değil; daha çok trafik polisinin izin verdiği koridor içinde serbest dolaşım var.
{
"agents": ["router", "support", "billing", "research"],
"edges": [
["router", "support"],
["support", "billing"],
["support", "research"],
["research", "support"]
],
"behavior": "agent decides next hop"
}
Bu modelin hoş tarafı shared transcript yapısıdır. Her yeni ajan önceki konuşmayı görür; ayrı thread’lerde kaybolmazsınız. Benim AZ-305 hazırlığında mimarı desenleri okurken sevdiğim şey de buydu aslında: bağlam kopmuyorsa tasarım nefes alıyor demektir (ki bu çoğu kişinin gözünden kaçıyor) Bu konuyla ilgili Kubernetes v1.36’da PSI GA: Sinyali Gürültüden Ayırmak yazımıza da göz atmanızı tavsiye ederim.
| Özellik | Klasik Router | Handoff Orchestration |
|---|---|---|
| Sahiplik değişimi | Zor | Doğal |
| Ara soru sorma | Sınırlı | Güçlü |
| Tam sohbet bağlamı | Bazen kopar | Paylaşımlı transcript ile korunur |
| Maliyet/karmaşıklık | Daha düşük başlangıç maliyeti | Daha iyi kontrol ama biraz daha fazla tasarım işi ister |
Nerede parlıyor, nerede biraz ham kalıyor?
Açık konuşayım: Handoff çok işe yarıyor ama sihirli değnek değil. Güzel özellik, fakat henüz ham tarafları var; özellikle yanlış kurgulanmış graph’larda döngü riski ve gereksiz devretmeler can sıkabiliyor. O yüzden guardrail kısmını hafife almamak lazım.
Kendi deneyimimden konuşuyorum, Ben geçen ay İzmir’de bir üretim müşterisinde bunu konuşurken aynı noktaya geldik: “ajanlar istedikleri kadar zeki olsun, sınır koymazsanız prod ortamda mızıkçılık başlar.” Şaka gibi ama doğru! O projede ilk denemede yanlış edge tanımı yüzünden agent kendini tekrar support’a devredip durdu; çözüm olarak edge sayısını kıstık ve termination koşulunu netleştirdik. Bu konuyla ilgili NL2SQL’de Asıl Soru: Prompt mu, Veritabanı mı? yazımıza da göz atmanızı tavsiye ederim.
En iyi handoff tasarımı genelde en az konuşan tasarımdır; ajanın ne zaman susacağını bilmesi en az ne zaman konuşacağını bilmesi kadar önemli.
Size bir şey söyleyeyim, Maliyet tarafında da ufak bir not düşeyim: Azure üzerinde çalışan LLM tabanlı ajanlarda her ekstra hop token tüketimini artırabiliyor (özellikle uzun transcript varsa). TL bazında bakınca küçük pilotta önemsiz görünen farklar kurumsal ölçekte büyüyor… yanı işi sadece teknik değil FinOps gözüyle de değerlendirmek lazım.
Bütçe kısıtlıysa ne yapmalı?
Eğer bütçeniz sınırlıysa önce iki-agent senaryosu ile başlayın: biri genel triage yapsın, diğeri uzmanlaşsın. Üçüncü ajanı ancak gerçekten ihtiyaç varsa ekleyin.
Şahsen, Büyük enterprise yapılarda işe doğrudan policy-based guardrails + audit log + role separation üçlüsünü kurun derim (özellikle regülasyonlu sektörlerde). Küçük ekipte hız kazanırsınız; büyük kurumda işe izlenebilirlik kazanırsınız — ikisi aynı anda bedava gelmiyor maalesef.
Pratikte nasıl yaklaşırım?
Neyse uzatmayalım, ben böyle projelerde hep aynı sırayla gidiyorum:
- Kullanıcı yolculuğunu çıkarıyorum; hangi noktada sahiplik değişebilir diye bakıyorum.
- Ajanları rol bazında ayırıyorum; tek ajan içine her şeyi tıkıştırmıyorum. — ciddi fark yaratıyor
- Döngü riskini azaltmak için izin verilen edge listesini dar tutuyorum.
- Error path belirliyorum; örneğin “emin değilsen insana eskale et”.
Bunu yapmadan direkt production’a dalarsanız sonra log incelemekten gözünüz döner…
Kod seviyesinde kafada canlandırma
# pseudo-code
support_agent.on_message = lambda msg:
if needs_billing_help(msg):
return handoff("billing")
if needs_more_info(msg):
ask_user_followup()
return stay()
if resolved(msg):
return finish()
Kod basit görünüyor ama davranış kısmı kritik olan yer burasıdır işte… Ajan “stay”, “handoff” ya da “finish” arasında doğru zamanda karar verebilmeli.
Aksi hâlde sistem teknik olarak çalışır ama operasyonel olarak yorucu olur.
Bu arada benzer mantığı Azure Functions retry zincirlerinde de gördüm; yanlış backoff stratejisi sistemi öldürmez belki ama sessizce yorar!
Bence Türkiye’de kullanım şekli biraz farklı olacak
Bunu Türkiye’deki şirketler açısından değerlendirirsek mesele sadece teknoloji seçimi değil.
Asıl konu organizasyon alışkanlığı.
Kurumsal müşterilerimde gördüğüm kadarıyla bizde ownership netliği çoğu zaman kağıt üstünde güzel dürüyor ama pratikte gri alan çok oluyor.
Handoff gibi modeller tam da bu gri alanları görünür hâle getiriyor.
Ama bunun bedeli var:
ekiplerin rol tanımlarını ciddi şekilde netleştirmesi gerekiyor.
Ha bu arada küçük ölçekli SaaS şirketlerinde tablo farklı.
Onlar hızlı sonuç ister.
Bir servis dışından bilgi toplasın,
gerekirse başka servise atsın,
sonra çıksın…
bu kadar.
Kurumsalda işe logging,
denetim izi,
KVKK hassasiyeti,
yetki ayrımı…
hepsi oyuna giriyor.
O yüzden ben Türkiye’de ilk adımda yalnızca müşteri destek veya iç operasyon senaryolarıyla başlanmasını daha mantıklı buluyorum.
Risk düşük olur.
Öğrenme hızı yüksek olur.
Ve açıkçası ekipler de boğulmaz.
Ekiplerin yaptığı tipik hata ne?
Bence en sık yapılan hata şu:
her uzmanlık alanına ayrı agent açıp sonra hepsini birbirine bağlamak.
Kağıt üstünde süper görünüyor.
Pratikte işe orkestrasyon karmaşası doğuruyor.
Geçen yıl Eylül ayında Bursa’daki bir lojistik firmasında buna benzer bir deneme yaptık.
Beş agent vardı;
iki hafta sonra ekip bana dönüp “hangisi neyi biliyordu şimdi?” diye sordu.
İşte o an anladılar ki fazla parçalama bazen faydadan çok yük getiriyor.
Ben olsam önce insan gibi tasarlarım:
bir giriş agent’ı,
bir-iki uzman,
gerekirse human-in-the-loop noktası…
Sonra genişletirim.
Bu yaklaşım bana AZ-104 döneminde öğrendiğim şeyi hatırlatıyor;
önce temel sağlıklı olsun,
sonra süs gelir.”
Sizin için kısa karar rehberi
?>Eğer hızlıca karar vermek istiyorsanız şöyle düşünün:
– Tek geçişli işler için klasik router yeterli.
– Konuşma sırasında soru sorma gerekiyorsa handoff daha uygundur.
– Regülasyonlu sektördeyseniz log. Guardrail olmadan başlamayın.
– Bütçe düşükse az sayıda agent ile pilot yapın.”
Bir de dürüst olayım:
bazı senaryolarda geleneksel workflow engine hâlâ daha iyi seçim olabilir.
Her problemi LLM agent ile çözmeye çalışmak moda diye yapılacak iş değil.”
Sıkça Sorulan Sorular
Handoff orchestration ne demek?
Ajanların işi birbirine devrettiği bir orkestrasyon modeli, yanı merkezî bir yönetici yerine kararları çoğunlukla ajanın kendisi veriyor. Aslında en güzel yanı şu: konuşma bağlamı tek bir transcript içinde kalıyor, hiçbir şey kaybolmuyor.
Klasik pipeline’a göre ne farkı var?
Hani ara soru sormak gerektiğinde ya da sahiplik tam orta yerde el değiştirdiğinde klasik pipeline gerçekten zorlanıyor. Handoff bu tür akışlarda çok daha doğal çalışıyor. Bence özellikle back-edge gereken işlerde farkı çok net hissediyorsunuz.
Küçük ekipler için de uygun mu?
Evet, uygun. Ama tecrübeme göre az sayıda agent ile başlamak şart. Fazla parçalarsanız debug yükü ciddi artıyor, açıkçası bu konuda dikkatli olmakta fayda var.
Maliyet artar mı?
Maalesef evet, özellikle uzun sohbetlerde token tüketimi epey büyüyebiliyor. Mesela pilot aşamada maliyeti yakından izlemek gerçekten şart.
Kaynaklar ve İleri Okuma
Azure Architecture Center — Patterns
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.
3 comments