# Çok Ajanlı Orkestrasyon Üretime Geçiyor: Yönetişim, Maliyet ve MCP/A2A (2026)

> Source: https://sukruyusufkaya.com/blog/cok-ajanli-orkestrasyon-uretim-yonetisim-2026
> Updated: 2026-07-09T10:42:15.842Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Gartner 2027'ye kadar agentic projelerin %40'ının iptal edileceğini söylüyor. Sebep model değil; yönetişim, maliyet kontrolü ve denetim eksikliği.

**TL;DR —** 2026, çok ajanlı orkestrasyonun (multi-agent orchestration) demolardan çıkıp üretime girdiği yıl oldu. Gartner, 2026 sonunda kurumsal uygulamaların %40'ının göreve özel yapay zekâ ajanları içereceğini söylüyor; 2025'te bu oran %5'in altındaydı. Ama aynı Gartner, 2027'ye kadar agentic AI projelerinin %40'ından fazlasının iptal edileceğini öngörüyor. Dikkat edin: bunun sebebi modelin yetersizliği değil. Sebep yönetişim boşluğu, kontrolsüz maliyet yayılması ve eksik denetim altyapısı. Bu yazıda sahadan bakışla anlatacağım: tek ajan neden duvara toslar, orchestrator-worker deseni nasıl çalışır, MCP ve A2A protokollerinin farkı, maliyet patlaması nereden gelir, ve bir pilotu üretime taşırken KVKK ile EU AI Act'i nasıl işin merkezine koyarsınız.

## Önce dürüst bir itiraf: tek ajan yetmiyor

Son iki yılda müşterilerimin çoğuyla aynı sahneyi yaşadım. Birisi heyecanla geliyor, "Şükrü, tek bir ajan kurduk, harika çalışıyordu, ama üç adımdan sonra dağılmaya başladı" diyor. Bu tesadüf değil. Tek bir dil modeli ajanı, ne kadar güçlü olursa olsun, sınırlı bir bağlam penceresine (context window) sahip. Ona müşteri verisini, iş kurallarını, geçmiş konuşmaları, on beş farklı aracın çıktısını ve bir de karar mantığını aynı anda yüklediğinizde, model yorulmaya başlar. Teknik olarak "yorulmaz" ama pratikte olan şudur: erken talimatları unutur, araç çağrılarını karıştırır, ve en kötüsü, kendinden emin bir tonla yanlış cevap verir.

Şöyle düşünün: tek bir çok yetenekli çalışanınız var. Aynı anda muhasebeci, hukukçu, satış temsilcisi ve veri analisti olmasını istiyorsunuz. İlk hafta idare eder. Ama iş büyüdükçe bu kişi hem yavaşlar hem hata yapar. Çözüm bellidir: ekip kurarsınız. Herkesin bir uzmanlık alanı, bir sorumluluğu ve birbiriyle konuşma biçimi olur. İşte çok ajanlı orkestrasyon tam olarak budur. Tek bir dev beyin yerine, her biri dar bir işe odaklanmış, birbirine görev devreden ajanlardan oluşan bir sistem.

Rakamlar bu geçişi doğruluyor. Gartner, çok ajanlı sistemlerle ilgili müşteri sorularında 2024'ün ilk çeyreğinden 2025'in ikinci çeyreğine kadar %1.445'lik bir artış bildirdi. Bin dört yüz kırk beş. Bu bir moda dalgası değil, bir mimari dönüşüm. Agentic AI pazarı 7,8 milyar dolardan 2030 için öngörülen 52 milyar dolara doğru büyüyor. Yani soru "çok ajanlı sisteme geçer miyiz?" değil artık; soru "geçtiğimizde bunu nasıl yöneteceğiz?"

## Orchestrator-worker deseni: en sağlam başlangıç noktası

Sahada en çok işe yarayan ve en kolay yönetilen desen, orchestrator-worker (yönetici-işçi) desenidir. Mantığı basit. Bir orkestratör ajan var; o beynin patronudur ama işi kendisi yapmaz. Gelen talebi anlar, parçalara böler, ve her parçayı ilgili uzman işçi ajana yönlendirir. İşçi ajanlar dar ve derin çalışır: biri sadece fatura sorgular, biri sadece envanter kontrol eder, biri sadece sözleşme metni analiz eder. Sonra orkestratör bu parçaları toplar, tutarlı bir cevaba dönüştürür ve kullanıcıya sunar.

Bir örnek vereyim. Bir sigorta şirketinde hasar dosyası değerlendirmesi kuruyorduk. Tek ajanla denediğimizde model, poliçe kurallarını okurken hasar fotoğrafı analizini unutuyordu. Orchestrator-worker desenine geçtik. Orkestratör dosyayı aldı; poliçe kontrolünü bir işçiye, fotoğraf analizini ikinci bir işçiye, dolandırıcılık risk skorunu üçüncü bir işçiye dağıttı. Her işçi kendi dar alanında çok daha isabetliydi. Orkestratör sonuçları birleştirdi ve bir insan uzmana özetle sundu. Karar döngüsü belirgin şekilde hızlandı; 2026'da üretim seviyesi orkestrasyon raporları karar döngülerinde %50'ye varan hızlanma ve operasyonel maliyetlerde %35-40 azalma gösteriyor.

Ama şuna dikkat çekmek istiyorum: bu desenin güzelliği hızda değil, izlenebilirlikte. Her işçi ayrı bir sorumluluk taşıdığı için, bir şey ters gittiğinde nereye bakacağınızı bilirsiniz. Poliçe kontrolü hatalıysa, o işçinin loglarına bakarsınız. Tek dev ajanla bu imkânsızdır; her şey tek bir kara kutunun içinde eriyip gider.

## MCP ve A2A: iki katmanlı omurgayı basitçe anlamak

2026'da bu alanın en önemli gelişmesi teknik değil, protokolel. İki protokol, çok ajanlı sistemlerin omurgasını oluşturdu: Model Context Protocol (MCP) ve Agent-to-Agent (A2A) protokolü. Bunları karıştırmak çok yaygın, o yüzden basitçe ayıralım.

**MCP dikey bağlantıdır.** Bir ajanı araçlara, verilere ve sistemlere bağlar. Ajanınızın CRM'e, veritabanına, dosya sistemine, bir API'ye erişmesi gerektiğinde MCP devreye girer. Şöyle düşünün: MCP, ajanlar dünyasının USB-C'sidir. Eskiden her araç için özel bir entegrasyon yazardınız; şimdi standart bir fiş var. Nisan 2026 itibarıyla MCP, 10.000'den fazla kurumsal sunucuda uygulanıyor ve SDK indirmeleri 97 milyonu aştı. Anthropic, OpenAI, Google, Microsoft ve AWS bunu benimsedi. Bu, bir standardın gerçekten standart hâline geldiği ender anlardan biri.

**A2A yataydır.** Ajanları birbirine bağlar. Bir ajanın başka bir ajana görev devretmesi, durum sorması, sonuç alması gerektiğinde A2A konuşur. A2A, Linux Foundation tarafından yönetiliyor; bu önemli, çünkü tek bir şirketin insafına kalmış bir protokol yerine, tarafsız bir vakıf tarafından yönetilen açık bir standart demek. Kurumsal alıcılar için bu güven meselesidir.

İkisini birlikte düşünün. MCP ajanınızın "elleri ve gözleri"dir; dış dünyaya uzanır. A2A ise ajanlarınızın "ortak dili"dir; birbirleriyle konuşurlar. Bir orkestratör, A2A ile işçilere görev dağıtır; her işçi de MCP ile kendi araçlarına erişir. İki katman, tek omurga.

Bu neden bu kadar önemli? Çünkü birlikte çalışabilirlik (interoperability) artık en üst öncelik. IT liderlerinin %87'si birlikte çalışabilirliği önceliklendiriyor. Ve işletmelerin %51'i hibrit yaklaşımı tercih ediyor: açık protokolleri, satıcı tarafından yönetilen orkestrasyonun üzerine katman olarak koyuyorlar. Yani kimse tamamen tek bir satıcıya kilitlenmek istemiyor, ama sıfırdan her şeyi kendi de kurmak istemiyor. Ortada, akıllıca bir denge kuruluyor.

## Asıl mesele: yönetişim boşluğu

