Yıllardır “.NET tarafında AI hep geriden geliyor” diye bir algı vardı (ben de ilk duyduğumda şaşırmıştım). Açık konuşayım, ben de bir dönem aynı şeyi düşünüyordum. Python tarafı LangChain, LlamaIndex derken; biz hâlâ HTTP client’la OpenAI’a istek atıyorduk. Gel gör ki son bir düşüneyim… bir buçuk yılda iş baya tersine döndü. Microsoft Extensions for AI (MEAI) ile temeli attı, VectorData ile RAG kapısını araladı, şimdi de Microsoft Agent Framework ile işin tepesine kuruluyor. Kısacası tablo değişti.
Bugün yazacağım şey biraz uzun olacak, baştan söyleyeyim. Çünkü Agent Framework sadece “yeni bir kütüphane” değil.NET ortaminde AI uygulaması kurma işini başka bir yere taşıyor, hatta bazen insanın kafasını da karıştırıyor (iyi anlamda), çünkü olay artık tek tek API çağrısı yapmak değil, ajanların birbirleriyle konuştuğu daha düzenli bir yapı kurmak. Logosoft tarafında son üç ayda iki farklı kurumsal projede bu framework’ü production’a soktuk — biri sigorta sektöründe bir poliçe asistanı, diğeri bir lojistik firmasında operasyon ajanı. Anlatacaklarım büyük ölçüde o saha deneyiminden geliyor. Evet.
Önce şu “ajan” lafını netleştirelim
Chatbot dediğimiz şey, açık konuşayım, çoğu zaman bir aracı gıbı çalışıyor. Sen soruyorsun, modelden cevabı çekiyor, sana geri veriyor. Bitti. Ajan işe işin rengini değiştiriyor; kendi başına adım atabiliyor, araç çağırabiliyor, aldığı sonucu tartıp “tamam da bu yetmedi” deyip başka bir şeye uzanabiliyor.
Şöyle düşünün. MEAI ile çalışmak, işini bilen bir meslektaşa soru sormak gıbı. Ajan işe o meslektaşa eline bir to-do listesi tutuşturup “bunu sen hallet, takıldığın yerde masamdaki dökümanlara da bak, hesap makinesini kullan, gerekirse müşteriye mail at” demek gıbı; yanı kontrol sende duruyor. Işi yürüten taraf biraz kendi kafasına göre ilerliyor.
İşin teknik tarafına gelirsek, Agent Framework Nişan 2026’da 1.0’a ulaştı. C# ve Python için artık oturmuş sayılabilecek bir SDK var. Tek ajanla da gidebiliyorsunuz, graph tabanlı orkestrasyonla kurulan multi-agent akışlara da çıkabiliyorsunuz; ben bu yazıda C# tarafında kalacağım, çünkü sahada elim daha çok oraya gidiyor.
Şimdi gelelim işin can alıcı noktasına.
İlk ajanını 10 satırda kur
Bakın, Önce paketi ekle. Kısa iş.
dotnet add package Microsoft.Agents.AISonra kod geliyor, ama panik yok; gerçekten bu kadar. Ben ilk gördüğümde de “bu mu yanı?” demiştim, çünkü işin güzel tarafı tam burada başlıyor (az kod, az sürtünme, az kafa karışıklığı), tabii detaylar yine var. Temel kurulum baya hızlı ilerliyor.
using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")
? throw new InvalidOperationException("AZURE_OPENAI_ENDPOINT tanımlı değil.");
var deployment = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME")
? "gpt-5.4-mini";
AIAgent agent = new AzureOpenAIClient(
new Uri(endpoint),
new DefaultAzureCredential())
.GetChatClient(deployment)
.AsAIAgent(
instructions: "Sen tecrübeli bir Azure danışmanısın. Kısa ve net cevap ver.",
name: "AzureCoach");
Console.WriteLine(await agent.RunAsync(
"Bir startup için Azure bölge seçimi nasıl yapılır?"));Dikkat ettiyseniz .AsAIAgent() diye bir extension method var. Güzel nokta şu: Microsoft burada önce IChatClient soyutlamasını öne çıkarıyor, sonra onun üstüne ajan mantığını oturtuyor. Katmanlar birbirine girmiyor, bağımlılık da tek yerde kalıyor, bu yüzden mimarı tarafı fena durmuyor. Daha açık söyleyeyim, peki neden önemli? Çünkü yarın öbür gün modeli değiştirince her yeri didik didik etmek zorunda kalmıyorsunuz (buna dikkat edin)
Durun, bir saniye.
Evet.
“Eğer MEAI’yi tanımıyorsanız Agent Framework size ağır gelebilir. Önce
IChatClient‘i sindirin, sonra ajanlara geçin. Sırayı bozmayın.” — Sahada öğrendiğim acı ders.
Kısacası, açık konuşayım, ben de ilk denemede acele edip doğrudan ajan tarafına atlamanın pek iyi fikir olmadığını gördüm; önce chat client akışını kafaya oturtunca her şey daha anlamlı geliyor (özellikle kimlik doğrulama, endpoint yönetimi ve deployment adı gıbı ufak görünen ama işi bozan parçalar), yoksa insan “niye çalışmadı şimdi?” diye kendi kendine söylenip duruyor.
Tool calling: işin püf noktası burada
Bir ajanı ajan yapan şey, kendi başına araç kullanabilmesi. Yanı “fonksiyon çağrısı”. Kısacası bu iş, modele sadece konuşma değil, hareket etme alanı da vermek demek. Modeli bir kasap bıçağıyla değil, isviçre çakısıyla donatıyorsun aslında. Fena benzetme değil.
Geçen hafta sigorta projesinde tam olarak şu sorunla karşılaştık: Müşteri “X poliçemde ne kadar prim ödemişim, son 3 yılı listele” diyor (ciddiyim). Bunun cevabı modelin eğitim verisinde yok, olması da imkansız. Ne yapıyoruz? Modele bir GetPaymentHistory(string policyId, int years) fonksiyonu tanıtıyoruz. Ajan kendi karar veriyor: “Bu soruya cevap vermek için bu tool’u çağırmam lazım.” İşte olay bu kadar net. Ama dür, her şey o kadar pürüzsüz de değil; tool’u yanlış tarif edersen model gayet rahat şekilde yanlış kapıyı çalıyor.
using System.ComponentModel;
using Microsoft.Agents.AI;
[Description("Belirtilen poliçe için son N yılın prim ödemelerini döndürür.")]
static string GetPaymentHistory(
[Description("Poliçe numarası")] string policyId,
[Description("Kaç yıl geriye gidilecek")] int years)
{
// Burada gerçek veritabanı çağrın olacak
return $"{policyId} için {years} yıllık ödeme geçmişi:...";
}
var agent = chatClient.AsAIAgent(
instructions: "Sigorta müşteri temsilcisisin. Tool'ları gerektiğinde kullan.",
tools: [AIFunctionFactory.Create(GetPaymentHistory)]);Burada kritik nokta: [Description] attribute’larını asla ihmal etme. Modelin tool’u doğru zamanda çağırması, açıklamanın kalitesine bağlı. Ben ilk projede “yazsam ne ölür, yazmasam ne ölür” diye geçmiştim, sonuçta ajan yanlış tool’u çağırmaya başladı. Description’ları düzelttim, hallolduk. Hatta biraz şaşırdım açıkçası; tek farkın birkaç kelime olduğunu sanıyorsun ama davranış baya değişiyor (ben de ilk duyduğumda şaşırmıştım). Şey gıbı, küçük ayar büyük dert çözüyor.
Peki neden?
Ne tür araçlar bağlanır?
- Yerel C# fonksiyonları — en basit hâli, yukarıdaki örnek
- HTTP API çağrıları — REST endpoint’leri tool’a sarılabilir — ciddi fark yaratıyor
- MCP sunucuları — Model Context Protocol ile dış dünya entegrasyonu (bu konuda .NET’te MCP Tool Çağrılarını AGT ile Yönetmek: Saha Notları yazımda detayına girmiştim) — ciddi fark yaratıyor
- VectorData üzerinden RAG araçları — bilgi tabanı sorgulama
Bunların hepsi aynı mantığa çıkıyor aslında: model bir şeyi bilmiyorsa tahmin etmeye çalışmıyor, gidip soruyor. Güzel tarafı bu. Peki neden önemli? Çünkü üretim ortamında uydurma cevap istemiyorsun; doğru kaynaktan veri çekip dönmesini istiyorsun. Yanı işin aslı şu: tool calling olmadan ajan yarım kalıyor, ama tool’ları fazla serbest bırakırsan da ortalık biraz karışabiliyor (ki bu çoğu kişinin gözünden kaçıyor)
Kendi deneyimimden konuşuyorum, Evet. mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımızda bu konuya da değinmiştik.
Hafıza meselesi: thread’ler ve conversation state
Şimdi işin en çok atlanan kısmına gelelim. Bir ajan, tek atımlık soru-cevap için değil, bir diyalog yürütmek için var. “Az önce bahsettiğin poliçeyi bir daha söyler mısın?” dediğinde, o “az önce” kısmını hatırlaması lazım. Yoksa ortada akıllı görünen ama hafızasız bir şey kalıyor.
Agent Framework bunu AgentThread kavramıyla çözüyor:
var thread = agent.GetNewThread();
await agent.RunAsync("Merhaba, ben Aşkın. İstanbul'dan yazıyorum.", thread);
await agent.RunAsync("Hangi şehirden olduğumu hatırlıyor musun?", thread);
// "Evet, İstanbul'dan yazdığınızı söylemiştiniz." der.Buraya kadar güzel gidiyor. Ama production’a çıkınca tablo değişiyor, çünkü thread’i nereye koyacağınız ayrı mesele; in-memory tutarsanız uygulama yeniden başlayınca uçup gidiyor, kullanıcı sayısı artınca da iş biraz saçma bir noktaya geliyor (şaşırtıcı ama gerçek). Bizim lojistik projesinde ilk başta in-memory ile ilerledik, demo tarafında her şey sorunsuzdu. Sonra kullanıcı sayısı 50’yi geçince Redis’e taşıdık. Açık konuşayım, orada rahatladık; bence en temiz yol da bu — thread’leri serialize edip Redis ya da Cosmos DB’de saklamak. langchain-azure-cosmosdb: Tek Veritabanıyla Agent. RAG yazımda buna değinmiştim, mantık aslında aynı yere çıkıyor.
Multi-agent: işin gerçekten ilginçleştiği yer
Tek ajan iyi hoş da, kompleks işlerde bir yerde patlıyor. “Bu işi yap, sonra şunu doğrula, sonra raporla” gıbı senaryolarda her şeyi tek ajana yıkınca, prompt şişiyor, hata ihtimali artıyor, bir de üstüne debug ederken insanın kafası karışıyor (inanın bana). Çözüm? Uzmanlaşmış birkaç ajan ve aralarında düzgün bir orkestrasyon.
Yanı, Agent Framework’ün Workflow sistemi tam burada devreye giriyor. Graph tabanlı bir yapı kuruyorsun; ajanları node olarak koyuyorsun, aralarındaki akışı da edge’lerle tanımlıyorsun. Tahmin eder mısınız? Kulağa teorik geliyor ama pratikte baya iş görüyor, yanı işin aslı şu: görevleri bölüyorsun, herkes kendi payına düşeni yapıyor, sonra sistem toparlayıp ilerliyor (şaşırtıcı ama gerçek) Daha fazla bilgi için Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımıza bakabilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
| Pattern | Kullanım Senaryosu | Ne Zaman Tercih Et |
|---|---|---|
| Sequential | Adım adım pipeline (yaz → düzelt → yayınla) | Lineer iş akışları |
| Concurrent | Aynı veriyi farklı uzmanlara gönder | Çoklu perspektif lazımsa |
| Group Chat | Ajanlar bir konuyu tartışıyor, bir moderatör var | Karar verme, brainstorm |
| Handoff | Bir ajan başka ajana iş devrediyor | Eskalasyon, uzmanlık gerektiren akış |
Bir şey dikkatimi çekti: Lojistik projesinde Handoff pattern’i kullandık. Müşteri çağrısı önce TriageAgent‘a düşüyor; konu kargo takibiyse TrackingAgent’a, fatura ile ilgiliyse BillingAgent‘a, şikayetse EscalationAgent‘a aktarıyor (ki bu çoğu kişinin gözünden kaçıyor). Her ajan kendi alanında dar ama net çalışıyor; prompt kısa kalıyor, tool seti minimal oluyor, hani gereksiz kalabalık da ortadan kalkıyor. Sonuç? İlk hâlinde tek ajanla %71 olan doğru cevap oranı multi-agent’a geçince %89’a çıktı. Token maliyeti de düştü çünkü her çağrıda devasa system prompt göndermiyoruz. Evet, fark ediyor.
Neyse, peki neden?
Çünkü her işi aynı ajana yükleyince hem karar kalitesi düşüyor hem de zincirin nerede koptuğunu anlamak zorlaşıyor. Burada biraz parçalamak iyi geliyor; az önce “tek ajan yeter” gıbı düşünseniz bile, iş büyüyünce o fikir pek tutmuyor. Neyse uzatmayayım, multi-agent yaklaşımı tam da bu yüzden daha temiz duruyor.
Kısacası, tam da öyle. VSTest Newtonsoft.Json Bağımlılığını Bırakıyor: Etkisi Ne? yazımızda bu konuya da değinmiştik.
Türkiye’deki kurumsal yapılar için bir parantez
Şimdi biraz lokal gerçeklikten konuşalım. Türkiye’de Azure OpenAI deployment’ları çoğu zaman West Europe ya da Sweden Central üzerinden dönüyor, çünkü işin hem servis tarafı hem de bölgesel erişim tarafı orada daha rahat akıyor. KVKK devreye girince bazı bankalarla kamu kurumları “veri yurt dışına çıkmasın” diye frene basıyor, işte tam burada Agent Framework tek başına sihirli bir çözüm vermiyor, çünkü mesele model katmanında kalıyor. Yine de framework model-agnostic olduğu için, yarın öbür gün yerli LLM sağlayıcılarına (BTK destekli projeler, T3 AI. Benzeri) geçiş yaptığınızda kodun büyük kısmı aynı kalabiliyor; açık konuşayım, bu baya iyi bir sigorta gıbı duruyor. Bu konuyla ilgili Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşti yazımıza da göz atmanızı tavsiye ederim.
Bir de şu var. Kurumsal müşterilerde gördüğüm tablo biraz ilginç (ciddiyim). Türkiye’de “ajan” konsepti hâlâ kenardan izleniyor; CTO’lar da çoğu zaman “biz daha chatbot’a yeni geçtik” deyip konuyu kapatıyor. Ben işe tersini söylüyorum, hatta bazen fazla net konuşuyorum: chatbot mimarisinin üstüne yıllarca biriken teknik borcu sonra temizlemek çok yorucu oluyor (hele süreçler büyüdüyse daha da can sıkıyor), o yüzden doğrudan ajan mimarisiyle başlamak bana daha mantıklı geliyor. Şimdi, siz ne dersiniz?
Maliyet tarafı: TL bazında ne tutuyor?
Açık konuşayım, fiyatlandırma ilk bakışta biraz kafa karıştırıyor. Mesela ortalama bir senaryo — en azından ben öyle düşünüyorum — alalım: gpt-5.4-mini deployment’ı var, günde yaklaşık 2000 kullanıcı sorusu geliyor, multi-agent yapısı çalışıyor (ortalama 2.3 ajan/soru), üstüne tool calling de açık; ay sonu fatura kabaca 180-220 dolar bandına oturuyor, TL karşılığı da 6.500-8.000 TL civarı gezebiliyor. Bu rakam kulağa az buz gelmiyor. Bir junior developer’ın yarım haftalık maliyetini düşününce insan ister istemez “hmm, fena değilmiş” diyor; tabii tutarlı bir use case varsa (ben de ilk duyduğumda şaşırmıştım)
Bütçe dar işe önce küçük başlayın. Neden önemli bu? gpt-5.4-mini yerine gpt-4o-mini ile girin, multi-agent kısmını sonra açın; hatta isterseniz tool sayısını da kısın çünkü her tool tanımı her çağrıda token’a yazılıyor ve bu detay bazen sessizce faturayı şişiriyor. Bu konuyla ilgili Visual Studio 2026 Nisan: Copilot Agent’ları Devreye Girdi yazımıza da göz atmanızı tavsiye ederim.
Pratik başlangıç rehberi: ilk haftanız
- Gün 1-2: MEAI’yi önce bir kenara not edin.
IChatClientile basit bir konsol uygulaması yazın, sonra yapay zekayı HTTP üzerinden çağırma alışkanlığını bırakın; işin aslı, ilk günlerde amaç gösterişli şeyler yapmak değil, akışın nerede kırıldığını kendi gözünüzle görmek. - Gün 3: İlk ajanınızı kurun. Sadece system prompt ile başlayın, tool eklemeyin; evet, biraz sade kalıyor ama tam da bu yüzden neyin çalıştığını daha net görüyorsunuz.
- Gün 4: Bir tane yerel C# fonksiyonunu tool olarak bağlayın. Description’ları özenli yazın, çünkü model bazen en küçük ipucunu kapıyor (bazen de saçma yere takılıyor, o ayrı mesele). — ciddi fark yaratıyor
- Gün 5: Thread’leri Redis’e taşıyın. Conversation persistence kurun; hani şu “oturum gitti mi her şey sıfırlanıyor” hissi var ya, önü erkenden çözmek baya iş görüyor. (bence en önemlisi)
- Hafta 2: Multi-agent workflow’a geçin. Önce sequential deneyin, sonra handoff’a bakın; tersinden başlarsanız kafa karışıyor, açık konuşayım, ekipte herkes aynı anda farklı şeyi tartışmaya başlıyor. — bunu es geçmeyin
- Hafta 3: Observability ekleyin — OpenTelemetry entegrasyonu hazır geliyor, kullanın. Bu kısmı atlayan çok kişi gördüm, sonra da “neden yavaşladı” diye logların içinde kayboluyorlar.
Bu sıralamayı bozarsanız zorlanırsınız. Ben bunu kendi ekibimde acı tecrübeyle öğrendim — junior bir arkadaşa “doğrudan multi-agent’a geç” dedim, iki gün sonra “abi anlamadım hiçbir şey” diye geldi; haklıydı, çünkü ortada tutunacak bir zemin yoktu.
Bakın, peki neden? Çünkü burada mesele sadece kod yazmak değil, önce zihinde küçük bir iskelet kurmak gerekiyor. Sonra üstüne kat çıkıyorsunuz; önce tek ajan, sonra tool, ardından thread yönetimi, en son da çoklu ajan akışı ve gözlemlenebilirlik geliyor.
Tam da öyle.
Hata anekdotu: yaşadığım bir tuzak
İlk Production deploy’unda garip bir şeyle karşılaştım. Ajan, tool çağrısından dönen JSON’u bazen yanlış parse ediyordu; hata mesajı da şuydu: The model returned a tool call with malformed arguments. Saatlerce bunun peşinde koştum. Sonra bir anda fark ettim, işin aslı tool fonksiyonumda decimal tipinde bir parametre vardı ve model de bazen string, bazen number dönüyordu. decimal yerine double yaptım, mesele kapandı. Belki çok basit duruyor ama saatlerimi yedi. Sizin zamanınızı yemesin.
Peki, bir de şu taraf var: .NET’in Composable AI Stack’i: ConferencePulse Vakası yazımda da değindiğim gıbı, framework parçaları aslında fena değil, hatta kendi içinde baya konuşuyorlar. Hata mesajları bazen insanı duvara toslatıyor. EnableSensitiveDataLogging‘i development’ta açık tutun, yoksa şey, nerede koptuğunu anlamak biraz sürüyor. Peki neden? Çünkü log görmeden tahmin yürütüyorsunuz, sonra da yanlış yere dalıp gidiyorsunuz. Evet.
Kimler için, kimler için değil?
Net konuşayım. Eğer ekip 2 kişiyse ve hâlâ MVP peşindeyseniz, multi-agent tarafına hemen dalmayın (ben de ilk duyduğumda şaşırmıştım). Tek ajanla, birkaç tool ekleyerek, gayet yol alırsınız; hatta çoğu zaman işin %80’ını zaten orada kapatırsınız, sonra bir bakmışsınız gereksiz karmaşa yüzünden hız düşmüş. Ama 10+ kişilik bir ürün ekibiniz varsa. AI artık sadece bir özellik değil de ürünün omurgası hâline geldiyse, Agent Framework bence kaçınılmaz oluyor. Mimarı tarafı başka türlü pek ölçeklenmiyor, işin aslı bu.
Bence framework henüz tam oturmuş değil. Workflow editör’ü mesela görsel olarak yok; Semantic Kernel tarafında vardı, burada işe daha gelmemiş durumda. Debugging deneyimi de açık konuşayım biraz daha cilaya ihtiyaç duyuyor. Yanı loglara bakıyorsunuz, sonra tekrar akışı kafada kuruyorsunuz, biraz uğraştırıyor; ama yön fena değil, ekosistem de hızlı büyüyor, şaşırdım doğrusu. Ben yine de production’a koyarken temkinli giderim diyorum. Siz ne dersiniz?
Evet, doğru duydunuz.
Sıkça Sorulan Sorular
Microsoft Agent Framework, Semantic Kernel’ın yerini mi alıyor?
Kısaca: evet. Microsoft, hani Semantic Kernel ve AutoGen’den öğrendiklerini alıp Agent Framework çatısı altında birleştirdi. Yeni projelerde bence direkt buradan başlamak mantıklı. Mevcut Semantic Kernel kodlarınız çalışmaya devam ediyor zaten — aslında açıl bir migration baskısı yok, sakın olabilirsiniz.
Sadece Azure OpenAI ile mi çalışıyor?
İlginç olan şu ki, Hayır, çalışmıyor. Framework IChatClient üzerine kurulu olduğu için OpenAI, Azure OpenAI, Anthropıc Claude, Google Gemini, hatta Ollama üzerinden lokal modeller (Llama, Phi vs.) ile de gayet güzel çalışıyor (şaşırtıcı ama gerçek). Provider değiştirmek istediğinizde genelde tek bir satır değişiyor — yanı düşündüğünüzden çok daha kolay.
Production’da hangı observability araçlarını kullanıyorsunuz?
Bi saniye — Application Insights + OpenTelemetry kombinasyonu kullanıyoruz. Agent Framework OTel sinyallerini zaten hazır üretiyor — token kullanımı, tool çağrı sayıları, latency dağılımı hepsi geliyor. Açıkçası Grafana’da dashboard kurmak yarım günü geçmedi, beklediğimden hızlıydı.
Multi-agent yapısında loop’a girme riski var mı?
Ne yalan söyleyeyim, Var, bu konuda dikkatli olmak lazım. İki ajan teorik olarak birbirine sürekli iş havale edebilir. Bunun için framework içinde MaxIterations ve MaxTokens guardrail’leri mevcut — mutlaka set edin, mesela biz 15 iterasyonu aşan workflow’ları otomatik kestiriyoruz ve alarm gönderiyoruz. Tecrübeme göre bunu es geçince pişman oluyorsunuz.
Küçük bir ekip için en hızlı başlangıç yolu nedir?
Tek ajan + 2-3 tool + Azure OpenAI gpt-4o-mini kombinasyonuyla bir hafta içinde POC çıkarabilirsiniz rahatlıkla. Hani ne farkı var diyorsunuz, değil mi? Bence multi-agent ve workflow’a ihtiyacınız netleşmeden o tarafa geçmeyin — yanı gereksiz karmaşıklığa girmeye değmiyor.
Kaynaklar ve İleri Okuma
Hani, Microsoft Agent Framework – Building Blocks for AI Part 3 (Jeremy Likness)
Microsoft Agent Framework Resmî Dokümantasyonu
Microsoft Agent Framework GitHub Reposu
Hani, Microsoft.Extensions.AI 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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
