Vallahi, 2025’te yapay zekâ dünyasında gerçekten değişen şey nedir biliyor musunuz? “Ajan araç çağırabiliyor mu?” sorusu artık kimseyi heyecanlandırmıyor (kendi tecrübem). Kimse. Asıl mesele çok daha karmaşık bir yerde duruyor: birden fazla ajan aynı anda sahada koşarken birbirine çarpmadan, görev paylaşımını düzgünce yapıp, bir hata aldığında neredeyse tüm sistem dağılmadan ayakta kalabiliyor mu? Açık konuşayım — bu fark ilk bakışta küçücük bir nüans gibi görünüyor,. Pratiğe döktüğünüzde geceyle gündüz kadar ayrı iki dünya ortaya çıkıyor.
Geçen ay İstanbul’daki o ürün toplantısını hâlâ düşünüyorum arada. Ekipten biri tek bir süper ajanla her şeyi halletmek istiyordu — “niye karmaşıklaştıralım ki?” modunda, anlarsınız (evet, doğru duydunuz). Diğeri ise işleri uzmanlaşmış, küçük parçalara bölmek gerektiğini savunuyordu; sessiz ama kararlı bir şekilde. Masanın havası bayağı teknikti, tartışma uzadı gitti, ama bir noktada herkes aynı gerçeğe geldi: demo yapmak kolay. Üretimde sistemi ayakta tutmak? O bambaşka bir hikâye. İşte tam o noktada MCP ile A2A konuya giriyor.
Şimdi burada bir şeyi net söyleyeyim. Birini araç katmanı gibi düşünebilirsiniz — ajanın dış dünyayla konuştuğu kapı, hani. Diğeri ise ajanlar arası bir trafik polisi gibi; kim kime ne zaman yetki devredecek, hangi mesaj hangi ajana gidecek, bunları koordine eden katman. İkisini kafanızda karıştırdığınız an mimari bulanıklaşıyor, hata aldığınızda nereye bakacağınızı bilemiyorsunuz — ve o his berbat, inanın. Ama ayırdığınız zaman, yani her birinin sorumluluğunu net çizgilerle belirlediğinizde, sistemin tam olarak nerede kırıldığını görebiliyorsunuz. Bu görünürlük? Bazen, sadece bazen, iyi bir model seçiminden bile daha değerli oluyor. Gerçekten öyle.
Neden bu konu şimdi bu kadar önemli?
Eskiden tek ajanlı kurulumlar yeterliydi. Kullanıcı isteği gelir, ajan düşünür, birkaç API çağrısı yapar, cevap dönerdi (buna dikkat edin). Güzel. Temiz. İlk bakışta gerçekten etkileyiciydi de — hani şu “bak yapay zeka ne kadar akıllı” diye heyecanlandığın o anlar. Ama iş gerçek hayata, gerçek müşterilere, gerçek sistemlere gelince tablo değişiyor; çünkü gerçek dünya ne yazık ki tek tip, tek katmanlı görevlerden oluşmuyor.
Kısa bir not düşeyim buraya.
Bir e-ticaret senaryosunu düşünün mesela. Biri stok kontrolü yapıyor, biri müşteri e-postasını yazıyor, biri ödeme sisteminden veri çekiyor, bir diğeri güvenlik açısından logları izliyor. Bunların hepsini aynı kafaya, aynı modele tıkmaya kalkarsanız — inanın, denedim — model şişiyor, maliyet artıyor, hata ayıklama tam anlamıyla kabusa dönüyor. Ben 2023’te küçük bir SaaS projesinde buna çok benzer bir yapı kurmuştum; ilk hafta harikaydı, ikinci haftada prompt karmaşası yüzünden kim neyi neden yaptı anlayamaz hale geldik. Gülünç ama acı bir tablo, inan.
İşin garibi, Gel gelelim 2025’te beklenti kökten değişti. Şirketler artık sadece “çalışsın” demiyor. “İzlenebilir olsun”, “yetki sınırı olsun”, “başka ekiple konuşabilsin”, “çökse bile tam olarak nerede çöktüğü belli olsun” istiyor. Kısacası: oyuncak prototip değil, operasyona hazır, üretim ortamına dayanıklı bir altyapı aranıyor. Bu kadar mı? Değil tabii — ama özet bu işte.
Çok konuştum, örnekle göstereyim. Apple’ın Yapmadığı MacBook Neo: Modla Gelen Sürpriz yazımızda bu konuya da değinmiştik.
MCP ile A2A aynı şey değil, zaten olmamalı da
Ne yalan söyleyeyim, Kafa karışıklığının kaynağı tam olarak burası. İnsanlar MCP’yi duyunca “tamam, her şey çözüldü” moduna geçiyor; A2A çıkınca da sanki tüm entegrasyon derdi bitecekmiş gibi bir hava oluyor. Hayır. Bu konuyla ilgili LaTeX’e Küstü, Markdown’dan PDF Üreten Python CLI Yazdı yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
MCP’nin işi aslında gayet net — araçlara, API’lere, dış kaynaklara standart bir yoldan bağlanmak. Yani ajan “şu veriyi çekeyim”, “bu servise yazayım”, “şu dosyayı okuyayım” dediğinde düzenli, tutarlı bir kapıdan geçiyor. Peki bunu neden söylüyorum? Bu kapı düzgün kurulursa ekip içinde kimse kafasına göre kablo takmıyor, sistem bir şekilde derli toplu kalıyor — en azından teoride böyle olması gerekiyor.
A2A ise bambaşka bir alana giriyor. Ajanların birbirini bulması, kim ne yapabilir diye anlaşması ve güvenli biçimde iş paylaşması… Bir ajan araştırma yaparken diğeri rapor yazıyor, biri uzun vadeli izleme yaparken öbürü acil durumları alıyor. Yani şöyle özetleyeyim: MCP içeriye — kendi adıma konuşayım — dönük düzeni kuruyor, A2A dışarıya dönük koordinasyonu veriyor. İkisi farklı katmanlar, farklı problemler. Daha fazla bilgi için A2A Neden Önemli: Çok Ajanlı Sistemler Altyapı Oluyor yazımıza bakabilirsiniz.
| Katman | Ne işe yarar? | Basit benzetme |
|---|---|---|
| MCP | Ajanın araçlarla konuşmasını standartlaştırır | Priz adaptörü |
| A2A | Ajanların birbirini bulup iş paylaşmasını sağlar | Trafik ışığı + ortak dil |
| Observability | Sistemin ne yaptığını izlemeyi kolaylaştırır | Kamera kayıt odası |
Neden ikisi birlikte daha mantıklı?
Açık konuşayım: tek standarda yüklenmek çoğu zaman mimariyi sakatlar. Sadece MCP’ye güvenirseniz her ajan kendi araçlarını gayet iyi bilir ama — dur bir saniye — diğer ajanın ne yaptığını pek umursamaz, umursamak için de bir mekanizması yoktur zaten — bence çok yerinde bir karar —. Sadece A2A ile giderseniz bu sefer ajanlar arası koordinasyon güzel kurulur, tamam,. Asıl işi yapacak araç bağlantıları zayıf kalır. İkisi de yarım çözüm. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Tuhaf ama, Bence iyi tasarım şu noktada başlıyor: içeride araç erişimi için MCP, dışarıda iş bölümü için A2A… ve bunların üstünde bir gözlemleme katmanı var mı? Varsa işler çok daha az sürprizli ilerliyor. Yok mu? O zaman neler döndüğünü anlamak için saatler harcarsınız. Denedim, biliyorum.
Tek ajanlı yapı neden çabuk tıkanıyor?
Tek ajanlı sistemler ilk demoda gerçekten etkileyici. Soru soruyorsun, cevap geliyor; dosya okutuyorsun, kod yazdırıyorsun… tamam gibi görünüyor. Ama yük artınca — ve muhtemelen artar — sınırlar hemen yüzüne çarpıyor.
Şöyle düşün: aynı agent’a aynı anda araştırma yaptırmaya, kod çalıştırmaya, e-posta atmaya ve bir de müşteri kaydını güncellemeye kalkarsın. Prompt uzuyor, bağlam şişiyor, kontrol hissi gidiyor. Bu bana geçen sene Berlin’de tanıştığım bir startup ekibini hatırlattı — üç kişilik bir ekipti, tek bir orkestratör agent yazmışlardı, sistem ilk hafta güzel çalıştı,. Iki hafta sonra kimsenin hangi çıktının nereden geldiğini bilmediği, kimin neyi tetiklediğini anlayamadığı tam bir kaosa dönüşmüştü. Kimse sorumluluğu üstlenmiyordu çünkü sistem zaten buna izin vermiyordu.
Sık görülen sorunlar neler?
- Aşırı büyük prompt’lar yüzünden bağlam kaybı
- Sorumluluk sınırlarının belirsizleşmesi
- Hata izolasyonunun zayıf olması
- Maliyetlerin beklenmedik şekilde yükselmesi (bence en önemlisi)
- Kimin ne yaptığına dair iz bırakmayan akışlar
Uzmanlaşmış ajanlara geçince tablo toparlanıyor. Bir ajan yalnızca araştırma yapar, biri yalnızca tool çağırır, biri doğrulama yürütür. Evet, her parçanın ayrı maliyeti var — bunu inkâr etmiyorum. Ama toplam sistem çok daha kontrollü oluyor, neyin nerede patladığını anlayabiliyorsun. Bu fark küçük değil.
Tek ajanda her şeyi toplamak kısa vadede hızlı görünür; çok ajanlı yaklaşım ise uzun vadede daha sakin yaşatır.
Mimariyi nasıl kurmalı? İçeride araçlar, dışarıda protokoller
Şöyle ki, Benim sevdiğim zihinsel model şu: ajanın içine baktığınızda tool zincirleri görürsünüz; ajanlar arasına baktığınızda ise protokol akışı görürsünüz. Bu ayrım küçük gibi dursa da tasarım kararlarını ciddi biçimde etkiliyor.
# Basit düşünce modeli
Agent_A:
- Research tool via MCP
- Summarize findings
- Send task to Agent_B via A2A
Agent_B:
- Validate data
- Trigger internal workflow tools via MCP
- Return result to Agent_A
Observability:
- Trace each step
- Log failures and retries
- Measure cost per task
Küçük bir startup için bu yapı fazladan karmaşık gibi görünebilir; haklısınız da kısmen haklısınız aslında — itiraf edeyim, beklentimin üstündeydi —. İlk etapta tek servis içinde iki modül bile yeterli olabilir. Ama kurumsal tarafta işler farklıdır çünkü izinler ayrı olur, departmanlar ayrı olur ve denetim beklentisi hiç şaka kaldırmaz.
Bunu test ettiğimde — evet gerçekten test ettim — en çok fark yaratan şey gözlemleme oldu. Mayıs 2024’te kendi deneme ortamımda üç mini ajanla oynarken birinin neden takıldığını anlamam neredeyse yarım saat sürdü; log yoksa tahmin yürütüyorsunuz resmen fal bakmak gibi oluyor.
Küçük ekip vs enterprise yaklaşımı
| Senaryo | Daha uygun yaklaşım | Neden? | Küçük startup | Sade MCP + sınırlı sayıda A2A akışı | Daha düşük operasyon yükü gerekir; |
|---|---|---|---|---|---|
| Orta ölçek ekip |
, etc.
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.