Şimdi yazının kalbine geliyoruz. Gartner'ın o çarpıcı öngörüsünü tekrar hatırlatayım: 2027'ye kadar agentic AI projelerinin %40'ından fazlası iptal edilecek. Ve sebep modelin zekâsı değil. Sebep üç şey: eksik yönetişim, kontrolsüz maliyet yayılması ve olmayan denetim altyapısı.

Bunu sahada defalarca gördüm. Bir ekip harika bir pilot kuruyor. Demo mükemmel. Yönetim heyecanlanıyor. Sonra üretime taşıma zamanı geliyor ve sorular başlıyor: Bu ajan hangi verilere erişebilir? Kim onayladı? Bir müşteriye yanlış tavsiye verirse sorumlu kim? Bu kararın denetim kaydı nerede? Ajan bir aracı çağırdığında bunu loglıyor muyuz? Ve genellikle cevap sessizliktir. Çünkü pilot aşamasında kimse bunları düşünmemiştir.

Yönetişim boşluğu, üretime geçişin en büyük öldürücüsüdür. Tek bir ajanı yönetmek bile zorken, birbiriyle konuşan on ajanı yönetmek katlanarak zorlaşır. Her ajanın yetkisi, erişim sınırı, sorumluluğu net olmalı. Aksi hâlde şu klasik senaryoyu yaşarsınız: bir işçi ajan, olması gerekenden fazla veriye erişir; bir orkestratör, onaylanmamış bir işlemi tetikler; ve kimse bunun nasıl olduğunu geriye doğru izleyemez.

## RACI ile ajanları yönetmek: klasik bir çerçeveyi yeni bir soruna uygulamak

Müşterilerime hep söylediğim bir şey var: yeni teknolojiyi yönetmek için her zaman yeni bir çerçeveye ihtiyacınız yoktur. Bazen eski, kanıtlanmış çerçeveleri akıllıca uygularsınız. RACI matrisi tam da böyle bir araç. Klasik olarak insan ekiplerinde sorumluluk dağıtmak için kullanılır: Responsible (yapan), Accountable (hesap veren), Consulted (danışılan), Informed (bilgilendirilen).

Şimdi bunu ajanlarınıza uygulayın. Her ajan görevi için sorun:

- **Responsible (Yapan):** Hangi ajan bu işi fiilen yürütüyor? Örneğin fatura sorgulayan işçi ajan.
- **Accountable (Hesap veren):** Bu işin sonucundan kim sorumlu? Genellikle bu bir insandır, bir ajan değil. Bir ajan asla nihai hesap verebilir olamaz. Bu ayrımı kaybetmeyin.
- **Consulted (Danışılan):** Bu ajan karar verirken hangi kaynaklara, hangi diğer ajanlara danışıyor?
- **Informed (Bilgilendirilen):** Bu ajanın çıktısından kim haberdar edilmeli? Bir uyumluluk ekibi mi, bir denetçi mi?

Bu basit uygulamayı yaptığınızda, aniden yönetişim boşluğu somutlaşır. "Bu ajan kimin adına, kimin yetkisiyle, kimin gözetimi altında çalışıyor?" sorusuna net bir cevabınız olur. Ve Accountable sütununu her zaman bir insana bağlamak, hem KVKK hem de EU AI Act açısından hayati önemdedir. Çünkü her iki düzenleme de otomatik kararlarda insan gözetimini ve sorumluluğunu arar.

## Maliyet yayılması: sessiz katil

Yönetişimden sonra ikinci büyük öldürücü maliyettir. Ama dikkat, bu sinsi bir maliyettir. Şöyle işler: tek ajanla bir kullanıcı sorusu, belki üç dört model çağrısı yapar. Çok ajanlı sistemde aynı soru, orkestratörden işçilere, işçilerden araçlara, sonra geriye doğru toplanan onlarca hatta yüzlerce çağrıya dönüşebilir. Buna görev başına çağrı patlaması diyorum.

Somut bir senaryo. Bir e-ticaret müşterisinde müşteri hizmetleri orkestrasyonu kurmuştuk. Tek bir "siparişim nerede?" sorusu, sistemde şuna dönüşüyordu: orkestratör soruyu ayrıştırır (1 çağrı), sipariş işçisi veritabanını sorgular (2 çağrı), kargo işçisi taşıyıcı API'sini kontrol eder (3 çağrı), iade politikası işçisi kuralları okur (2 çağrı), ve orkestratör hepsini birleştirip yanıt üretir (2 çağrı). On çağrı, tek bir basit soru için. Bunu günde yüz bin kez çarpın. Aniden faturanız tavan yapar.

