1.0 geldiğinde neden biraz durup bakıyorum?
Bakın şimdi, “1.0” etiketi bazen sadece pazarlama kokuyor. Ama bazı ürünlerde o sayı gerçekten bir eşik oluyor; Microsoft Agent Framework için de durum tam böyle, bu sürümle birlikte iş deneme-yanılma modundan çıkıp üretim tarafına daha net oturuyor. Ben bunu özellikle Azure tarafında çalışan ekiplerde çok net hissediyorum: stabil API, uzun vadeli destek ve sürpriz azlığı… işte asıl kıymetli olan bunlar.
Geçen ay İstanbul’da bir finans müşterisinde, küçük bir müşteri destek ajanı kurgusunu konuşurken aynı cümleyi kurdum: “PoC güzel. Prod başka.” Ekip ilk başta tek ajanla ilerlemek istiyordu. Sonra akış büyüdü, belge okuma ayrı, sınıflandırma ayrı, cevap yazma ayrı derken işin rengi değişti. Agent Framework 1.0’ın bana göre olayı tam burada başlıyor.
Peki neden?
Şunu fark ettim: Aslında — dur bir saniye, önce şunu söyleyeyim: ben bu tip duyurularda hep teknik detaydan önce operasyonel rahatlığa bakarım. Çünkü bir sistemin çalışması başka şeydir, üç ay sonra bakımının kolay olması başka şey; AZ-305 sınavına hazırlanırken de kafama en çok bu kazınmıştı, mimarı kağıt üstünde güzel olabilir ama sürdürülebilir değilse pek anlamı yok.
Bir de şu var: Microsoft’un Semantic Kernel ile AutoGen çizgisini tek SDK altında toplaması bana mantıklı geliyor. Ayrık iki yol yerine ortak zemin… hani ekiplerin kafasını karıştıran kısım biraz buydu zaten. Şimdi gel gelelim işin pratik tarafına.
Tek ajanla başlamak kolay, asıl mesele büyüyünce
İlk demo genelde hızlı çıkar. Bir işim verirsin, talimat yazarsın, model endpoint’ını bağlarsın ve hop… çalışır. Bu kötü değil, hatta bayağı iş görüyor. Ama gerçek hayatta kullanıcı sayısı artınca ya da iş süreci uzayınca tek ajan yetmiyor; orada araç çağırma, oturum yönetimi ve akış kontrolü devreye giriyor (ki bu çoğu kişinin gözünden kaçıyor)
Kendi deneyimimden örnek vereyim: 2024 sonunda Logosoft’ta bir kamu kurumuna yakın çalışan karmaşık bir doküman işleme senaryosu vardı. Tek bir asistanla başlamıştık ama sonrasında doğrulama, özetleme ve aksiyon çıkarma adımlarını ayırmak zorunda kaldık. İlk tasarım fena değildi. İkinci hafta duvara tosladık; çünkü her isteği aynı ajana yığmak işleri ağırlaştırdı (en azından benim deneyimim böyle)
Bakın, agent Framework 1.0’ın sevdiğim tarafı şu: “tek akıllı bot” fikrine takılı kalmıyor. Birden fazla uzman ajanı — en azından ben öyle düşünüyorum — yan yana koyup sıraya sokabiliyorsun ya da birbirine danışan ajanlar kurabiliyorsun. Küçük startup için bu lüks gibi görünebilir; ama enterprise tarafta tam tersine ihtiyaç oluyor (kendi tecrübem) Copilot Cloud Agent Artık İmzalı Commit Atıyor: Neyi Değiştiriyor? yazımızda bu konuya da değinmiştik.
Kısa bir not düşeyim buraya. Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor? yazımızda bu konuya da değinmiştik.
| Senaryo | Ne işe yarar? | Ben olsam ne yaparım? |
|---|---|---|
| Küçük startup | Hızlı prototip, tek ürün özelliği | Önce tek ajan + basit tool entegrasyonu |
| Büyüyen ekip | Görev ayrımı, farklı uzmanlıklar | Sekansiyel workflow ile başlayıp ölçerim |
| Enterprise | Uyum, izlenebilirlik, ölçek | A2A/MCP ve güvenlik kontrollerini erken koyarım |
A2A ve MCP neden önemli?
İlginç olan şu ki, Açık konuşayım, bazı kısaltmalar ilk bakışta insanı yoruyor. Ama A2A ve MCP gibi standartların kıymeti büyük; çünkü ajanların kendi içinde kilitli kalmasını engelliyorlar. Bir yanda farklı runtime’lar arasında konuşabilmek var, öbür yanda araçlara düzenli erişim var.
Bunu ben hep priz adaptörü benzetmesiyle anlatıyorum: Elinizde çok iyi cihaz olabilir ama fişi uymuyorsa ne olacak? Aynı mantık burada da geçerli. Agent Framework’ün cross-runtime yaklaşımı da buna benziyor; Python tarafında kurduğun şeyi .NET ekibiyle aynı masada tartışabiliyorsun.
Kod az mı? Evet. Basit mi? Evet ama…
Duyuruda gösterilen ilk agent örneği baya minimaldi; birkaç satırda ayağa kalkıyor (evet, doğru duydunuz). Bu kısmı seviyorum çünkü yeni başlayan ekipler için giriş bariyerini düşürüyor. Fakat dürüst olayım: “birkaç satır” kısmı demo içindir, üretimde tablo biraz daha kabarır.
# Python tarafında kaba iskelet
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
agent = Agent(
client=FoundryChatClient(
project_endpoint="https://your-project.services.ai.azure.com",
model="gpt-5.3",
credential=AzureCliCredential(),
),
name="HelloAgent",
instructions="You are a friendly assistant."
)İşin garibi, .NET tarafında da benzer şekilde kısa başlıyor ama sonrasında oturum yönetimi, streaming cevaplar ve fonksiyon araçları girince yapı doğal olarak büyüyor. Burada güzellik şu: dil fark etmeden benzer zihniyetle ilerleyebiliyorsun.
Ha bu arada küçük bir not: bazen geliştiriciler “çalışıyor ya yeter” diyor. E tabii lokal ortamda yeter de üretimde loglama yoksa sonra gece uc’te telefon çalar! Ben bunu iki kez yaşadım; biri Ankara’daki bir e-ticaret projesinde oldu, diğeri de Hollanda merkezli bir SaaS müşterisinde… ikisinde de sorun koddan çok gözlem eksikliğiydi. Bu konuyla ilgili GitHub Copilot CLI Kullanımını Artık Kişi Bazında Görmek Mümkün yazımıza da göz atmanızı tavsiye ederim.
Multi-agent orkestrasyon: gerçek oyun burada dönüyor
Şöyle söyleyeyim, Mesele sadece sohbet eden bir bot yapmak değil artık. Asıl soru şu: İş yükünü parçalara bölüp doğru sırada koşturabiliyor musun? Microsoft’un burada sunduğu sequential workflow yaklaşımı tam bu yüzden değerli geliyor bana. Bu konuyla ilgili GitHub Actions Nisan 2026 Güncellemeleri: Üç Küçük Ama Etkili Hamle yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim yazımıza bakabilirsiniz.
Mesela içerik üretim hattını düşünün; biri taslak çıkarır, biri marka diline uyarlar, biri güvenlik filtresi uygular, biri de son kontrol yapar (evet biraz insan ekibine benziyor). Geçen sene Nisan ayında İzmir’de görüştüğüm bir medya firmasına da aynısını önermiştim; tek ajanla her işi yaptırmaya çalışmışlardı. Cevapların tonu sürekli kayıyordu.
Bence en kritik avantajlardan biri görevleri ayrıştırınca hata ayıklamanın kolaylaşmasıdır. Hangi adım yanlış çıktıysa onu izole edersin… Yani bütün sistemi topyekûn suçlamazsın ki bu baya rahatlatıyor.
Sekansiyel akış ne zaman yeter?
Bence, Eğer işler belirgin sıradaysa sekansiyel akış çoğu zaman yeterli olur. Örneğin önce belgeyi oku, sonra özetle, ardından karar önerisi ver gibi lineer süreçlerde güzel çalışır.
Peki ne zaman yetmez?
Eğer ajanların birbirine danışması gerekiyorsa ya da paralel görevler varsa tek sıra bazen dar gelir. O noktada biraz daha gelişmiş orkestrasyon gerekir; yoksa sistem şişmeye başlar ve bakım kabusa döner.
Üretimde en pahalı hata çoğu zaman model seçimi değil… yanlış orkestrasyondur.
.NET mi Python mı? İkisi de tamam da ekip ne istiyor?
Dürüst olayım, bu sorunun cevabı teknikten çok organizasyonel oluyor çoğu zaman. Python ekibi hızlı prototipte çok rahat ederken .NET ekibi mevcut kurumsal uygulamalara gömülme konusunda kazanım sağlıyor.
Aslında, Bende kişisel olarak şöyle bir refleks oluştu: Eğer müşteri zaten Azure üzerinde .NET ağırlıklı gidiyorsa işi zorlamam. .NET ile devam ederim ki sahiplenme kolay olsun (özellikle büyük şirketlerde). Ama veri bilimi ya da araştırma odaklı küçük ekiplerde Python gayet doğal duruyor.
- Küçük ekip: Hızlı PoC için Python iyi gider.
- Kurum içi uygulama: .NET entegrasyonu çoğu yerde daha rahat olur. — bunu es geçmeyin
- Melez yapı: Aynı framework ile iki dünyayı konuşturmak güzel avantaj sağlar. — bunu es geçmeyin
Neyse uzatmayayım; benim gözümde önemli olan dil değil ekibin günlük alışkanlığıdır. Mesela bir bankacılık projesinde .NET standardize edilmişti. Kimse bundan şikayet etmiyordu çünkü operasyon basitti. Aynı senaryoyu Python’a taşısaydınız belki bilimsel açıdan hoş olurdu ama bakım tarafında ekstra pazarlık çıkardı!
Peki güvenlik ve işletim tarafında neler değişiyor?
Açık konuşayım, Agent Framework 1.0 ile birlikte güvenlik ve gözlemlenebilirlik tarafında da ciddi bir olgunlaşma var. Özellikle üretimde en çok sıkıntı çıkaran üç nokta düzelmiş görünüyor:
- Kimlik doğrulama: Azure Managed Identity entegrasyonu artık çok daha pürüzsüz çalışıyor. Geliştirme ortamında Azure CLI ile başlayıp, üretimde Managed Identity’e geçiş neredeyse tek satır değişiklik.
- Gözlemlenebilirlik: OpenTelemetry desteği kutudan çıkıyor. Token kullanımı, araç çağrıları ve ajan akış adımları izlenebilir hale geliyor. Gece üçte telefon çaldığında en azından nereye bakacağınızı biliyorsunuz.
- Hata yönetimi: Araç çağrıları başarısız olduğunda otomatik retry ve fallback mekanizmaları Framework seviyesinde var. Her ajanı ayrı ayrı korumaya almak zorunda kalmıyorsunuz.
Geçen yıl bir e-ticaret projesinde gece yarısı yaşadığımız kesinti tam da bu tür gözlemlenebilirlik eksikliğinden kaynaklanmıştı. Ajan çalışıyor gibi görünüyor ama aslında araç çağrısı sürekli timeout alıyordu; log yapısı olmadığı için bunu bulmamız saatler sürmüştü.
Sonuç: 1.0 gerçekten “1.0” mı?
Bence evet. Agent Framework 1.0 ile Microsoft, ajanları oyuncaktan üretime taşımak isteyen ekipler için ciddi bir zemin hazırlamış durumda. Tek ajanla başlayıp multi-agent orkestrasyona geçiş yolu açık; A2A ve MCP standartları sayesinde kilitlenme riski düşük; Python ve .NET ikisi de birinci sınıf vatandaş.
Tabii ki kusursuz değil — henüz topluluk ekosistemi ve hazır araç kütüphanesi olgunlaşma aşamasında. Ama temeller sağlam ve ben kişisel olarak yeni projelerde bunu tercih etmeye başladım. Sizin de en azından bir PoC ile denemenizi tavsiye ederim.
Sıkça Sorulan Sorular
Agent Framework sadece Azure ile mi çalışıyor?
Hayır, framework açık kaynak ve model bağımsız. Azure AI Foundry ile en iyi entegrasyon sağlansa da OpenAI, Anthropic veya yerel modeller de kullanılabilir. Kritik olan doğru client sınıfını seçmek.
Semantic Kernel ve AutoGen kullanıyorduk, geçiş zor mu?
Agent Framework zaten Semantic Kernel ve AutoGen’ın birleştirilmiş hali. Semantic Kernel kullanıcıları için geçiş oldukça doğal; AutoGen tarafında ise bazı API değişiklikleri var ama kavramsal olarak benzer kalıyor.
Küçük bir proje için multi-agent gerekli mi?
Kesinlikle hayır. Tek ajan ile başlamak ve ihtiyaç oldukça büyümek en doğru yaklaşım. Framework bu geçişi kolaylaştırmak üzere tasarlanmış; ilk günden karmaşık orkestrasyon kurmaya gerek yok.
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder