Ajanlar Birbiriyle Konuşmaya Başladı: A2A ve MCP ile Çoklu-Ajan Birlikte Çalışabilirliği (2026)

TL;DR — 2025'e kadar yapay zekâ ajanları büyük ölçüde yalnız çalışıyordu: her biri kendi modeli, kendi araçları, kendi küçük dünyasıyla. 2026'da işler değişti. Artık ajanlar birbiriyle konuşuyor. Bunu mümkün kılan iki protokol var: MCP (Model Context Protocol) ajanı araçlara ve verilere "dikey" olarak bağlıyor; A2A (Agent2Agent Protocol) ajanları birbirine "yatay" olarak bağlıyor. İkisi rakip değil, tamamlayıcı. Nisan 2026 itibarıyla MCP 10.000'den fazla kurumsal sunucuda, 97 milyondan fazla SDK indirmesiyle yaygınlaştı; A2A ise Linux Foundation çatısı altında bir yılda 150'den fazla kuruluşu aştı. Ama burada bir tuzak var: kurumların yaklaşık %79'u "ajan benimsedik" diyor, sadece %11'i bunları gerçekten üretimde çalıştırıyor. Bu yazıda bu boşluğun neden var olduğunu, güvenliğin neden meselenin kalbi olduğunu ve Türkiye'deki bir kurumun KVKK, veri ikametgâhı ve insan denetimi sınırları içinde nereden başlaması gerektiğini anlatıyorum.

Sahada danışmanlık yaparken en sık karşılaştığım yanlış anlama şu: "Bizim zaten bir yapay zekâ asistanımız var, ne fark eder?" Fark çok büyük. Tek bir asistan, tek bir kutuya sığar. Soru sorarsınız, cevap verir. Ama gerçek kurumsal iş akışları tek bir kutuya sığmaz. Bir satınalma sürecini düşünün: talebi anlayan bir ajan, tedarikçi sözleşmelerini tarayan başka bir ajan, bütçe kontrolü yapan üçüncü bir ajan, onay zincirini yöneten dördüncü bir ajan. Bunların her biri farklı bir ekip, farklı bir sistem, hatta farklı bir şirket tarafından geliştirilmiş olabilir.

2025'e kadar bu ajanları birbirine bağlamak için her seferinde özel, kırılgan entegrasyonlar yazıyorduk. Her bağlantı elle örülmüş bir köprüydü; biri değişince diğeri çöküyordu. Şimdi ise standart protokoller var. Tıpkı internetin TCP/IP üzerine, web'in HTTP üzerine kurulması gibi, ajan ekonomisi de ortak bir dil üzerine kuruluyor. Bu, abartısız, son yirmi yılın en önemli altyapı dönüşümlerinden biri. Ve çoğu kurum bunun farkında bile değil.

İşin güzel tarafı şu: bu protokoller artık tek bir şirketin kontrolünde değil. MCP'yi Anthropic başlattı, A2A'yı Google başlattı, ama ikisi de bağımsız vakıflara devredildi. Bu, kurumsal karar vericiler için kritik bir güven sinyali. Çünkü hiçbir CTO, şirketinin bel kemiğini tek bir satıcının insafına teslim etmek istemez.

MCP, yani Model Context Protocol, Anthropic tarafından geliştirildi ve bir ajanın dış dünyaya — araçlara, veritabanlarına, dosya sistemlerine, API'lere — bağlanma biçimini standartlaştırıyor. Ben buna "dikey" bağlantı diyorum, çünkü bir ajanı kendi altındaki kaynaklara indiriyor.

Bir benzetme yapayım. MCP, yapay zekâ dünyasının USB-C'si gibidir. Eskiden her cihazın kendi şarj kablosu vardı; bir telefon için bir kablo, bir kamera için başka bir kablo, bir dizüstü için üçüncü bir kablo. USB-C geldi, hepsi tek bir standartta buluştu. MCP de aynısını yapıyor: bir kez MCP sunucusu yazarsanız, MCP'yi destekleyen her ajan o aracı kullanabilir. CRM'inizi bir kez bağlarsınız, hangi ajan gelirse gelsin o CRM'i konuşabilir.