Sorun şu ki, bu maliyet pilot aşamasında görünmez. Pilot, günde belki elli sorgu çalıştırır. Üretimde bu yüz bine çıkar ve maliyet doğrusal değil, çoğu zaman çarpan etkisiyle büyür. İşte "kontrolsüz maliyet yayılması" derken kastedilen bu. Ve bunu üretime geçmeden önce modellemezseniz, ilk fatura geldiğinde proje iptal edilir.

Sahada uyguladığım birkaç somut önlem var:

- **Çağrı bütçesi koyun.** Her görev tipi için maksimum çağrı sayısı belirleyin. Bir "siparişim nerede?" sorusu on çağrıyı aşamaz; aşarsa alarm çalar.
- **Model kademelemesi yapın.** Her işçi en güçlü ve en pahalı modeli kullanmak zorunda değil. Basit sınıflandırma işini küçük ve ucuz bir model yapar; sadece gerçekten muhakeme gereken adımda büyük modele çıkarsınız.
- **Önbellek kullanın.** Aynı soru tekrar geliyorsa, aynı zincirini baştan çalıştırmayın. Sonuçları önbelleğe alın.
- **Erken durdurma (early exit) tasarlayın.** Orkestratör, bir işçinin cevabının yeterli olduğunu anlarsa, kalan işçileri boşuna çağırmasın.

Bu dört önlem, gördüğüm projelerde faturayı sıklıkla yarıya indirdi ve o %35-40'lık operasyonel maliyet azalmasının nasıl mümkün olduğunu açıklıyor. Maliyet azalması otomatik gelmez; onu tasarlarsınız.

## Denetim ve gözlemlenebilirlik: göremediğinizi yönetemezsiniz

Üçüncü öldürücü, denetim altyapısının eksikliğiydi. Şunu net söyleyeyim: çok ajanlı bir sistemi gözlemlenebilirlik (observability) olmadan üretime almak, farları kapalı gece yolculuğu yapmak gibidir. Bir süre iyi gider, sonra bir uçurumla tanışırsınız.

Neyi loglamanız gerekir? Her ajan çağrısını, her araç erişimini, her karar noktasını. Kim, ne zaman, hangi veriye erişti, hangi kararı verdi, hangi diğer ajana devretti. Bir müşteri "bana neden bu tavsiye verildi?" diye sorduğunda, ki KVKK kapsamında bunu sorma hakkı vardır, kararın tüm zincirini geriye doğru izleyebilmeniz gerekir. Buna izlenebilirlik (traceability) diyoruz ve bu, EU AI Act'in yüksek riskli sistemler için açıkça aradığı bir şeydir.

Gözlemlenebilirliği üç katmanda düşünün:

1. **İz kaydı (trace):** Tek bir kullanıcı isteğinin sistemdeki tüm yolculuğu. Hangi ajanlara uğradı, ne kadar sürdü, kaç çağrı yaptı.
2. **Metrikler:** Toplam çağrı sayısı, ortalama gecikme, hata oranı, görev başına maliyet. Bunlar sizin kontrol panelinizdir.
3. **Denetim kaydı (audit log):** Değiştirilemez, zaman damgalı, düzenleyiciye gösterilebilir bir kayıt. Bu, uyumluluk için pazarlık konusu değildir.

Bu üçünü kurmadan üretime çıkmayın. İnanın, ilk ciddi olay yaşandığında, bu logların olması ile olmaması arasındaki fark, projenizin hayatta kalmasıyla ölmesi arasındaki farktır.

## Türkiye bağlamı: KVKK ve EU AI Act'i işin merkezine koymak

Türkiye'de çalışan bir danışman olarak şunu sürekli vurguluyorum: düzenlemeyi sonradan yamamaya çalışmayın, baştan tasarıma gömün. Çok ajanlı sistemlerde bu daha da kritik, çünkü veri birçok ajan arasında dolaşıyor ve her sıçrama yeni bir uyumluluk sorusu doğuruyor.

