Durable Workflows ile Microsoft Agent Framework: Gerçek Hayatta Ne İşe Yarıyor?
Microsoft Agent Framework tarafında son dönemde en çok dikkatimi çeken şey, ajansal yapıyı sadece “konuşan bot” seviyesinden çıkarıp iş akışına çevirmeleri öldü. Açık konuşayım, çoğu ekip AI agent deyince hâlâ tek bir prompt, tek bir cevap, biraz da süsleme düşünüyor (yanlış duymadınız). İşin aslı şu ki, kurumsal tarafta mesele hiç öyle değil. Bir karar verilecekse, veri çekilecekse, onay alınacaksa ve üstüne hata olursa geri sarılacaksa… orada artık workflow konuşuyoruz.
📋 İçindekiler
Ben bu yaklaşımı ilk gördüğümde aklıma hemen 2019’da bir finans müşterisinde yaptığımız otomasyon geldi. O zamanlar Azure Functions ile parça parça ilerliyorduk; e-posta at, kayıt aç, başka servisten veri çek, sonra tekrar dene… Dağınık bir yapıydı. Şimdi MAF’ın workflow modeli o parçaları daha temiz topluyor. Hani “şu işi biri baştan sona yönetsin” dersiniz ya — tam olarak o.
Evet, doğru duydunuz.
Açık konuşayım, Bir de şu var: MAF’in workflow katmanı sadece sıra sıra çalışan adımlar için değil; paralel dallanma, koşullu geçiş, insan onayı gibi gerçek hayatta can sıkan ama kaçınılmaz senaryolar için de uygun görünüyor. Kağıt üstünde güzel dürüyor. Pratikte göreceğiz artık.
Workflow Mantığı Neden Önemli?
Şunu net söyleyeyim: Agent yazmakla workflow işletmek aynı şey değil. Agent tarafında amaç genelde “akıllı cevap” üretmek oluyor; workflow tarafında işe hedef “güvenilir sonuç”. Bu fark bazen gözden kaçıyor. Mesela müşteri hizmetlerinde bir agent kullanıcıya doğru yanıt verebilir — bence çok yerinde bir karar —. O yanıtın arkasındaki sipariş iptal süreci yarıda kalırsa sistem çöker. Kurumsal dünyada bizi zorlayan da zaten bu ara boşluk.
Şöyle söyleyeyim, MAF’in workflow modeli burada baya işe yarıyor çünkü executor denen küçük görevleri düğüm gibi bağlayabiliyorsunuz. Her executor tek iş yapıyor: biri siparişi buluyor, biri iptal ediyor, biri e-posta hazırlıyor. Bu bana eski günlerdeki klasik pipeline tasarımlarını hatırlatıyor ama daha hafif ve daha okunur hâliyle. Özellikle.NET ekosisteminde çalışan ekipler için bu sade yaklaşım iyi olmuş.
Durun, bir saniye.
Geçen yıl İstanbul’da bir telekom projesinde benzer bir akış kurgulamıştık; olay şu: müşteri talebi geliyor, risk kontrolü çalışıyor, sonra operasyondan onay bekleniyor. Ancak ondan sonra işlem tamamlanıyor. O projede en büyük dert retry mantığını ve hata propagasyonunu düzgün tutmaktı. MAF burada doğrudan çözüm veriyor demem, ama zemini temizliyor diyebilirim.
Executor nedir?
Bence, Executor’ı küçük bir uzman işçi gibi düşünün. Eline gelen girdiyi alıyor, kendi işini yapıyor ve çıktı veriyor. Ne eksik ne fazla. Bu kadar basit olması güzel; çünkü karmaşıklığı azaltıyor. Ama şunu da söyleyeyim: Çok fazla executor yazarsanız proje kısa sürede Lego kutusuna döner — her şey birbirine girer.
Bu yüzden ben genelde önce süreç haritasını çıkarırım: hangi adım gerçekten bağımsız? Hangi adım başka bir adımı beklemek zorunda? Hangisi paralel çalışabilir? AZ-305’e hazırlanırken de hep aynı refleks vardı aslında: bileşeni değil bağımlılığı düşünmek. Burada da durum aynı.
Kod Tarafında Neler Değişiyor?
Mantık çok yabancı değil aslında. Bir console app açıyorsunuz, gerekli paketleri ekliyorsunuz ve executor sınıflarını yazmaya başlıyorsunuz (kendi tecrübem). Aşağıdaki yapı bana göre iyi bir başlangıç örneği: Visual Studio’da Bulut Ajanları: Kod Akışını Değiştiren Güncelleme yazımızda bu konuya da değinmiştik.
internal sealed class OrderLookup()
: Executor<OrderCancelRequest, Order>("OrderLookup")
{
public override async ValueTask<Order> HandleAsync(
OrderCancelRequest message,
IWorkflowContext context,
CancellationToken cancellationToken = default)
{
await Task.Delay(TimeSpan.FromMilliseconds(100), cancellationToken);
return new Order(
Id: message.OrderId,
OrderDate: DateTime.UtcNow.AddDays(-1),
IsCancelled: false,
CancelReason: message.Reason,
Customer: new Customer(
Name: "Jerry", Email: "jerry@example.com"));
}
}İlginç olan şu ki, Bence bu örneğin güzel tarafı şu: iş mantığı gözünüzün önünde dürüyor. Gizli sihir azalmış durumda. Azure Functions veya Durable Task dünyasında bazen yapı fazla soyut olur ya… burada o kadar ağır hissettirmiyor.
Ne yalan söyleyeyim, Bir dakika, şunu da ekleyeyim: Basit görünmesine aldanmayın. Workflow tasarlarken asıl mesele kod değil, state yönetimi ve hata davranışı oluyor. İlk denediğimde ben de bunu hafife aldım; 2024 Kasım ayında küçük bir lab ortamında test ederken timeout senaryosunda çıktılar beklediğim gibi taşınmadı. Sebep basitti: input-output zincirini doğru modellememiştim. Çözüm mü? Executor sınırlarını daraltıp ara çıktıları açık hâle getirdim. Bu konuyla ilgili GPT-5.2 ve GPT-5.2-Codex Emekli Oluyor: Şimdi Ne Olacak? yazımıza da göz atmanızı tavsiye ederim.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| In-process runner | Hızlı başlar, local geliştirme kolay | Duruşta dayanıklılık yok |
| Durable hosting | Yarıda kesilse bile devam edebilir | Daha fazla operasyon yükü getirir |
| Azure Functions entegrasyonu | Büyüyen sistemler için pratik | Tasarımdaki disiplin şarttır |
Durağan Değil, Dayanıklı Akışlar Gerekir
Bi saniye — İşin hayatı kısmı burası bence.Burada in-memory çalışan workflow modeli demo için fena durmuyor ama üretimde herkesin kafasını rahatlatan şey durability oluyor.Başka türlü olmuyor çünkü gerçek dünya kusursuz değil;s servis düşüyor network kopuyor fonksiyon timeout yiyor kullanıcı sayfayı kapatıyor (kendi tecrübem). bunların hepsi normaldir yanı.
Neden durable yapı?
Çünkü kurumsal tarafta “bir kere çalıştıysa yeter” diyemezsiniz.Finans kuruluşlarında bunu özellikle görüyorum;if işlem tamamlanmadığında sadece teknik problem çıkmıyor operasyonel risk de ortaya geliyor.Müşteri kaydı yarıda kaldıysa çağrı merkezî devreye giriyor log analizi gerekiyor yeniden deneme politikası tartışılıyor… Sız ne dersiniz? yanı mevzu uzuyor,baya uzuyor hatta.
Bence MAF’in durable yaklaşımı burada değer kazanıyor ama henüz ham duran yerler de var gibi geliyor bana.Özellikle izlenebilirlik ve debug deneyimi güçlü olmazsa ekipler kısa sürede klasik custom orchestration koduna geri döner.Yani araç iyi olsa bile kullanım disiplini şart.Hmm,biraz sert söyledim belki ama durum bu.
Küçük startup ile enterprise farkı
Küçük bir startup iseniz hedefiniz hız olmalı; in-process runner ile başlayın ve gereksiz soyutlamaya girmeyin derim.En başta her şeyi dağıtmanın anlamı yok.Eenterprise tarafta işe tam tersi geçerli: versiyonlama,retry stratejisi,audit trail ve insan onayı olmadan böyle bir yapıyı canlıya almak biraz cesaret işi olur — hatta açık konuşayım biraz delilik bile sayılır. Daha fazla bilgi için SIG Architecture API Governance: Kubernetes’in Sessiz Kahramanı yazımıza bakabilirsiniz.
E tabi maliyet tarafını da unutmamak lazım.Azure Functions + durable pattern kombinasyonu TL bazında bakınca ilk etapta ucuz görünür ama çağrı hacmi yükseldikçe tablo değişir (özellikle uzun yaşayan orchestrator’larda).Ben FinOps görüşmelerinde şunu sık söylüyorum:cucuz başlayan mimarı bazen pahalı bitiyor çünkü operatör zamanı bedava sanılıyor.Aslında bedava falan değil tabiî. Daha fazla bilgi için MCP Tool Çağrılarını .NET’te Yönetmek: AGT ile Pratik Yol yazımıza bakabilirsiniz. Kubernetes v1.36 Route Sync Metriği: CCM’de Yeni Bir Pencere yazımızda bu konuya da değinmiştik.
Zor Senaryolar: Paralellik ve İnsan Onayı
Maf workflow modelinin hoşuma giden kısmı fan-out / fan-in desenlerini doğal şekilde desteklemesi öldü.Ha bu arada bu tarz desenler teoride basit görünür ama pratikte data merging kısmı biraz can sıkabilir.Birden çok agent aynı anda araştırma yapıyorsa sonuçları nasıl toplayacağınızı önceden belirlemeniz gerekir.Yoksa iki ayrı doğruluk iddiası arasında kalırsınız… sonra kim haklı diye saatler gider.Neyse uzatmayayım,kafa karıştırıcı kısım tam da burasıdır işte.
Bunun yanında human-in-the-loop konusu da önemli.Durumu şöyle düşünün:Bazı kararlar otomatik verilmemeli.Mesela yüksek tutarlı para iadesi,kilit güvenlik aksiyonu ya da dış müşteriye gidecek resmî yanıt.Bu noktada insan onayı koymak işleri yavaşlatır gibi görünür. Yanlış karar maliyetini ciddi düşürür.Logosoft’ta geçen sene Ankara’daki bir kamu müşterisiyle çalışırken bunu birebir yaşadık:onay kapısı eklenince süreç %18 yavaşladı ama hatalı işlem oranı neredeyse sıfırlandı.Bence değiş tokuş gayet makul,Sız ne dersiniz?
Kurumsal AI projelerinde hız tek başına başarı ölçütü değil; güvenilirlik yoksa hızlı sistem sadece hızlı hata üretir.
Maliyet ve Operasyon Açısından Bakınca
Vallahi, Maliyet konusu çoğu blog yazısında yüzeysel geçiliyor ama ben burada dürüst olayım istiyorum.MAF + Azure Functions + Durable Task kombinasyonu size ilk bakışta modern. Temiz gelir fakat operasyonel borcu yine sız taşırsınız.Logging mi eksik?Alarm mı kaçmış?Replay sırasında veri tutarlılığı mı bozulmuş?Hepsi gündeme gelir.Bu yüzden PoC aşamasında sevdiğiniz mimariyi seçmeyin;sürdürülebilir olanı seçin.Kulağa basit geliyor,gerekirse acıyla öğreniyorsunuz zaten.
Eğer bütçe kısıtlıysa benim önerim şu olur:hayati olmayan işleri düz in-process yürütün,durable katmanı sadece para kaybettiren veya regülasyona takılan akışlara koyun.Mesela sipariş e-postası göndermek ayrı şeydir,sipariş iptalinin muhasebe kaydını açmak ayrı şeydir.Biri gecikebilir,biri gecikmemeli.Kolay gibi dürüyor (ilk duyduğumda inanamadım). Ayrımı doğru yapmak baya fark yaratır.Bu ayrımı kaçırınca işler çorba oluyor hani.
- Küçük ekip: Önce basit workflow kurun,sadece kilit adımlarda durability açın.
- Büyük kurum:Aaudit trail,retry policy,human approval ve telemetry’i en baştan planlayın.
- Maliyet hassasiyeti yüksekse:Sadece yüksek değerli işlemleri Azure’a taşıyıp kalanını sade tutun.
Nereden Başlamalı?
Lafı gevelemeden söyleyeyim:düzgün başlangıç yapmak istiyorsanız önce süreçlerinizi çizmeniz gerekiyor.Koddan başlamayın.Mevcut manuel akışı kağıda dökün,hataların nerede çıktığını not alın,en çok bekleyen noktaları ayıklayın.Sonra executor’ları tanımlayın.Bu sırayı ters çeviren ekiplerin çoğu iki hafta sonra refactor içinde boğuluyor,bizzat gördüm.Gereksiz kahramanlık etmeye değmez yanı.
Sıkça Sorulan Sorular
Microsoft Agent Framework içindeki workflow ne işe yarıyor?
Kısaca söyleyeyim: çok adımlı AI akışlarını düzenlemek için kullanılıyor. Yanı executor tabanlı yapı sayesinde her adımı ayrı tanımlıyorsunuz. Framework bunların arasındaki veri akışını kendisi hallediyor (en azından benim deneyimim böyle). Hata yönetimi de böylece çok daha derli toplu oluyor.
Durağan çalışma neden bu kadar önemli?
Doğrusu, Açıkçası üretimde işler her zaman pürüzsüz gitmiyor. Servis kapanabiliyor, ağ kopabiliyor, işlem ortada kalabiliyor. Durable yaklaşım sayesinde akış kaldığı yerden devam edebiliyor — hani sıfırdan başlamak zorunda kalmıyorsunuz — böylece veri kaybı riski ciddi ölçüde azalıyor.
Küçük ekipler bu yapıyı kullanmalı mı?
Evet, kullanabilirler. Ama tecrübeme göre hemen her şeyi durable yapmak şart değil. Bence önce basit runner ile başlayıp yalnızca kritik adımları dayanıklı hâle getirmek çok daha mantıklı. Kompleksliği erken şişirmemek önemli — sonradan eklemek her zaman mümkün.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Azure Functions zorunlu mu?
Hayır, zorunlu değil. Local in-process runner ile rahatlıkla başlayabilirsiniz (ben de ilk duyduğumda şaşırmıştım). Ama ölçeklenebilirlik ve dayanıklılık ihtiyacı doğduğunda Azure Functions entegrasyonu aslında gayet doğal bir adım oluyor.
Kaynaklar ve İleri Okuma
- Orijinal Microsoft Blog Yazısı
- Azure Durable Functions Genel Bakış
- Microsoft Agent Framework GitHub Deposu
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