Rakamlar bu standardın ne kadar hızlı yayıldığını gösteriyor. Nisan 2026 itibarıyla MCP, 10.000'den fazla kurumsal sunucuda hayata geçti ve SDK'ları 97 milyondan fazla kez indirildi. Daha da önemlisi, kimlerin benimsediğine bakın: Anthropic, OpenAI, Google, Microsoft, AWS. Yani normalde birbiriyle kıyasıya rekabet eden devler, bu konuda aynı masaya oturdu. Sektörde bunun olması nadirdir; olduğunda da bir şeyin gerçekten standart hâline geldiğini anlarsınız.

MCP'nin pratikte ne yaptığını somutlaştırayım. Diyelim ki bir banka, müşteri hizmetleri ajanının hesap bakiyesini sorgulayabilmesini istiyor. MCP olmadan, bu ajan için özel bir bağlantı kodu yazılması gerekir; ajan değişirse kod yeniden yazılır. MCP ile, banka bir kez bir "bakiye sorgulama" MCP sunucusu kurar ve bu yetkiyi, erişim sınırları ve denetim kayıtlarıyla birlikte tanımlar. Artık hangi ajan o sunucuya bağlanırsa bağlansın, aynı kurallarla, aynı denetimle çalışır.

A2A, yani Agent2Agent Protocol, başlangıçta Google tarafından geliştirildi ve tamamen farklı bir problemi çözüyor: ajanların birbiriyle konuşmasını. MCP bir ajanı araçlara indiriyorsa, A2A iki ajanı yan yana getiriyor. Ben buna "yatay" bağlantı diyorum.

Şöyle düşünün: MCP, bir çalışanın bilgisayarına, telefonuna, dosya dolabına erişmesini sağlayan altyapıdır. A2A ise iki çalışanın birbirine e-posta atması, toplantı yapması, görev devretmesidir. Biri kişinin araçlarıyla ilişkisi, diğeri kişiler arası ilişki. İkisi de gerekli, ikisi de farklı.

A2A'nın yolculuğu da öğretici. Proje Haziran 2025'te Linux Foundation çatısı altına alındı ve bir yılını doldurduğu Nisan 2026'da 150'den fazla kuruluşu aştı. Bugün Microsoft Azure AI Foundry ve Copilot Studio'ya, AWS Bedrock AgentCore'a ve Google Cloud'a entegre edilmiş durumda. Yani bir ajanı Azure'da, başka birini AWS'de çalıştırsanız bile, bunlar A2A sayesinde ortak bir dille konuşabilir. Bu, bulut sağlayıcısına kilitlenmenin (vendor lock-in) korkusunu ciddi biçimde azaltıyor.

A2A'nın kalbinde "Agent Card" denilen bir kavram var. Her ajan, kendisini tanıtan bir kimlik kartı yayımlıyor: "Ben şuyum, şunları yapabilirim, benimle şöyle konuşabilirsin." Tıpkı bir kartvizit gibi. Bir ajan başka bir ajanı keşfettiğinde, önce bu kartı okuyor, ne yapabileceğini anlıyor ve ona göre görev devrediyor. Bu keşif mekanizması, ajanların önceden birbirini tanımadan bile iş birliği yapabilmesini sağlıyor — ki ölçeklenebilir bir ajan ekonomisi için bu şart.

Kafadaki karışıklığı gidermek için ikisini bir tabloda karşılaştırayım:

