Agent Framework Orchestration 1.0: Çoklu Ajan Koordinasyonu Yetişkin
Microsoft Agent Framework’ün orchestration katmanı hem Python hem.NET tarafında 1.0’a geldi. Python’daki agent-framework-orchestrations paketi de artık 1.0.0 etiketini taşıyor. Kulağa “sadece bir versiyon numarası” gibi geliyor,. E peki, sonuç ne öldü? Çoklu ajan mimarileriyle uğraşan ekipler için bu bayağı hayatı bir eşik.
Neden mi? Çünkü şimdiye kadar desen seçerken SDK olgunluğuna bakıp duruyorduk. “Python’da handoff var mı,.NET’te magentic hazır mı” diye tek tek kontrol etmek zorunda kalıyorduk. Artık o dert büyük ölçüde bitti. Sequential, concurrent, group chat, handoff ve magentic — beşi de iki SDK tarafında stabil.
Çoklu ajan sistemlerinde en çok yeniden icat edilen tekerlek “koordinasyon” katmanıdır. Sıradaki ajanı kim seçer? Turlar arası state nasıl taşınır? Ekip tıkandığında ne olur? Orchestration 1.0 tam da bu tekerleği hazır veriyor.
Beş Desen, Beş Farklı Dert
Araya gireyim: Microsoft burada beş temel koordinasyon deseni sunuyor. Her birinin yeri ayrı, ama sahada gördüğüm kadarıyla ekiplerin çoğu ilk projede yanlış deseni seçip sonra “biz bunu niye böyle yaptık” diye dönüp bakıyor (buna dikkat edin). O yüzden lafı gevelemeden kısa kısa açayım:
- Sequential: Ajanlar sırayla çalışıyor. Birinin çıktısı ötekine gidiyor. Bildiğiniz pipeline mantığı.
- Concurrent: Ajanlar aynı anda paralel koşuyor, sonra sonuçlar birleşiyor.
- Group Chat: Ajanlar sanki bir sohbet odasındaymış gibi sırayla söz alıyor. — ciddi fark yaratıyor
- Handoff: Bir ajan görevi doğrudan diğerine devrediyor. Çağrı merkezî hissi veriyor biraz.
- Magentic: Yönetici ajan plan yapıyor, uzmanlara işi dağıtıyor, gidişatı da izliyor.
Şimdi burada ufak bir nüans var. Sequential ve concurrent zaten çoğu framework’te vardı; handoff da yeni sayılmaz, LangGraph’ta da var, CrewAI’de de benzer şeyler görüyorsunuz. Asıl farkı yaratan desen bence magentic. En az elle kablolanan yapı o. Diğerlerinde grafiği sız kuruyorsunuz; magentic’te işe hedefi, yöneticiyi. Uzmanları veriyorsunuz, gerisini yönetici ajan toparlıyor. Şey, işin rahat tarafı orası.
Workflow Katmanı ile Orchestration Katmanı Aynı Şey Değil
Bu ayrımı doğru oturtmak lazım, çünkü karıştıran çok oluyor. Agent Framework’te iki farklı seviye var ve aradaki fark sandığınızdan daha belirgin:
Alt Seviye: Workflow Primitifleri
Workflow katmanında grafiği sız kuruyorsunuz. Executors işi yapıyor, edges mesajları yönlendiriyor, workflow event yayınlıyor. Yanı düşük seviyeli, esnek ama dizayn yükü sizde olan bir yapı bu. State machine kurar gibi düşünün; biraz el emeği istiyor (şaşırtıcı ama gerçek)
Üst Seviye: Orchestration Builders
Orchestration builder’lar bunun üstünde dürüyor (ki bu çoğu kişinin gözünden kaçıyor). Aynı workflow modelini içeride kullanıyorlar ama size hazır bir builder veriyorlar. Mesela MagenticBuilder‘a katılımcıları veriyorsunuz, o size çalıştırılabilir bir workflow dönduruyor. Sonuç yine workflow. stream edebiliyorsunuz, compose edebiliyorsunuz, hatta kendi grafiğinizin parçası yapabiliyorsunuz.
Peki neden?
Magentic Neden Bu Kadar Önemli?
Açık konuşayım: Sequential ve concurrent desenlerini kendi başınıza yazmanız çok zor değil. Yarım gün ayırırsınız, kuyruk kurarsınız, ajanları çağırırsınız, biter gider. Ama magentic öyle değil işte.
Magentic’te yönetici ajan görevi plana çeviriyor, uzmanlara iş atıyor, her turdan sonra ilerlemeyi kontrol ediyor, ekip tıkandığında planı revize ediyor. Bunu elle yazmaya kalkınca şunlarla boğuşuyorsunuz:
- Sıradaki ajanı kim seçecek? (Routing logic)
- Turlar arası state nasıl taşınacak? (Context management)
- Ekip tıkandığında (stall detection) ne olacak?
- Kaç tür sonra peş edilecek? (Max round & reset)
- İş bitti diye kim karar verecek? (Termination)
Bence, Bunlar kağıt üstünde basit dürüyor olabilir. Pratikteyse epey çirkinleşiyorlar. Bilhassa stall detection ve reset mantığını düzgün yazmak ciddi emek istiyor; hani küçük gibi görünen ama gece yarısı can sıkan şeylerden biri bu. Magentic bunları paket halinde veriyor (bizzat test ettim)
Koda Bakalım: MagenticBuilder Nasıl Kullanılıyor?
Aşağıda Foundry Chat Client ile kurulmuş bir magentic workflow örneği var. Bir araştırmacı var, bir kod yazan uzman var ve bir yönetici var; yönetici ajan turdan tura koordinasyonu üstleniyor:
import os
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import MagenticBuilder
from azure.identity import AzureCliCredential
client = FoundryChatClient(
project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
model=os.environ["FOUNDRY_MODEL"],
credential=AzureCliCredential(),
)
researcher = Agent(
name="Researcher",
description="Bilgi toplar",
instructions="Sadece arastirma yaparsin, sayisal analiz yapmazsin.",
client=client,
)
coder = Agent(
name="Coder",
description="Kod yazip veri analizi yapar",
instructions="Sayisal sorulari kod yazarak cevaplarsin.",
client=client,
tools=client.get_code_interpreter_tool(),
)
manager = Agent(
name="Manager",
description="Ekibi koordine eder",
instructions="Karmaşık gorevlerde ekibi yonlendirirsin.",
client=client,
)
workflow = MagenticBuilder(
participants=[researcher, coder],
manager_agent=manager,
max_round_count=10,
max_stall_count=3,
max_reset_count=2,
).build()
task = (
"ResNet-50, BERT-base ve GPT-2 modellerinin egitim ve cikarim "
"enerji tuketimini karsilastir, CO2 emisyonunu tahmin et ve gorev "
"tipine göre en verimli modeli oner."
)
async for event in workflow.run(task, stream=True):
print(event)
Dikkat edin; burada grafik çizmediniz, edge kurmadınız, kimin nereye mesaj göndereceğini tek tek yazmadınız. Sadece “bu üç ajan var, birbirleriyle konuşup şu işi çözsünler” dediniz. Geri kalan kısmı yönetici ajana bırakıyorsunuz.
Guardrail Parametreleri Neden Ciddi?
max_round_count, max_stall_count, max_reset_count — bu üçlü olmazsa magentic size boş yere Azure faturası şişirebilir. Sonsuz döngüye giren bir yönetici ajan düşünün; her turda GPT-4 seviyesinde bir modele plan revize ettiriyor olsun… Hani ne farkı var diyorsunuz, değil mi? Bir sabah uyanıp 3000 dolarlık faturayla karşılaşmanız hiç şaşırtıcı olmaz.
Ben de test ederken bir kere stall count’u 10’a çekmiştim; açık konuşayım, o gün bu parametrelerin tavsiye değil zorunluluk olduğunu net gördüm.
Peki Hangi Deseni Ne Zaman Seçmeli?
Sahada müşterilerle konuşurken en çok gelen soru bu oluyor: “Hangisini kullanayım?” Basit bir tabloyla toparlayayım:
| Desen | Kullanım Senaryosu | Karmaşıklık | Maliyet Riski |
|---|---|---|---|
| Sequential | Sabit sıralı pipeline (özet → çeviri → gözden geçirme) | Düşük | Öngörülebilir |
| Concurrent | Bağımsız paralel analiz (sentiment + kategori + özet) | Düşük | Orta (paralel çağrı) |
| Group Chat | Beyin fırtınası, tartışma, konsensüs | Orta | Yüksek (uzayabilir) |
| Handoff | Müşteri destek, triage, yönlendirme | Orta | Öngörülebilir |
| Magentic | Belirsiz, çok adımlı araştırma görevi | Yüksek | Yüksek — guardrail şart |
Bence burada asıl mesele şu: Magentic ne kadar hoş görünse de her probleme uygun değil. Görev iyi tanımlıysa ve adımlar belliyse sequential kullanın; maliyet ve latency tarafında daha rahat edersiniz. Tahmin eder mısınız? Magentic’i belirsizlik yüksek olduğunda devreye alın — yanı “bu problemi nasıl çözeriz” kısmı hâlâ sisliyse.
Türkiye Tarafında Kurumsal Adaptasyon Nasıl Olur?
Kendi açımdan biraz yerel bağlam ekleyeyim dedim. Türkiye’de kurumsal müşterilerde çoklu ajan mimarilerine geçiş hâlâ erken aşamada dürüyor. Bankaların çoğu daha yeni yeni tek-ajanlı Copilot senaryolarını Foundry üzerinde deniyor; multi-agent tarafına geçmek için önce birkaç soru netleşmeli:
- Denetlenebilirlik: BDDK ve KVKK açısından “birden fazla ajan konuştu ve karar verdi” senaryosu ciddi audit soruları çıkarıyor. Hangi ajan ne dedi? Kararın izi nerede?
- Maliyet öngörülebilirliği: CFO’lar sabit maliyet ister; magentic gibi dinamik desenlerde tür sayısı değiştiği için aylık tahmin yapmak zorlaşıyor.
- Sorumluluk paylaşımı: Ajan ekibinin verdiği hatalı kararda hesap kime sorulacak? Hukukî taraf hâlâ biraz gri.
Kendi deneyimimden konuşuyorum, Bence bu üç konuya net cevap bulmadan multi-agent’ı prod’a taşımayın derim. İlk fazda sequential veya handoff gibi daha öngörülebilir desenlerle başlayın; ekip olgunlaştıkça magentic’e geçersiniz artık.
Neyse uzatmayayım (buna dikkat edin)
This konuda daha önce yazdığım Agent Harness ile Ajana Veri Vermek: Onay ve Hafıza Dahil, ajana onay ve hafıza katmanı ekleme konusunda pratik ipuçları içeriyor; denetlenebilirlik tarafında başlangıç noktası olarak fena değil.
Küçük Ekip ile Kurumsal Ekip Aynı Şeyi Yapmıyor Aslında
Küçük bir ekipseniz ya da startup’sanız — magentic tam size göre olabilir diyebilirim aslında — hızlı prototip çıkarırsınız — az kodla epey esneklik yakalarsınız — hatta bir haftada POC bile bitirirsiniz.
Evet.
Ama 500+ kişilik kurumsal yapıda ilk 6 ay sequential ve handoff ile ilerlemek daha akıllıca dürüyor bence.
Neden?
Şöyle söyleyeyim, Dönüp dolaşıp aynı yere geliyoruz: Kurumsal ortamda deterministik davranış altın standart gibi çalışıyor.
Aynı görev için yönetici ajanın her seferinde farklı plan üretmesi test yazmayı da zorlaştırıyor; insan bazen “bu kadar oynaklık niye” diye soruyor açıkçası.
TL Bazında Maliyet Ne Demek?
Sayı konuşalım biraz.
Magentic tarzı bir görev ortalama 6-8 tür sürüyor.
Ciddiyim.
Her turda yönetici ajan planı gözden geçiriyor, bir uzman çalışıyor ve sonuç geri dönüyor; GPT-4o seviyesinde modelle bakınca tür başına 3-5 çağrı çıkabiliyor yanı toplamda 20-40 model çağrısı görmek mümkün.
Küçük bir detay:
Dürüst olmak gerekirse, `Foundry üzerinden GPT-4o kullanıyorsanız (Kasım 2026 tarifesi), input token 2.50 USD/M output token da yaklaşık 10 USD/M civarında.` Ortalama görev tüketimi de kabaca 50K-150K token bandına düşüyor.
Bunun TL karşılığı görev başına yaklaşık 10-40 TL ediyor diyelim; ayda 10 bin görev yapan sistem için de rakam kabaca 100 bin ila 400 bin TL aralığına çıkıyor.
Sıkça Sorulan Sorular
Magentic ile Group Chat arasındaki fark ne?
Group chat’te ajanlar sırayla söz alıyor. Kim ne zaman konuşacak, aslında framework’ün seçim mekanizmasına kalıyor — yanı ortada plan yapan merkezî bir otorite yok. Magentic’te işe bir yönetici ajan var; aktif olarak plan yapıyor, revize ediyor, iş dağıtıyor. Bence en güzel benzetme şu: group chat “toplantı”, magentic “proje yönetimi” gibi düşünebilirsiniz.
Orchestration builder yerine ham workflow yazmak ne zaman mantıklı?
Aslında, Eğer ihtiyacınız standart desenlerden hiçbirine uymuyorsa ham workflow’a ının. Mesela belirli koşullarda döngü kurmak, dinamik olarak yeni ajan spawn etmek ya da kendi terminasyon mantığınızı yazmak istiyorsanız — o zaman ham workflow daha doğru. Ama standart beş desenden biri işe yarıyorsa builder’ı tercih edin; açıkçası kod daha az, bakım çok daha kolay oluyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Multi-agent sistemleri prodüksiyona almak için minimum altyapı ne?
Yanı, Tecrübeme göre en az şu üçü olmalı: (1) observability — hani OpenTelemetry veya Application Insights ile tür bazlı loglama, (2) budget guard — Azure Cost Management alertleri ile aylık limit, (3) fallback mekanizması — magentic başarısız olursa deterministik bir yola düşme. Bu üçü olmadan prodüksiyona geçmeyin, gerçekten.
Python ve.NET SDK arasında feature parity var mı?
Beş orchestration deseni her ikisinde de stabil. Ama workflow primitifleri tarafında bazı yardımcı fonksiyonlar Python’da biraz daha zengin. Yanı Node.js/TypeScript projeleriyle uyumlu bir stack istiyorsanız Python daha mantıklı; mevcut kurumsal.NET yığınına entegre olacaksanız.NET tarafı sizin için çok daha rahat olur.
Yönetici ajan için hangi modeli seçmeli?
Bence bu kritik bir karar. Yönetici ajanı en güçlü modelinizle çalıştırın — GPT-4o veya Claude Sonnet seviyesi. Uzman ajanlar için daha küçük modeller yeterli olabiliyor. Zayıf bir modeli yönetici yaparsanız plan kalitesi düşüyor, tür sayısı artıyor ve toplam maliyet paradoksal şekilde yükseliyor. Yanı tasarruf etmeye çalışırken tam tersi oluyor.
Kaynaklar ve İleri Okuma
Microsoft DevBlogs: Agent Framework’s Orchestration Patterns Reach 1.0
İlginç olan şu ki, Microsoft Agent Framework Resmî Dokümantasyonu
Agent Framework GitHub Deposu. Örnek Kodlar
Azure AI Foundry 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.
4 comments