**KVKK açısından** en kritik noktalar şunlar. Birincisi, veri minimizasyonu: her işçi ajanına, sadece işini yapmak için gereken minimum veriyi verin. Fatura sorgulayan ajanın müşterinin sağlık verisine erişmesi için hiçbir sebep yok. İkincisi, amaç sınırlaması: bir ajan, veriyi yalnızca toplandığı amaç için işlemeli. Üçüncüsü, açık rıza ve aydınlatma: kullanıcı, kararının otomatik bir sistem tarafından verildiğini bilmeli. Dördüncüsü, sınır ötesi veri aktarımı: eğer ajanlarınız yurt dışındaki bir model sağlayıcısına veri gönderiyorsa, bu aktarımın KVKK'ya uygunluğunu tesis etmelisiniz. Çok ajanlı sistemlerde bu kolayca gözden kaçar; her MCP bağlantısı potansiyel bir veri aktarım noktasıdır.

**EU AI Act açısından** ise Türkiye'den Avrupa pazarına hizmet veren şirketler için bu doğrudan bağlayıcı. Act, sistemleri risk seviyesine göre sınıflandırır. Eğer çok ajanlı sisteminiz kredi kararı, işe alım, sağlık gibi yüksek riskli bir alanda çalışıyorsa, insan gözetimi, izlenebilirlik, risk yönetimi ve dokümantasyon zorunlu hâle gelir. RACI matrisindeki "Accountable" sütununu hep bir insana bağlama önerimin altında yatan sebep budur; Act, otomatik sistemlerde anlamlı insan gözetimini talep eder.

Türkiye'de çalışan ekiplere pratik tavsiyem: bir "ajan veri haritası" çıkarın. Hangi ajan, hangi veriye erişiyor, bu veri nereye gidiyor, hangi model sağlayıcısı işliyor, ve hangi yasal dayanakla. Bu harita hem KVKK hem AI Act denetimlerinde sizi yıllarca ileri taşır.

## Pilottan üretime: olgunluk yolu

Bir pilotu üretime taşımak tek bir sıçrama değildir; bir olgunluk yolculuğudur. Sahada gördüğüm sağlıklı ilerleme genellikle şu aşamalardan geçer:

**Aşama 1 — Keşif pilotu.** Tek bir dar kullanım senaryosu. Amaç: değer var mı? Burada yönetişim hafiftir, ama en azından temel loglamayı baştan kurun. En sık hata, "sonra ekleriz" demektir.

**Aşama 2 — Kontrollü genişleme.** Pilot işe yaradıysa, orchestrator-worker desenine geçin. İkinci, üçüncü işçi ajanı ekleyin. Burada RACI matrisini kurmaya, çağrı bütçelerini koymaya, MCP/A2A protokollerini standartlaştırmaya başlayın.

**Aşama 3 — Üretim sertliği.** Tam gözlemlenebilirlik, değiştirilemez denetim kayıtları, maliyet kontrolleri, insan onay noktaları (human-in-the-loop) kritik kararlarda. KVKK ve AI Act uyumluluğu belgelenmiş olmalı. Bu aşamada sistem gerçek yüke ve gerçek denetime dayanmalı.

**Aşama 4 — Ölçekli işletim.** Birden fazla çok ajanlı sistem, ortak protokol katmanı üzerinde çalışır. Hibrit yaklaşım burada devreye girer: açık MCP/A2A protokollerini, satıcı yönetimli orkestrasyon platformlarının üstüne katman olarak koyarsınız. İşletmelerin %51'inin tercih ettiği bu model tesadüf değil; hem esneklik hem yönetilebilirlik verir.

Bu yolu atlamaya çalışan ekipleri gördüm. Aşama 1'den doğrudan Aşama 4'e sıçramaya çalışırlar. Neredeyse her zaman o %40'lık iptal istatistiğinin bir parçası olurlar. Olgunluk atlanamaz; ivmelendirilebilir ama atlanamaz.

## Sık sorulan sorular

**"Çok ajanlı sisteme gerçekten ihtiyacım var mı, yoksa tek iyi bir ajan yeter mi?"**
Dürüst cevap: eğer göreviniz tek bir dar alanda kalıyorsa ve bağlam sınırlarını zorlamıyorsa, tek ajanla kalın. Karmaşıklık bedava değil. Çok ajanlı mimariye, ancak görev gerçekten birden fazla uzmanlık gerektirdiğinde ve tek ajan tutarlılık kaybettiğinde geçin. Modaya değil, ihtiyaca göre karar verin.