Boyut	MCP (Model Context Protocol)	A2A (Agent2Agent Protocol)
Kaynak	Anthropic	Google (artık Linux Foundation)
Yön	Dikey: ajan → araç/veri	Yatay: ajan ↔ ajan
Çözdüğü problem	Ajanın kaynaklara erişimi	Ajanların birbiriyle iş birliği
Benzetme	USB-C / araç kemeri	E-posta / kartvizit
Temel kavram	Tool, Resource, Prompt	Agent Card, Task, görev devri
Tipik kullanım	CRM, veritabanı, dosya, API bağlama	Çok ajanlı iş akışı orkestrasyonu

Bu tabloya bakınca neden rakip değil tamamlayıcı olduklarını görmek kolaylaşıyor. Gerçek bir kurumsal çözümde ikisini de kullanırsınız: ajanlarınız birbiriyle A2A üzerinden konuşur, her ajan da kendi işini yapmak için MCP üzerinden araçlara uzanır. Biri olmadan diğeri yarım kalır.

Bir dönem "hangi protokol kazanacak?" tartışması vardı. Sektör, video formatı savaşları veya işletim sistemi savaşları gibi bir "kazanan her şeyi alır" senaryosu bekliyordu. Üçüncü bir protokol daha var: ACP (Agent Communication Protocol), IBM ve AGNTCY tarafından geliştirilen. Bir süre üç protokolün birbirini yiyeceği düşünüldü.

Ama olan bu olmadı. Bugün MCP, A2A ve ACP'nin üçü de Linux Foundation gözetimi altında. Yani "kazanan her şeyi alır" çağı, yerini "tamamlayıcı katmanlaşma" çağına bırakıyor. Bu çok önemli bir olgunlaşma işareti. Protokoller birbirini yok etmek yerine farklı katmanlarda uzmanlaşıyor. Tıpkı internetin tek bir protokolle değil, katman katman yığılan protokollerle (IP, TCP, HTTP, TLS) çalışması gibi.

Kurumsal karar verici açısından bunun anlamı net: artık "yanlış ata oynama" korkusuyla beklemeniz gerekmiyor. Üç büyük protokol de nötr bir vakıf çatısı altında, birbiriyle uyumlu çalışacak şekilde gelişiyor. Bu, yatırım yapmak için gereken güveni sağlıyor. Bekleyip görmek yerine, temkinli ama kararlı adımlarla başlamanın tam zamanı.

Şimdi işin en kritik kısmına geliyorum. Ajanların birbiriyle konuşması heyecan verici, ama aynı zamanda yepyeni bir saldırı yüzeyi açıyor. Yıllardır güvenlik dünyası insan kullanıcılar ve sistemler arasındaki güveni yönetmeye odaklandı. Şimdi araya özerk karar veren ajanlar girdi. Bu, güvenlik mimarisini baştan düşünmeyi gerektiriyor.

Şu soruyu sorun: Bir ajan başka bir ajandan görev aldığında, o ajanın gerçekten iddia ettiği ajan olduğunu nereden biliyoruz? İnsan dünyasında kimlik doğrularız — şifre, biyometri, çok faktörlü doğrulama. Ajan dünyasında da aynısı gerekiyor ama daha karmaşık. Çünkü ajanlar dinamik olarak ortaya çıkıp kaybolabilir, başka ajanlar adına hareket edebilir, hatta zincirleme yetki devri yapabilir.

Üç temel sütun üzerinde durmak gerekiyor:

• Kimlik ve kimlik doğrulama (authentication): Her ajanın doğrulanabilir bir kimliği olmalı. "Sen kimsin?" sorusuna kriptografik olarak cevap verebilmeli. A2A'nın Agent Card mekanizması bunun temelini atıyor ama kurumun bunu kendi kimlik altyapısıyla (örneğin kurumsal SSO, sertifika otoritesi) sıkıca bağlaması gerekiyor.
• Yetkilendirme (authorization): Kimliği doğrulanmış bir ajanın her şeyi yapabilmesi gerekmez. "Sen busun, peki ne yapmaya iznin var?" sorusunun cevabı net olmalı. En az ayrıcalık ilkesi (least privilege) burada hayati. Bir ödeme başlatma ajanının, müşteri verisini toplu dışa aktarma yetkisi olmamalı.
• Denetim izi (audit trail): Hangi ajan, ne zaman, hangi ajana, hangi görevi verdi; hangi araca eriştti; hangi kararı aldı? Bunların hepsi değiştirilemez biçimde kaydedilmeli. Bir sorun çıktığında — ki çıkacak — geriye dönüp "burada ne oldu?" diyebilmeniz gerekiyor. Denetim izi olmadan üretime ajan koymak, ben olsam, asla önermem.

