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
-
Hmm, bunu nasıl anlatsamdı…
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)
Ö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.
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…
💡 Bilgi: İlk pilotta shared transcript’i muhtemelen saklayın ve handoff kararlarını loglayın. Sonradan niye devredildi sorusunun cevabı altın değerinde oluyor.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
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Emre Ç.
Konuşma ortasında ajan değişikliği gerçekten klasik router’ların kamburu, graf tabanlı yaklaşım mantıklı geliyor. Acaba döngüsel geçişlerde deadlock gibi durumlarla karşılaşmak mümkün mü sistemde? Bu arada NL2SQL yazınız da çok yerindeydi, çok ajanlı sistemlerde veritabanı tarafını nasıl ele aldığınızı görmek güzeldi: https://www.askinkilic.com.tr/nl2sqlde-asil-soru-prompt-mu-veritabani-mi/
Cem A.
Klasik router’ın neden yetersiz kaldığını anlatan kısım çok yerinde olmuş, biz de benzer bir problemi yaşadık geçen ay. Peki bu grafik yapısında döngüsel handoff durumları nasıl önleniyor, buna değinilmiş mi?
Uğur H.
Router yaklaşımının başlangıçta iyi görünüp konuşma ortasında çuvalladığı durumu çok iyi açıklamışsınız. Acaba graf yapısında döngüsel geçişlere izin veriliyor mu, yani bir ajan işi başka birine devretti sonra tekrar aynı ajana geri dönebiliyor mu?
Yorumlar kapalı.
3 comments