**"MCP ve A2A'yı bugün mü benimsemeliyim, yoksa olgunlaşmalarını mı beklemeliyim?"**
MCP zaten olgunlaştı; 10.000'den fazla sunucu, 97 milyon SDK indirmesi ve beş büyük sağlayıcının benimsemesi bunu gösteriyor. Bugün MCP üzerine inşa etmek güvenli. A2A daha genç ama Linux Foundation yönetişimi ona sağlam bir zemin veriyor. Yeni sistemleri bu protokoller üzerine kurun; özel entegrasyonlara kilitlenmeyin.

**"Maliyeti önceden nasıl tahmin ederim?"**
Pilotta görev başına ortalama çağrı sayısını ölçün, sonra bunu gerçekçi üretim hacmiyle çarpın. Sonra en kötü senaryoyu (çağrıların patladığı durumu) da modelleyin. İkisi arasındaki fark sizi şaşırtacak; işte o farkı çağrı bütçeleri ve model kademelemesiyle kapatırsınız.

**"İnsan gözetimini nereye koymalıyım?"**
Her yere değil, kritik yerlere. Geri döndürülemez veya yüksek riskli kararlarda (para transferi, kredi reddi, tıbbi öneri) insan onayı zorunlu olmalı. Düşük riskli, geri alınabilir işlemlerde ajanlar özerk çalışabilir. RACI matrisiniz size bu ayrımı yapmakta yardımcı olur.

## Harekete geçme kontrol listesi

Bu yazıyı okuduktan sonra masanıza döndüğünüzde, şu listeyi elinize alın:

- [ ] **Kullanım senaryonuzun gerçekten çok ajanlı olmayı gerektirip gerektirmediğini** dürüstçe değerlendirin. Gerekmiyorsa, tek ajanla kalın.
- [ ] **Orchestrator-worker desenini** temel mimari olarak seçin; işçileri dar ve derin tutun.
- [ ] **MCP'yi araç/veri bağlantısı, A2A'yı ajanlar arası iletişim için** standart olarak benimseyin; özel entegrasyonlardan kaçının.
- [ ] Her ajan görevi için bir **RACI matrisi** çıkarın; "Accountable" sütununu her zaman bir insana bağlayın.
- [ ] **Görev başına çağrı bütçesi** koyun, **model kademelemesi** ve **önbellekleme** uygulayın; maliyeti pilotta modelleyin.
- [ ] Üç katmanlı **gözlemlenebilirlik** kurun: iz kaydı, metrikler, değiştirilemez denetim kaydı.
- [ ] Bir **ajan veri haritası** hazırlayın; her ajanın eriştiği veriyi, hedefini ve yasal dayanağını belgeleyin.
- [ ] **KVKK** açısından veri minimizasyonu, amaç sınırlaması, aydınlatma ve sınır ötesi aktarım kontrollerini uygulayın.
- [ ] Avrupa'ya hizmet veriyorsanız **EU AI Act** risk sınıflandırmanızı yapın; yüksek riskliyse insan gözetimi ve dokümantasyonu tamamlayın.
- [ ] **Olgunluk yolunu** izleyin: keşif, kontrollü genişleme, üretim sertliği, ölçekli işletim. Aşama atlamayın.

Şunu unutmayın: 2026'da çok ajanlı orkestrasyonu üretime taşıyan ekipleri, modelinin ne kadar zeki olduğu değil, sistemini ne kadar iyi yönettiği ayıracak. Zekâ artık meta değil; standart. Fark, yönetişimde, maliyet disiplininde ve denetim olgunluğunda yaratılıyor. O %40'lık iptal dalgasının içinde mi olursunuz, yoksa %60'lık hayatta kalan tarafta mı, bunu bugün masaya koyduğunuz disiplin belirleyecek. Kararı siz veriyorsunuz.

## Sahadan üç mini senaryo: neyin ters gittiğini gördüm

Teoriyi anlattım; şimdi izin verin size gerçekten yaşadığım üç kısa hikâye üzerinden neyin ters gittiğini göstereyim. Çünkü çok ajanlı orkestrasyonun tehlikeleri slaytlarda değil, gerçek üretim ortamlarında ortaya çıkıyor.

**Senaryo bir: sonsuz döngüye giren iki ajan.** Bir lojistik firmasında iki ajan tasarlamıştık; biri rota planlıyor, diğeri maliyeti optimize ediyordu. A2A üzerinden birbirlerine görev devrediyorlardı. Ama bir gün şu oldu: rota ajanı "bu rota çok pahalı" diyerek maliyet ajanına yönlendirdi; maliyet ajanı "daha ucuz rota planla" diyerek rota ajanına geri gönderdi; rota ajanı yine pahalı buldu ve geri yolladı. İki ajan, birbirlerine görev devrederek sonsuz bir döngüye girdi. Her tur onlarca model çağrısı yaktı. Kimse fark etmeden birkaç saat içinde ciddi bir fatura birikti. Ders: çok ajanlı sistemlerde döngü koruması (loop guard) ve maksimum devir sayısı (max hops) zorunludur. Bir görev, belirli sayıda sıçramadan sonra otomatik olarak bir insana yükselmelidir.

**Senaryo iki: sızan yetki.** Bir bankada, müşteri sorularını yanıtlayan bir orkestratör ve ona bağlı işçiler vardı. İşçilerden biri, hesap bakiyesi sorgulamak için veritabanına MCP ile bağlanıyordu. Ama entegrasyonu kuran ekip, o işçiye tüm veritabanı tablolarına erişim vermişti; oysa sadece bakiye tablosuna erişmesi gerekiyordu. Bu, kötü niyetli bir kullanıcı bir "prompt injection" saldırısı denediğinde ortaya çıktı; ajan, olması gerekenden çok daha fazla veriye ulaşabiliyordu. Neyse ki bunu üretim öncesi güvenlik testinde yakaladık. Ders: her MCP bağlantısında en az yetki ilkesini (principle of least privilege) uygulayın. Ajan, işini yapmak için mutlak minimum yetkiyle donatılmalı.

**Senaryo üç: kaybolan denetim izi.** Bir sağlık teknolojisi şirketinde, çok ajanlı bir triyaj asistanı üretimdeydi. Bir hasta, aldığı yönlendirmenin neden verildiğini sordu; bu KVKK kapsamında meşru bir talepti. Ekip logları açtı ve dehşete düştü: orkestratörün kararı loglanmıştı, ama işçilerin ara adımları loglanmamıştı. Kararın tam zincirini yeniden kuramadılar. Bu, hem yasal bir risk hem de bir güven krizi yarattı. Ders: kısmi loglama, loglamamaktan bazen daha tehlikelidir, çünkü size sahte bir güven verir. Uçtan uca izlenebilirlik pazarlık konusu değildir.

Bu üç hikâyenin ortak noktası dikkatinizi çekti mi? Hiçbiri modelin zekâsıyla ilgili değil. Hepsi yönetişim, yetki ve gözlemlenebilirlikle ilgili. Gartner'ın o %40'lık iptal öngörüsü tam olarak bu hikâyelerden besleniyor.

## İnsan-döngüde tasarımı: özerklik ve kontrol arasındaki denge

Çok ajanlı sistemlerde en çok tartışılan konu şudur: ajanlar ne kadar özerk olmalı? Sahada gördüğüm dengeyi paylaşayım. Her kararı insana sormak, sistemin tüm hızını öldürür; hiçbir kararı sormamak ise sizi o iptal istatistiğine götürür. Doğru cevap ikisinin ortasında, ama rastgele bir orta değil, risk temelli bir orta.

Kararları iki eksende düşünün: geri döndürülebilirlik ve etki. Bir karar hem kolay geri alınabiliyorsa hem düşük etkiliyse (mesela bir ürün önerisi listelemek), ajan özerk çalışsın. Ama karar geri döndürülemez veya yüksek etkiliyse (para transferi, sözleşme imzalama, tıbbi yönlendirme, kredi reddi), insan onayı zorunlu olmalı. Bu ikili eksen, size nerede fren koyacağınızı net söyler.