Bu üç sütunun ötesinde, ajanlara özgü yeni riskler de var. Mesela "prompt injection" yani komut enjeksiyonu: kötü niyetli bir ajan veya veri kaynağı, başka bir ajana gizlice zararlı talimatlar sızdırabilir. Ya da "yetki yayılması": bir ajan zinciri boyunca yetkilerin sessizce birikmesi ve sonunda kimsenin amaçlamadığı bir gücün ortaya çıkması. Bunlar teorik değil; sahada karşılaşmaya başladığımız gerçek sorunlar.

Gelelim sektörün en az konuşmak istediği gerçeğe. Gartner'a göre 2026 sonuna kadar kurumsal uygulamaların yaklaşık %40'ı göreve özel yapay zekâ ajanları içerecek — bu, 2025'teki %5'in altındaki orandan büyük bir sıçrama. Tablo parlak görünüyor.

Ama madalyonun diğer yüzü var. Aynı dönemde kurumların yaklaşık %79'u "yapay zekâ ajanları benimsedik" diyor; ne var ki sadece %11'i bunları gerçekten üretimde çalıştırıyor. Aradaki bu uçurum — benimseme ile üretim arasındaki boşluk — sektörün gerçek hikâyesi. Çoğu kurum pilot aşamasında takılıp kalıyor. Demo çalışıyor, sunum etkileyici, yönetim heyecanlı; ama iş gerçek müşteri verisiyle, gerçek para akışıyla, gerçek sorumlulukla üretime çıkmaya gelince herkes duruyor.

Neden? Çünkü üretim bambaşka bir oyun. Demo'da hata yapan ajan komik olur; üretimde hata yapan ajan dava, ceza, itibar kaybı demektir. İşte tam da bu yüzden yukarıda anlattığım güvenlik, kimlik ve denetim meseleleri pilot ile üretim arasındaki o duvarı oluşturuyor. Bu duvarı aşmadan ölçeklenemezsiniz.

"

Sahadaki gözlemim şu: Üretime geçemeyen kurumların çoğu teknik bir engele değil, bir güven ve yönetişim eksikliğine takılıyor. Model çalışıyor; eksik olan, "bir şey ters giderse ne olacak?" sorusunun kurumsal cevabı.

Ama boşluğun kapandığını gösteren güçlü sinyaller de var. Üretimde, gerçek ölçekte çalışan örnekler artık mevcut. Alipay, Şubat 2026'da tek bir haftada yaklaşık 120 milyon yapay-zekâ-ajanı-tarafından-başlatılan işlem işledi. Bu, oyuncak bir rakam değil; gerçek paranın, gerçek ölçekte ajanlar tarafından hareket ettirildiğinin kanıtı. Benzer şekilde, DBS Bank ve Mastercard Singapur'da ilk canlı agentic (ajan tabanlı) ödemeyi tamamladı. Bunlar öncü vakalar ve geri kalanımıza yolu gösteriyor: doğru güvenlik ve yönetişimle, ajanlar üretimde gerçekten para taşıyabiliyor.

Şimdi en çok önemsediğim kısma geliyorum: Türkiye'deki bir kurum bu dönüşümden nasıl pay alır? Çünkü genel geçer öğütler kolay; asıl mesele yerel gerçeklerle, KVKK ile, veri ikametgâhı kısıtlarıyla, kurumsal kültürle bunu uyumlu kılmak.

