Handoff Orchestration: Ajanlar Birbirine Topu Atınca Ne

Garip gelecek ama, Geçen ay İstanbul’daki bir sigorta şirketinde, müşteri hizmetleri tarafına bir “AI asistan” projesi yetiştirmeye çalışıyorduk. Klasik hikâye yanı: bir router ajan geliyor, isteği alıyor, doğru uzman ajana yönlendiriyor. Kağıt üstünde temiz — ki bu tartışılır — duruyor, akıllı duruyor, modüler de sayılır. İlk demoda da fena değildi. Ta ki gerçek müşteri konuşmalarına bakana kadar.

Sorun şuydu: müşteri “poliçemi iptal etmek istiyorum” diyor, iptal ajanı devreye giriyor, ama konuşmanın ortasında ortaya çıkıyor ki adam aslında iptal değil, kapsam değişikliği istiyor. Şimdi ne yapacak iptal ajanı? (söylemesi ayıp) Router’a geri mi dönsün? Konuşma geçmişi sıfırlansın mı? Müşteriye “bir saniye, sızı başka bir asistana bağlıyorum” mu desin? İşte burada işler dağıldı. Ciddi dağıldı.

Araya gireyim: İşte tam bu noktada Microsoft Agent Framework’ün Handoff Orchestration deseniyle tanıştım. Bugün size bu deseni — sahada gördüğüm hâliyle — anlatmak istiyorum. Lafı gevelemeden söyleyeyim; ne işe yarıyor, ne zaman kullanılır, ne zaman başınıza dert açar, hepsine girelim.

Handoff Aslında Ne Demek?

İsim biraz yanıltıyor açıkçası. “Handoff” deyince akla klasik telefon transferi gelmesin. Burada olan şey daha ince: bir ajan grubu var, aralarında yönlü kenarlar tanımlı bir graf çiziyorsunuz. Framework her ajana “şu hedefe topu at” diye sentetik bir tool çağrısı ekliyor.

Yanı siz topolojiyi belirliyorsunuz — kim kime devredebilir, kim kimden devralabilir. Ama kararı modelin kendisi veriyor. Sabit bir if-else ağacı yok. Pipeline yok. Modeli zorla tek çizgiye sokmuyorsunuz. Bu arada iyi de oluyor; çünkü bazen modelin ufak bir kıvrım yapmasına izin vermek gerekiyor.

Bunu Türkiye’deki kurumsal yapılar açısından düşünürsek — özellikle bankacılık ve telekomda gördüğüm kadarıyla — bu yaklaşım önemli bir problemi çözüyor: yetki sınırı. Bir ajanın yanlış yere yönlendirme yapma ihtimalini prompt seviyesinde değil, workflow seviyesinde kesiyorsunuz (ve evet, compliance ekibi bunu duyunca rahatlıyor). Açık konuşayım, fark baya hissediliyor.

Routing kararı ajanlarda kalıyor; topoloji ve guardrail’ler geliştiricide. Bu ayrım, ölçeklenebilir multi-agent sistemlerin can damarı bence.

Ne Zaman Kullanmalı, Ne Zaman Kullanmamalı?

Açık konuşayım — Handoff her derde deva değil. Hatta yanlış yerde kullanırsanız, basit bir pipeline’la çözeceğiniz problemi gereksiz yere büyütürsünüz. Şöyle bakalım; çünkü bu kararı vermek işin en zor kısmı gıbı duruyor:

Handoff’a Yeşil Işık

• Bir ajan işini bitirmeden önce ek bilgi toplaması gerekiyorsa ve cevabın aynı ajana dönmesi şartsa — ciddi fark yaratıyor
• Konuşmanın ortasında “bu iş aslında bana ait değilmiş” realizasyonu yaşanabiliyorsa
• Geri kenarlar (back-edges) önemliyse — yanı ajan bazen “dür, daha fazla araştırma lazım” deyip önceki adıma dönebilmeli (bu kritik)
• Tüm konuşma geçmişinin paylaşılması gerekiyorsa
• Yönlendirme kararı bulanık ve bağlamsalsa — yanı tipik kurallarla yazılması zor işe

Handoff’a Kırmızı Işık

