A2A v1 ile .NET’te Çapraz Platform Agent İletişimi
Bir süredir agent tabanlı yapay zekâ sistemleriyle uğraşıyorsanız, ki ben baya uğraşıyorum, şunu fark etmişsinizdir: tek bir agent ile prototip çıkarmak kolay (evet, doğru duydunuz). Asıl mesele başka. Bu ne anlama geliyor? Birden fazla agent’ı farklı platformlardan, farklı ekiplerden, hatta farklı şirketlerden bir araya getirmeye kalkınca iş karışıyor; burada A2A Protocol v1.0 devreye giriyor ve açık konuşayım, bu çevre için HTTP’nın web servislerinde yaptığı şeye benzer bir rol oynayabilir.
📋 İçindekiler
- Agent Interop Neden Bu Kadar Kritik?
- Microsoft Agent Framework’te A2A Nasıl Çalışıyor?
- A2A v1’deki Önemli Yenilikler
- Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
- Pratikte İlk Adımlar: Ne Yapmalısınız?
- Beklentilerim ve Eleştirilerim
- Enterprise vs Startup: Kime Ne Uygun?
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Microsoft Agent Framework’ün hem client hem server tarafındaki.NET paketleri artık A2A v1 SDK’ya güncellendi. Evet, bu önemli. Lafı dolandırmadan söyleyeyim: agent’lar arası iletişimi bir düzene sokuyor ve bunu AWS, Google, IBM, Cisco, Salesforce gibi isimlerin de içinde olduğu bir teknik yönlendirme komitesi destekliyor; yanı sadece Microsoft’un kendi içinde dönen bir konu değil, baya daha geniş bir çerçeve var.
Agent Interop Neden Bu Kadar Kritik?
Geçen ay bir finans kuruluşunda danışmanlık yaparken tam olarak şu sahneyle karşılaştım: müşterinin satın alma agent’ı, tedarikçinin uyumluluk servisine bakması gerekiyordu (bu konuda ikircikliyim). Tedarikçi bambaşka bir tarafta, Google Cloud üzerinde kendi agent yapısını kurmuş; iki ekip de oturup custom REST endpoint’leri yazdı, mapping yaptı, hata yönetimini de elle ördü. Sonuç? Üç hafta gitti, sadece iki agent birbirini anlayabilsin diye.
İşin aslı biraz burada düğümleniyor. Multi-agent sistemler gerçek hayatta tek ekibin içinde kalmıyor, tek vendor’ın sınırında da durmuyor; bir müşteri destek agent’ı başka departmandaki uzmana yönlenmek istiyor, bir tedarik zinciri agent’ı da lojistik partnerinin agent’ıyla konuşmak zorunda kalıyor. Her seferinde custom entegrasyon kodu yazmak… hani açık konuşayım, baya yorucu ve gereksiz yere vakit yiyor.
Bunu bir de Türkiye’deki şirketler açısından düşünün. Büyük holdinglerde işler daha da karışık oluyor; bir grup şirketi Azure’da, diğeri AWS’de, üçüncüsü on-premise tarafında takılıyor. A2A gibi açık bir standart olmadan bu agent’ları birbirine bağlamak — dur bir saniye, “konuşturmak” bile tam oturmuyor — resmen ayrı proje çıkarıyor. A2A v1 tam da bu sıkıntıyı azaltmayı hedefliyor.
Ve işler burada ilginçleşiyor.
A2A Protokolü, agent’lar arası iletişim için HTTP ve REST’in web servisleri için yaptığını yapmayı hedefliyor: platformdan bağımsız, vendor’dan bağımsız, dil ve framework’ten bağımsız bir iletişim standardı.
Microsoft Agent Framework’te A2A Nasıl Çalışıyor?
Beni en çok çarpan yer burası öldü. A2A desteği framework’e öyle gömülmüş ki, (söylemesi ayıp) interop neredeyse bedavaya geliyor; kodu baştan şekillendirmeniz gerekmiyor, ayrı bir programlama modeli ezberlemeniz de gerekmiyor. İşin aslı, bu kısmı görünce bir an durup “tamam, burada iş var” dedim.
Client Tarafı: Uzak Agent = Yerel Agent
Şahsen, Uzak bir A2A agent’ı, kodunuzun içinde bildiğiniz AIAgent gibi davranıyor. Aynı RunAsync, aynı streaming, aynı session yönetimi. Bugün Azure OpenAI agent’ı çağırıyorsanız yarın partner tarafındaki A2A agent’ına geçebiliyorsunuz (çağıran koda dokunmadan). Açık konuşayım, bu soyutlama baya iş görüyor.
Peki neden?
// Uzak bir A2A agent'ı yerel agent gibi kullanma
var remoteAgent = new A2AAgent("https://partner-api.example.com/a2a");
// Aynı RunAsync ile çağırın — fark yok
await foreach (var response in remoteAgent.RunAsync(
"Tedarikçi uyumluluk durumunu kontrol et",
cancellationToken))
{
Console.WriteLine(response.Content);
}
// Veya multi-agent workflow'da yan yana kullanın
var workflow = new SequentialAgentWorkflow(
localAzureAgent, // Kendi Azure OpenAI agent'ınız
remoteAgent, // Partner'ın A2A agent'ı
anotherLocalAgent // Başka bir yerel agent
);
Ha bu arada, bu agent’ları sequential, concurrent, handoff veya group chat modunda yan yana koyabiliyorsunuz. Yanı A2A agent’ları workflow içinde kenarda duran bir ek bileşen değil; tam tersine oyunun içine giriyorlar (en azından benim deneyimim böyle). 2024’ün sonlarında benzerini elle kurmaya kalkmıştım — inanın 500 satır glue code çıkmıştı ortaya. Şimdi bunu 10-15 satırda toparlayabiliyorsunuz. Evet.
Server Tarafı: Kendi Agent’ınızı A2A Endpoint’e Çevirin
Ters taraf da çalışıyor tabi. Zaten elinizde olan herhangi bir AIAgent — ister Microsoft Foundry’de olsun, ister Anthropic’te, ister AWS Bedrock’ta — birkaç satırlık hosting koduyla A2A endpoint’i olarak dışarı açılabiliyor. Protokol için ayrıca boilerplate yazmıyorsunuz, agent’ı yeniden yazmanız da gerekmiyor. Peki neden güzel? Çünkü mevcut işi çöpe atmadan dış dünyaya açılabiliyorsunuz.
Logosoft’ta bir telekomünikasyon projesinde bunu test ettik. Müşterinin iç kullanım için yazılmış bir sınıflandırma agent’ı vardı; bunu dış partnerlere açmak istiyorlardı ama güvenlik kaygıları. Entegrasyon maliyeti yüzünden sürekli bekletiyorlardı. A2A hosting paketiyle bu agent’ı — ciddi söylüyorum — yarım günde dışarıya açabildik. Bu ne anlama geliyor? Tabiî production-ready hâle gelmesi biraz daha sürdü, çünkü orada işler her zaman ilk bakışta göründüğü kadar pürüzsüz olmuyor; yine de temel iletişim o kadar kolay kuruldu ki biz de şaşırdık açıkçası.
İşte tam da bu noktada devreye giriyor.
A2A v1’deki Önemli Yenilikler
v0.3 draft’ını kullanıyorduysanız — ki ben kullanıyordum. Birkaç kez başıma iş açtı — v1 ciddi iyileştirmeler getiriyor. Hepsini tek tek anlatayım:
| Özellik | v0.3 Draft | v1.0 Stable |
|---|---|---|
| Stabilite | Draft, kırıcı değişiklikler olabilir | Stabil, production-ready |
| Güvenlik | Temel auth desteği | OAuth 2.0, Bearer token, mTLS |
| Streaming | Sınırlı | Tam SSE desteği |
| Keşif (Discovery) | Basit agent card | Zengin metadata, capability bilgisi |
| Enterprise Hazırlık | Deneysel | Rate limiting, telemetri, hata yönetimi |
Güvenlik tarafı beni özellikle sevindirdi. v0.3’te auth mekanizmaları biraz belirsizdi — AZ-500 sertifikası olan biri olarak söylüyorum, kurumsal müşterilere “evet bu güvenli” demek zor oluyordu. v1’de OAuth 2.0 ve mTLS desteği gelince iş değişti. Artık bir bankacılık müşterisine bu protokolü önermekten çekinmiyorum.
Şöyle ki, Bir de şu var: agent discovery mekanizması çok daha zengin hâle gelmiş. Agent Card denen yapı, bir agent’ın ne yapabildiğini, hangi yeteneklere sahip olduğunu detaylı şekilde tanımlıyor. Hmm, bir düşüneyim… Evet, bunu REST API’lerdeki OpenAPI/Swagger spec’ine benzetebilirsiniz. Agent’ınızın “menüsü” gibi bir şey.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Bakın şimdi, Türkiye’de agent teknolojisinin yayılması biraz garip ilerliyor. Büyük bankalarla telekom şirketleri işi hızlandırmış durumda,. Orta ölçekli firmaların önemli kısmı hâlâ “ChatGPT API’sını nasıl çağırırım” seviyesinde dolaşıyor. Bu da tuhaf değil. Yine de A2A gibi bir standart, orta vadede buradaki ekosistem için baya kritik olacak.
Neden mi? Şöyle düşünün: Türkiye’de holding yapısı çok yaygın, yanı tek çatı altında 15-20 şirket görmek kimseyi şaşırtmıyor ve her birinin IT altyapısı ayrı telden çalıyor; bugün bu şirketlerin agent’larını birbirine bağlamak isteseniz, her bağlantı için ayrı entegrasyon projesi yazmanız gerekiyor, iş uzuyor, ekip yoruluyor, sonra bir bakıyorsunuz sadece veri değil süreç de dağılmış. A2A standardı olgunlaştığında — v1 bu yönde ciddi bir adım sayılır — bu holdingler agent’larını çok daha rahat konuşturabilecek.
Bunu biraz açayım.
Maliyet tarafını da es geçmeyelim. Azure’da agent servisleri kullandığınızda her API çağrısı token bazlı faturalanıyor; A2A ile uzak agent’lara yapılan çağrılar da benzer şekilde hem sizin tarafta hem karşı tarafta maliyeti tetikliyor,. Zincir uzadıkça fatura da hafifçe kabarıyor. Küçük ekipseniz ve bütçe dar işe önce kendi agent’larınızı toparlayın, sonra A2A entegrasyonlarına geçin; yoksa güzel fikir var ama kasada yüzünüz düşebilir (ciddiyim). Enterprise tarafında işe durum biraz farklı: standartlaşma uzun vadede custom entegrasyon maliyetlerini aşağı çekiyor. Bir müşterimde yapılan hesaplamaya göre 8 farklı agent entegrasyonu için yıllık custom geliştirme maliyeti yaklaşık 400 bin TL idi; A2A ile bunun yarısına inmek mümkün görünüyor.
Pratikte İlk Adımlar: Ne Yapmalısınız?
Denemek istiyorsanız, bence fazla düşünmeyin; bir yerden başlayın. İşe şu adımlarla girin:
- NuGet paketlerini yükleyin:
Microsoft.AgentFramework.A2A.Agent(client) veMicrosoft.AgentFramework.A2A.Hosting(server) paketlerinin v1 sürümlerini alın. - Basit bir agent oluşturun: Elinizde mevcut bir
AIAgentvarsa, önü A2A endpoint’i olarak expose edin. Yoksa önce sade bir Azure OpenAI agent’ı kurun, sonra üstüne gidin. (bence en önemlisi) - Agent Card tanımlayın: Agent’ınızın neleri yapabildiğini, hangi görevleri kabul ettiğini ve metadata tarafını anlatan bir Agent Card yazın.
- Test edin: Kendi iki agent’ınızı birbirine bağlayıp A2A konuşmasını deneyin. Streaming kısmına da bakın, session yönetimini de kurcalayın.
- Güvenliği yapılandırın: Production’a çıkmadan önce OAuth 2.0 ya da mTLS’i mutlaka devreye alın. Sonra bakarsınız rahat edersiniz. (bu kritik)
Bakın, Ha, az kalsın unutuyordum: daha önce CodeAct ile AI Agent’ları Hızlandırmak: %50 Daha Az Gecikme yazımda agent performans optimizasyonundan bahsetmiştim. E peki, sonuç ne öldü? A2A entegrasyonlarında da latency işi yine kritik, hatta bazen asıl dert o oluyor; o yazıdaki prensipleri burada da uygulayabilirsiniz, baya iş görüyor.
Bir de şöyle bir şey var: bu protokolü ilk denediğimde agent discovery kısmında biraz tökezledim. Agent Card’ın JSON formatında bazı zorunlu alanları atlamışım ve hata mesajı pek yardımcı değildi, sadece “Invalid Agent Card” yazıyordu; yanı insanın canı sıkılıyor biraz. Çözüm aslında basit: capabilities ve endpoints alanlarını mutlaka doldurun, boş bırakmayın. Bu küçük detay bana 2 saat kaybettirdi.
Beklentilerim ve Eleştirilerim
Güzel bir özellik, evet. Ama ham tarafı da var, önü saklamayayım.
İlk mesele şu: A2A v1’i production’da kullanan büyük ölçekli örnek sayısı hâlâ az. Protokol stabil deniyor, tamam, ama gerçek dünyada binlerce concurrent agent konuşurken nasıl davranacak, işte orası biraz sisli kalıyor; kağıt üstünde iyi dürüyor, pratikte işe göreceğiz artık.
İkincisi,.NET dışındaki dil desteği aynı seviyede değil. Python ve Java SDK’ları var, var olmasına var da,.NET kadar “first-class” hissettirmiyor; ekibiniz çok dilli bir yapıya sahipse bu can sıkabiliyor. Üçüncü konu — ve açıkçası benim en çok takıldığım yer — debugging ile observability tarafı henüz tam oturmamış. İki agent arasındaki iletişimde bir şey ters giderse, hatanın tam nerede patladığını bulmak zorlaşıyor; distributed tracing tarafı gelecek sürümlerde biraz daha toparlanırsa iyi olur.
Bir de şunu ekleyeyim: AI Agent’larda Sohbet Geçmişi: Nerede Saklamalı? yazımda agent state yönetiminden bahsetmiştim. A2A iletişiminde session ve state yönetimi hâlâ en karışık başlıklardan biri. v1 bu tarafta bazı iyileştirmeler getiriyor, tamam, ama cross-platform session devri kısmında biraz daha yol lazım gibi dürüyor.
Az önce “debugging zor” dedim ya, aslında küçük bir düzeltme yapayım — v0.3’e göre baya daha iyi durumda. v0.3’te hata yönetimi neredeyse yok gibiydi; şimdi en azından yapılandırılmış hata kodları ve telemetri desteği var. Yanı gidişat fena değil.
Araya gireyim: Tam da öyle.
Enterprise vs Startup: Kime Ne Uygun?
Küçük bir ekipseniz, iki ya da üç agent ile gidiyorsanız, açık konuşayım, A2A’ya hemen atlamanız gerekmeyebilir (buna dikkat edin). Agent’lar zaten aynı codebase içinde yaşıyorsa ve direkt method call ile haberleşiyorsa, iş çoğu zaman kendi kendine dönüyor. A2A’nın getirdiği overhead var ya, agent card tanımı, discovery, protocol negotiation falan, küçük ölçekte biraz fazla süs gibi durabiliyor.
Bunu yaşayan biri olarak söyleyeyim, Evet. Ama kurumsal tarafta tablo değişiyor.
Birden fazla ekip agent geliştiriyorsa, farklı vendor’ları yan yana kullanıyorsanız ya da partner’larla agent entegrasyonu planlıyorsanız, bence A2A v1’e şimdiden bakmak lazım. Çünkü bu işin standardı oturacak gibi dürüyor (tamam, yarın değil belki. Gidişat o), erken adapte olanlar da elbette bir adım öne geçiyor. REST API’lerin ilk çıktığı günleri düşünün; “neden bu kadar formalize ediyoruz, direkt SOAP kullansak olmaz mı” diyenler vardı. Şimdi işe REST’sız bir dünya pek kimseye mantıklı gelmiyor.
Burada, ha bu arada, .NET 10’da API Versiyonlama ve OpenAPI Entegrasyonu: Pratik Rehber yazısına da göz atın — A2A endpoint’leriniz için versiyonlama stratejisi kurarken oradaki yaklaşım baya iş görüyor. Sız ne dersiniz?
Sıkça Sorulan Sorular
A2A Protokolü sadece Microsoft agent’ları için mi çalışıyor?
Ne yalan söyleyeyim, Hayır, hiç de öyle değil. A2A aslında açık bir standart — hani AWS, Google, IBM, Salesforce gibi büyük isimlerin de teknik yönlendirme komitesinde yer aldığı bir şey bu (evet, doğru duydunuz). Yanı herhangi bir A2A-uyumlu client veya server ile rahatça iletişim kurabiliyorsunuz, vendor bağımsız çalışıyor.
v0.3’ten v1’e geçiş zor mu?
Doğrusu, Orta zorlukta diyebilirim (buna dikkat edin). NuGet paketlerini güncellemek kolay kısım zaten. Ama Agent Card formatında ve bazı protocol davranışlarında kırıcı değişiklikler var — bu yüzden entegrasyon testlerinizi baştan koşturmanız gerekiyor. Tecrübeme göre 1-2 günlük bir migration süreci genellikle yeterli oluyor.
A2A ile MCP (Model Context Protocol) arasındaki fark nedir?
MCP, mesela bir agent’ın dış araçlara ve veri kaynaklarına erişimini standardize ediyor — yanı agent-to-tool iletişimi bu. A2A işe agent-to-agent iletişimini standardize ediyor. Aslında ikisi birbirinin rakibi değil, birbirini tamamlıyor (inanın bana). Bir agent MCP ile araçlarına erişirken, A2A ile de diğer agent’larla konuşabiliyor. İkisine birden ihtiyaç duyabilirsiniz.
A2A v1 production’da kullanılabilir mi?
Microsoft ve diğer komite üyeleri “production-ready” diyor. OAuth 2.0, rate limiting, telemetri gibi enterprise gereksinimleri de karşılanmış durumda. Açıkçası büyük ölçekli production senaryolarında henüz sınırlı sayıda referans var — bu biraz düşündürücü. Bence pilot projelerle başlayıp kademeli olarak genişletmek en mantıklısı.
A2A kullanmak için.NET zorunlu mu?
Hayır, zorunlu değil. A2A bir protokol standardı,.NET işe Microsoft’un resmî SDK uygulamau. Python, Java ve diğer dillerde de SDK’lar var ya da geliştirme aşamasında. Ama şu an en olgun ve en iyi desteklenen implementasyon yine de.NET tarafında.
Kaynaklar ve İleri Okuma
Şöyle söyleyeyim, A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for.NET — Microsoft DevBlogs
A2A Protocol Resmî Spesifikasyonu — Google GitHub
Microsoft Agent Framework for.NET Dokümantasyonu — Microsoft Learn
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