İlk ve en önemli ilke: KVKK'yı en baştan tasarıma katın. Ajanlar veri işler; üstelik birbirine veri devreder. Bir ajan diğerine kişisel veri içeren bir görev devrettiğinde, KVKK açısından bu bir veri işleme faaliyetidir. Aydınlatma yükümlülüğü, açık rıza (gerekiyorsa), amaçla sınırlılık, veri minimizasyonu — bunların hepsi ajan mimarisine gömülmeli. Sonradan eklenen uyum, hiçbir zaman gerçek uyum olmaz. Ajanların hangi kişisel veriye, hangi amaçla, ne kadar süre eriştiğini en baştan haritalandırın.

İkincisi: Veri ikametgâhı ve on-prem seçeneklerini ciddiye alın. Birçok Türk kurumu, özellikle finans, sağlık ve kamu, verilerinin yurt dışına çıkmasını istemiyor ya da yasal olarak çıkaramıyor. İyi haber şu: MCP ve A2A protokolleri, açık standartlar oldukları için, bulutta da on-prem'de de çalışabilir. Ajan altyapınızı kendi veri merkezinizde veya yerel bir bulutta barındırıp, yine de standart protokollerle dış dünyayla konuşabilirsiniz. Protokolün açık ve nötr olması burada büyük bir avantaj; sizi belirli bir sağlayıcının coğrafyasına mahkûm etmiyor.

Üçüncüsü: İnsan denetimini (human oversight) mimarinin merkezine koyun. Özellikle başlangıçta, kritik kararlarda bir insanın onay halkasında olması şart. "İnsan döngüde" (human-in-the-loop) yaklaşımı, ajanlara güveni adım adım inşa etmenin en sağlıklı yolu. Ajan öneriyi hazırlar, insan onaylar; zamanla, güven oluştukça ve denetim kayıtları olgunlaştıkça, daha fazla özerklik tanırsınız. Aceleci tam-özerklik, sahada gördüğüm en pahalı hatalardan biri.

Dördüncüsü: EU AI Act ile bağı kurun. Türkiye'deki birçok kurum Avrupa'ya hizmet veriyor veya Avrupalı iş ortaklarıyla çalışıyor. AB Yapay Zekâ Yasası (EU AI Act), risk temelli bir yaklaşım getiriyor ve yüksek riskli yapay zekâ sistemleri için şeffaflık, insan denetimi, kayıt tutma gibi yükümlülükler koyuyor. İyi haber şu ki, bu yükümlülükler ile sağlam bir ajan yönetişimi büyük ölçüde örtüşüyor. KVKK + EU AI Act + iyi ajan mimarisi aynı yöne bakıyor: kimlik, yetki, denetim, insan gözetimi. Birini doğru yaparsanız, diğerlerinin de büyük kısmını yapmış olursunuz.

Bu ilkeleri somut bir başlangıç planına dökeyim:

Aşama	Ne yapılır	Süre (tipik)
1. Keşif	Mevcut süreçlerden ajana en uygun, düşük riskli bir alanı seçin	2-4 hafta
2. Pilot	Tek bir iş akışında MCP ile araç bağlama, kontrollü ortamda test	4-8 hafta
3. Güvenlik sertleştirme	Kimlik, yetki, denetim izi; insan onay halkaları	4-6 hafta
4. Çoklu-ajan	A2A ile ikinci bir ajanı orkestrasyona katın	6-8 hafta
5. Üretim	Aşamalı yaygınlaştırma, izleme, geri bildirim döngüsü	Sürekli

Bu takvim her kurum için farklılaşır; amacım hız değil, doğru sırayı göstermek. Dikkat edin: güvenlik sertleştirme, çoklu-ajan adımından önce geliyor. Çünkü tek ajanı bile güvenli hâle getiremediyseniz, iki ajanı konuşturmak riski ikiye değil, kat be kat artırır.