Eğer sizin akışınız deterministik işe — yanı A her zaman B’ye, B her zaman C’ye gidiyorsa ve bunda istisna yoksa — Handoff’a girmeyin. Sequential workflow kullanın. Daha sade oluyor, daha öngörülebilir oluyor, debug etmesi de kolaylaşıyor.

Bir de paralelleştirme istediğiniz durumlarda aynı şey geçerli değil zaten. Mesela bir doküman geldiğinde üç farklı ajan aynı anda farklı analizler yapacaksa bu Handoff değil; fan-out/fan-in deseni. Karıştırmayın derim.

Mekanik Nasıl Çalışıyor?

Peki nasıl işliyor? Bak şimdi işin teknik tarafına girdik. Bir handoff workflow’unu tanımladığınızda framework arka planda şunları yapıyor:

1. Her ajan için kendi çıkış kenarlarına göre handoff_to_X tarzında sentetik tool’lar üretiyor
2. Bu tool’ları ajanın tool listesine ekliyor — yanı ajan kendisini “transfer edebilir” hâle geliyor
3. Tüm ajanlar tek bir transcript‘i paylaşıyor; izole thread’ler yok
4. Aktif ajan bir tür tamamlayıp handoff tool’u çağırmazsa workflow doğal olarak sonlanıyor

Burası kritik nokta aslında. Termination koşulu için ekstra state machine yazmıyorsunuz (iyi haber bu). “Ajan susarsa iş bitti” mantığı çoğu senaryoda yeterli oluyor. Tabii her yerde değil ama şaşırtıcı derecede sık yetiyor.

Basit Bir Python Örneği

from agent_framework import HandoffBuilder, ChatAgent
triage = ChatAgent(
name="triage",
instructions="Kullanıcının ne istediğini anla, doğru uzmana yönlendir."
)
billing = ChatAgent(
name="billing",
instructions="Faturalama ve ödeme sorularını yanıtla. Teknik sorun çıkarsa support'a devret."
)
support = ChatAgent(
name="support",
instructions="Teknik destek sağla. Ödeme konusu çıkarsa billing'e devret."
)
workflow = (
HandoffBuilder(start_agent=triage)
.add_handoff(triage, [billing, support])
.add_handoff(billing, support)
.add_handoff(support, billing)
.build()
)
result = await workflow.run("Geçen ayki faturam çift çekilmiş, ayrıca uygulama da açılmıyor")

Burada dikkat ederseniz triage’dan billing ve support’a gidebiliyor ama billing ile support birbirleri arasında da geçiş yapabiliyor. Triage’a geri dönüş yok. Çünkü ihtiyaç da yokmuş gıbı duruyor; triage ilk turda işini bitiriyor zaten. mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımızda bu konuya da değinmiştik.

Sahada Gördüğüm Topoloji Şekilleri Üç Tane Gıbı Duruyor

Neyse uzatmayayım; Logosoft’ta son altı ayda yaptığımız 4-5 multi-agent projede Handoff topolojilerinin genelde üç şekle yakınsadığını gördüm diyebilirim. Bunları paylaşayım; belki kendi projede size de oturur: Daha fazla bilgi için Az Privilege AI Agent: Curity ve Microsoft’tan azd Şablonu yazımıza bakabilirsiniz.

1. Yıldız (Hub-and-Spoke)

Kafada merkezde bir triage ajan var; etrafında uzmanlar dolaşıyor gıbı düşünün. Uzmanlar birbirleriyle konuşmuyor — sadece triage’a geri dönebiliyorlar. Ankara’daki bir devlet kurumu projesinde bunu kullandık mesela (ve evet), compliance açısından en güvenli modele yakın duran yapı buydu çünkü kontrol noktası tek kalıyordu.

Soru şu: Mesh iyi mi?

Bakın, Evet de olabilir, hayır da olabilir gıbı duruyor açıkçası. Her ajan neredeyse her ajana geçebiliyor; yukarıdaki billing-support örneği gıbı düşünün. Esnek ama kontrolü zorlaşıyor biraz. Küçük ekiplerde veya 3-4 ajanlı sistemlerde idare eder ama daha fazlasında karmaşa hızlı başlıyor. Claude Sonnet 4 GitHub Copilot’ta Emekli Oldu: Geçiş Rehberi yazımızda bu konuya da değinmiştik.

Bir dakika — bununla bitmedi.

Daha sonra katmanlı yapı geliyor mu?

Evet geliyor tabii ki ama biraz başka türlü çalışıyor: üst katmanda triage var, orta katmanda kategori uzmanları var, alt katmanda detay uzmanları var (biraz matruşka gıbı). Aşağıdan yukarıya geri dönüş edge’leri de bulunuyor olabilir. Bir telekom müşterimizde 12 ajanlı sistemi böyle kurduk; karmaşık görünüyordu ama yönetilebilir kaldı. Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımızda bu konuya da değinmiştik.

Topoloji	Ajan Sayısı	Avantaj	Dezavantaj
Yıldız	3-8	Kontrol kolay ölür ya da denetlenebilir kalır	Triage darboğaz olabilir

Bazen İş Teknikten Çok Kültüre Takılıyor!

Bunu Türkiye’deki şirketler açısından değerlendirirsek gördüğüm en büyük engel teknik değil; kültürel taraf oluyor çoğu zaman. Birçok kurumsal müşterimde “AI ajanları kendi aralarında karar versin” fikri başta tedirginlik yaratıyor (haklılar da biraz). “Ya yanlış yere yönlendirirse?” sorusu ilk gün büyük ihtimalle geliyor.

Durun, bir saniye. Daha fazla bilgi için Agent Pull Request’leri Her Yerde: Doğru Review Nasıl? yazımıza bakabilirsiniz.

This is malformed due to corruption and must be fixed by regenerating entire content faithfully from source with proper HTML structure while keeping tags/links/styles intact.

Sıkça Sorulan Sorular

Handoff Orchestration ile klasik router pattern arasında ne fark var?

Klasik router’da yönlendirme tek seferlik — bir karar verilir, ajan kendi başına devam eder. Handoff’ta işe her ajan devretme kararını kendisi verebiliyor, hani konuşmanın tam ortasında bile. Yanı aslında router merkezî bir yapı, Handoff — kendi adıma konuşayım — işe dağıtık bir karar mekanizması. Bence bu fark pratikte çok belirgin hissettiriyor.

Sonsuz döngüye girmeyi nasıl engellerim?

İki yöntemi birlikte kullanmak iyi sonuç veriyor: max iteration limit (mesela 8 tür) ve prompt seviyesinde “emin değilsen kendin cevap ver, devretme” talimatı. Açıkçası production’da loop detection metric’ını izlemeden geçmeyin, tecrübeme göre bu kısım sık atlanan. Kritik bir nokta.

Handoff sadece Python’da mı çalışıyor?

Kendi deneyimimden konuşuyorum, Hayır, Microsoft Agent Framework hem.NET hem Python tarafında Handoff desteğini veriyor. API’ler birbirine yakın ama yanı dil idiomatik farkları mevcut. Mevcut stack’inize göre seçebilirsiniz.

Handoff ile token maliyeti ne kadar artıyor?

İtiraf edeyim, Aslında çok değişiyor ama kabaca, sequential bir pipeline’a göre %40-80 arası daha fazla token tüketebilir — çünkü her devirde transcript yeniden gönderiliyor. Hibrit model stratejisiyle (basit ajanlar küçük model, karmaşık ajanlar büyük model) bu fark ciddi şekilde kapatılabiliyor. Bence bu stratejiyi en baştan planlamak mantıklı.

Hangı durumlarda Handoff yerine sequential workflow kullanmalıyım?

Vallahi, Akışınız deterministikse, yanı A→B→C sırası hiç değişmiyorsa ve geri kenar ihtiyacınız yoksa sequential workflow çok daha basit, ucuz ve öngörülebilir. Handoff’u yalnızca bulanık ve dinamik routing ihtiyaçları için saklayın — hani her yerde kullanmak şart değil.

Hmm, bunu nasıl anlatsamdı…

Kaynaklar ve İleri Okuma

A Tour of the Handoff Orchestration Pattern — Microsoft DevBlogs

Microsoft Agent Framework Resmî Dokümantasyonu

Daha açık söyleyeyim, kendi deneyimimden konuşuyorum, Microsoft Agent Framework GitHub Repository