Pratik bir uygulama: orkestratöre bir "onay kapısı" mantığı yerleştirin. İşçiler işlerini yapar, ama nihai eylem yüksek riskliyse, orkestratör eylemi gerçekleştirmeden önce bir insana özet sunar ve onay bekler. Bu, hem hızı korur (insan sadece kritik anlarda devreye girer) hem de yönetişimi sağlar. Bir sigorta müşterimde bu deseni kurduğumuzda, rutin taleplerin %80'i tam otomatik işlenirken, yüksek tutarlı hasar ödemeleri insan onayına düşüyordu. Hem hız hem güven.

## Satın alma ve kurulum kararı: yap mı, al mı, katmanla mı?

Yöneticilerin bana en sık sorduğu sorulardan biri şu: "Bu orkestrasyon katmanını kendimiz mi kuralım, hazır bir platform mu alalım?" Cevabım genellikle üçüncü bir yol: katmanlayın. Verilere bakın; işletmelerin %51'i hibrit yığını tercih ediyor, yani açık protokolleri satıcı yönetimli orkestrasyonun üzerine koyuyor. Bu tesadüf değil.

Neden? Çünkü tamamen kendiniz kurarsanız, orkestrasyon altyapısını, gözlemlenebilirliği, protokol uyumunu, güvenlik katmanını sıfırdan bakım altında tutmanız gerekir. Bu, çekirdek işiniz değilse büyük bir yüktür. Ama tamamen tek bir satıcıya kilitlenirseniz, esnekliğinizi ve pazarlık gücünüzü kaybedersiniz; yarın daha iyi bir model çıktığında geçemezsiniz. Akıllı yol ortadadır: orkestrasyon platformunu bir satıcıdan alın, ama iletişim ve araç bağlantısını açık MCP ve A2A protokolleri üzerinden yürütün. Böylece platform değiştirseniz bile ajanlarınızın konuşma biçimi ve araç bağlantıları taşınabilir kalır.

Bu, birlikte çalışabilirliğin neden %87'lik bir öncelik olduğunu açıklar. Kimse tek bir tedarikçinin insafına kalmak istemiyor. Açık protokoller, size bir çıkış kapısı ve bir gelecek güvencesi verir. Sözleşme imzalarken şunu sorun: "Bu platform MCP ve A2A'yı yerel olarak destekliyor mu, yoksa beni kendi özel protokolüne mi kilitliyor?" Cevap ikincisiyse, iki kez düşünün.

## Ekip ve organizasyon: teknoloji kadar insan da değişmeli

Son bir nokta, ama belki en çok göz ardı edileni. Çok ajanlı orkestrasyon sadece bir teknoloji değişimi değil, bir organizasyon değişimidir. Gördüğüm başarısız projelerin çoğunda teknoloji çalışıyordu; başarısız olan, organizasyonun buna hazır olmamasıydı.

Yeni roller doğuyor. Birisi "ajan sahibi" olmalı; her üretim ajanının, tıpkı bir mikroservisin bir sahibi olduğu gibi, sorumlu bir insanı olmalı. Birisi maliyet panosunu izlemeli; çağrı patlamaları erkenden yakalanmalı. Birisi denetim ve uyumluluğu sahiplenmeli; KVKK ve AI Act gereksinimleri sürekli güncel tutulmalı. Ve en önemlisi, iş birimleriyle teknik ekipler arasında ortak bir dil kurulmalı. İş birimi "bu ajan neden bu kararı verdi?" diye sorabilmeli, teknik ekip de anlaşılır bir cevap verebilmeli.

Sahada işe yarayan bir uygulama: aylık bir "ajan gözden geçirme" toplantısı. İş, teknik ve uyumluluk bir masaya oturur; her üretim ajanının performansını, maliyetini, olaylarını ve uyumluluk durumunu gözden geçirir. Bu basit ritüel, sorunları küçükken yakalar ve o %40'lık iptal dalgasına karşı en güçlü kalkanlardan biridir. Teknoloji olgunlaşabilir, ama organizasyonel olgunluk da onunla birlikte yürümezse, en iyi mimari bile üretimde hayatta kalamaz.

Bu yüzden bir pilotu üretime taşırken, sadece "mimarimiz hazır mı?" diye sormayın. "Organizasyonumuz bu ajanları sahiplenmeye, izlemeye ve hesap vermeye hazır mı?" diye de sorun. İkinci sorunun cevabı, çoğu zaman projenin gerçek kaderini belirler.