Bana en sık sorulan soru bu: "Nereden başlayalım?" Cevabım hep aynı: en gösterişli yerden değil, en güvenli yerden. İlk ajan projeniz, yanlış giderse şirketi sarsmayacak bir alanda olmalı. İç süreçler — örneğin bir IT yardım masası, bir İK soru-cevap asistanı, bir rapor özetleme akışı — mükemmel başlangıç noktalarıdır. Buralarda hata yaparsanız, müşteri görmez, para kaybolmaz, sadece öğrenirsiniz.

Müşteriye dönük veya para hareketi içeren ajanları en sona bırakın. Onlar geldiğinde, kasları çoktan geliştirmiş, denetim altyapısını kurmuş, ekibi eğitmiş olursunuz. Alipay'in 120 milyon işlemi bir günde olmadı; arkasında yıllarca süren altyapı, güvenlik ve güven inşası var. Aceleci olmayın; ama kararsız da kalmayın.

Bir de şunu ekleyeyim: ölçütlerinizi en baştan tanımlayın. "Bu pilot başarılı sayılması için neyi başarmalı?" sorusuna net bir cevabınız yoksa, pilot asla bitmez. Bitmeyen pilotlar, üretim boşluğunun en büyük sebebidir. Somut bir hedef koyun: "Yardım masası taleplerinin %30'unu insan müdahalesi olmadan, doğrulukla çözmek" gibi. Ölçemediğiniz şeyi yönetemezsiniz, yönetemediğiniz şeyi de üretime alamazsınız.

MCP ve A2A'dan ikisini birden mi kullanmam gerekiyor, yoksa biri yeter mi? Duruma bağlı. Tek bir ajanı kendi araçlarınıza bağlamak istiyorsanız MCP yeter. Birden fazla ajanı birbiriyle konuşturmak istediğiniz an A2A devreye girer. Çoğu ciddi kurumsal senaryoda ikisi birlikte kullanılır: ajanlar A2A ile koordine olur, her biri MCP ile araçlarına uzanır.

Bu protokoller bir satıcıya bağımlılık yaratır mı? Tam tersi. Her ikisi de açık standart ve bağımsız vakıflar (Linux Foundation) tarafından yönetiliyor. Asıl amaçları satıcı bağımlılığını azaltmak. Bir ajanı Azure'da, diğerini AWS'de çalıştırıp aynı protokolle konuşturabiliyor olmanız bunun kanıtı.

KVKK açısından ajanların birbirine veri devretmesi sorun mu? Devir bir veri işleme faaliyetidir, dolayısıyla KVKK kapsamındadır. Sorun değil ama yönetilmesi gerekir: amaçla sınırlılık, veri minimizasyonu, aydınlatma ve gerekiyorsa rıza. En baştan tasarıma katarsanız sorun olmaz; sonradan eklemeye çalışırsanız baş ağrısı olur.

Üretime geçemiyoruz, takıldık. En yaygın sebep ne? Sahadaki gözlemim, sorunun genellikle teknik değil yönetişimsel olduğu yönünde. Model çalışıyor ama "bir şey ters giderse ne olacak?" sorusunun kurumsal cevabı yok. Kimlik, yetki, denetim izi ve insan onay halkalarını kurun; duvar genellikle orada aşılır.

Tam özerk ajanlara ne zaman geçmeliyiz? Acele etmeyin. İnsan-döngüde başlayın, denetim kayıtlarınız olgunlaşsın, güven verilerle kanıtlansın. Özerkliği kademeli artırın. Sahada gördüğüm en pahalı hatalar, güven inşa edilmeden verilen tam özerklikten doğuyor.

Bu yazıyı bitirirken size soyut bir özet değil, yarın masaya oturduğunuzda kullanabileceğiniz bir düşünce çerçevesi bırakmak istiyorum. Ajan birlikte çalışabilirliği artık "gelecekte olabilir" kategorisinden çıktı; üretimde, gerçek parayla, gerçek ölçekte çalışıyor. Soru "olacak mı?" değil, "biz hazır mıyız?".

Kendi kurumunuza şu dört soruyu sorun. Birincisi: Ajanlarımız bir gün birbiriyle konuşacaksa, kimliklerini nasıl doğrulayacağız ve yetkilerini nasıl sınırlayacağız? Bu sorunun cevabı yoksa, başlamak için en doğru yer burası. İkincisi: Bir ajan kararı ters gittiğinde, geriye dönüp "ne oldu?" diyebileceğimiz bir denetim izimiz var mı? Yoksa, üretime çıkmadan önce kurulmalı. Üçüncüsü: KVKK ve veri ikametgâmı kısıtlarımız bizi hangi mimari tercihlere zorluyor — bulut mu, on-prem mi, hibrit mi? Bu kararı erken verin, çünkü sonradan değiştirmek pahalıdır. Dördüncüsü: İlk, düşük riskli pilotumuz hangi iç süreç olacak ve başarısını neyle ölçeceğiz?

Bu dört sorunun cevabı, sizi pilot tuzağından üretim gerçekliğine taşıyan köprüdür. Protokoller olgunlaştı, vakıflar güveni sağladı, öncü kurumlar yolu açtı. Şimdi sıra, temkinli ama kararlı bir şekilde, kendi kurumunuzda ilk adımı atmakta. Mükemmel anı beklemeyin — o an, doğru sırayla başladığınız andır. Önce keşif, sonra küçük bir pilot, sonra güvenliği sertleştirme, ve ancak ondan sonra ajanları birbiriyle konuşturma. Bu sırayı koruyan kurumlar, önümüzdeki yıl bu dönüşümün kazananları arasında olacak. Sırayı atlayanlar ise, ne yazık ki, üretim boşluğunda takılı kalan o %79'a katılacak. Tercih, daha doğrusu disiplin, sizin elinizde.

Buraya kadar protokolleri ayrı ayrı anlattım; şimdi bir an durup bunların bir arada nasıl çalıştığını somut bir senaryoyla canlandırmak istiyorum. Çünkü teorinin pratiğe döküldüğü yerde gerçek anlaşılır. Bir sigorta şirketinde hasar değerlendirme sürecini düşünelim. Müşteri bir hasar bildiriyor. İlk ajan, "giriş ajanı", talebi karşılıyor, fotoğrafları ve belgeleri topluyor. Bu ajan, belge yönetim sistemine MCP üzerinden erişiyor — işte dikey bağlantı. Sonra giriş ajanı, topladığı dosyayı bir "değerlendirme ajanına" A2A üzerinden devrediyor — işte yatay bağlantı. Değerlendirme ajanı, poliçe veritabanına yine MCP ile bakıyor, kapsamı kontrol ediyor, ardından bir "ödeme ajanına" görevi A2A ile aktarıyor.

Bu zincirde her görev devri, her araç erişimi kaydediliyor. Her ajan kendini Agent Card ile tanıtıyor, kimliği doğrulanıyor, yetkisi sınırlanıyor. Eğer ödeme ajanı, yetkisinin üzerinde bir tutarla karşılaşırsa, otomatik olarak bir insan onay halkasına yönlendiriyor. İşte sağlıklı bir ajan mimarisi böyle görünür: dikey ve yatay bağlantılar iç içe, ama her adımda kimlik, yetki ve denetim sıkıca örülmüş. Bu örnekte protokollerin neden tamamlayıcı olduğunu çıplak gözle görebilirsiniz; MCP olmadan ajanlar işe yarar veriye ulaşamaz, A2A olmadan da birbirlerine iş devredemezler.

Bu mimarinin güzelliği modülerliğinde. Yarın değerlendirme ajanını daha iyi bir modelle değiştirmek isterseniz, sadece o ajanı değiştirirsiniz; Agent Card aynı kaldığı sürece zincirin geri kalanı hiç haberdar olmaz bile. Bu, kurumlara muazzam bir esneklik veriyor. Tek parça, devasa, kırılgan sistemler yerine, her biri kendi işini yapan, standart arayüzlerle konuşan küçük ajanlardan oluşan bir ekosistem kuruyorsunuz. Yazılım mühendisliğinde mikroservislerin getirdiği devrimi hatırlayın; ajan ekonomisi, benzer bir esnekliği yapay zekâ dünyasına taşıyor.

Sahada bir şeyi defalarca gördüm: teknolojiyi kurmak, yönetişimi kurmaktan çok daha kolay. Bir ajanı çalıştırmak günler alır; o ajanın kararlarından kimin sorumlu olduğunu, hangi sınırlar içinde hareket edeceğini, kimin denetleyeceğini netleştirmek aylar alabilir. Ama bu ikinci kısım, üretime gerçekten çıkmanın anahtarı.

İyi bir ajan yönetişimi birkaç soruya net cevap vermelidir. Bir ajan zarar verici bir karar aldığında sorumluluk kimde — ajanı geliştiren ekipte mi, devreye alan iş biriminde mi, onay halkasındaki insanda mı? Bu soruların cevabı kurumdan kuruma değişir, ama mutlaka önceden verilmiş olmalı. Kriz anında sorumluluk tartışması başlatmak, en kötü zamanlamadır. Bir ajan komitesi veya yapay zekâ yönetişim kurulu kurmak, başlangıçta fazla gibi görünse de, ölçeklendikçe paha biçilmez hâle gelir.

Ayrıca politikaların yaşayan belgeler olması gerekiyor. Ajan teknolojisi hızla değişiyor; bugün yazdığınız bir kural altı ay sonra eskimiş olabilir. Düzenli gözden geçirme döngüleri kurun. Yeni bir protokol özelliği çıktığında, yeni bir saldırı türü keşfedildiğinde, yeni bir düzenleme yürürlüğe girdiğinde yönetişiminizi güncelleyin. Statik bir politika, dinamik bir teknolojide hızla anlamsızlaşır.

Son olarak çoğu teknik yazının atladığı bir şeye değinmek istiyorum: insan boyutu. Ajanlar iş yapmaya başladığında, çalışanlar haklı olarak "benim yerime mi geçecek?" diye soruyor. Bu korkuyu görmezden gelmek, en iyi teknik mimariyi bile çökertir. Çünkü ajanları besleyen, denetleyen, düzelten, geliştiren yine insanlardır. Ekibi düşman değil ortak görmezseniz, sistem sessizce sabote edilir veya benimsenmez.

Benim önerim, ajanları "işi alan" değil "işi büyüten" araçlar olarak konumlandırmak. Bir yardım masası ajanı, çalışanı işsiz bırakmaz; onu sıkıcı, tekrarlı taleplerden kurtarıp daha karmaşık, daha değerli işlere yönlendirir. Bu mesajı dürüstçe ve somut örneklerle vermek, dönüşümün hızını ikiye katlar. Şeffaflık burada kritik: çalışanlara hangi süreçlerde ajan kullanılacağını, hangi kararların hâlâ insanda kalacağını açıkça anlatın. Belirsizlik korkuyu büyütür; netlik güveni büyütür.

Eğitim de bu kültürel dönüşümün ayrılmaz parçası. Ekibinizin ajanlarla nasıl çalışacağını, onları nasıl denetleyeceğini, ne zaman müdahale edeceğini öğrenmesi gerekiyor. Bu beceri, önümüzdeki yıllarda neredeyse her beyaz yakalı rolün temel yetkinliği hâline gelecek. Kurumunuzu bugünden bu yönde hazırlamak, yarının rekabet avantajıdır. Ben buna "ajan okuryazarlığı" diyorum; tıpkı bir nesil önce bilgisayar okuryazarlığının zorunlu hâle gelmesi gibi, bu da öyle olacak.