ATLAS ZOOM

Yapay Zekânın Ortak Dili

Agentic AI dünyasında standartlar çoğalıyor: MCP, A2A ve daha fazlası. Ancak hepsi aynı problemi çözmüyor. Asıl soru şu: Farklı modellerin, araçların ve ajanların birlikte çalıştığı bu yapıda tek bir ortak dil gerçekten mümkün mü?

Harness’tan bağlantı protokollerine, ajanlar arası iletişimden maliyet standartlarına

Yapay zekâ ajanları artık yalnızca cevap üretmiyor. Şirket sistemlerine bağlanıyor, araç çağırıyor, başka ajanlara iş veriyor ve kaynak tüketiyor. Bu yüzden yeni tartışma tek bir modelin ne kadar zeki olduğundan daha büyük: Farklı ajanlar, araçlar ve kurumlar birbirleriyle hangi katmanlar üzerinden çalışacak?

Bir satın alma yöneticisi olduğunuzu düşünün. Yapay zekâ asistanınıza, “Önümüzdeki ayın üretimi için eksik malzemeleri belirle, onaylı tedarikçilerden teklif topla ve bana bir karşılaştırma hazırla” diyorsunuz. Bu basit görünen talep aslında birden fazla teknik katmanı aynı anda çalıştırıyor.

Önce modelin bir çalışma döngüsüne oturması gerekiyor. Ardından stok ve üretim sistemlerine erişmesi, gerekirse başka ajanlarla iletişim kurması, kimin adına ve hangi yetkiyle hareket ettiğinin bilinmesi, yapılan çağrıların izlenmesi ve ortaya çıkan maliyetin ölçülmesi gerekiyor.

Burada MCP, A2A, AGNTCY, harness, function calling, API’ler, FinOps ve FOCUS gibi kavramlar aynı cümlede görünmeye başlıyor. Fakat bunlar birbirinin rakibi değil ve hepsi aynı problemi çözmüyor. Üstelik bir kurum MCP kullanmadan, başka bir kurum A2A kullanmadan da çalışan bir agentic sistem kurabilir.

Bu nedenle “Yapay zekânın ortak dili hangisi?” sorusunu tek bir protokol arayışı olarak okumak yanıltıcı olabilir. Daha doğru soru şu: Agentic AI stack’inin hangi katmanlarında ortak arayüzlere, hangi katmanlarında ise değiştirilebilir uygulamalara ihtiyacımız var? Bu yazıda ortak dili tek bir standart değil, katmanlardan oluşan bir birlikte çalışabilirlik yığını olarak ele alıyoruz.

Aynı haritada farklı görevler

Katman	Örnek yaklaşımlar	Ne çözer?
Runtime	Harness, framework runtimes	Agent loop, context, state, tool kullanımı ve onay akışları
Araç ve veri bağlantısı	MCP, function calling, OpenAPI/REST, gRPC, native connectors	Ajanın dış sistemlere, verilere ve araçlara erişimi
Ajanlar arası birlikte çalışabilirlik	A2A, custom APIs, mesajlaşma katmanları	Bağımsız ajanlar arasında görev, durum ve sonuç paylaşımı
Keşif, kimlik ve yönetişim	AGNTCY, IAM, RBAC/ABAC, credential sistemleri	Ajanı bulma, kimliğini doğrulama, yetkisini ve sınırlarını yönetme
Özel arayüz ve alan protokolleri	Agent Client Protocol, Agentic Commerce Protocol, AG-UI	Editör/istemci bağlantısı, ticaret akışları ve kullanıcı etkileşimi
Gözlemlenebilirlik	OpenTelemetry, tracing, loglar	Model, tool ve agent çağrılarını izleme ve ilişkilendirme
Ekonomik kontrol	FinOps, FOCUS	Maliyet ve kullanım verisini ortaklaştırma, harcamayı değere bağlama

Bu katmanları tek bir “protokoller listesi” olarak okumak kolay. Oysa runtime, araç bağlantısı, ajanlar arası iletişim, kimlik, gözlemlenebilirlik ve maliyet kontrolü farklı problemlerdir. Bir katmanda açık standart tercih edilirken başka bir katmanda doğrudan API, kurum içi servis veya vendor-native connector daha doğru olabilir. Aşağıdaki harita bu ayrımı gösteriyor.

Bu tablo bir teknoloji paketi önermiyor. Asıl fikir, mimari katmanları birbirinden ayırmak: aynı ihtiyacı bugün MCP, yarın başka bir protokol veya doğrudan API karşılayabilir. Kalıcı olan ürün adı değil, çözülen problemdir.

Harness: modeli ajana dönüştüren çalışma katmanı

Bir dil modeli tek başına ajan değildir. Çok adımlı bir görevi sürdürebilmesi, araç çağırması, context ve state tutması, gerektiğinde onay istemesi ve hata sonrası devam edebilmesi için modelin çevresinde çalışan bir runtime gerekir. Son dönemde bu çalışma katmanı için “agent harness” kavramı giderek daha sık kullanılıyor.

Microsoft Agent Framework harness'ı model ve tool çağrılarını, context ve state'i, approval politikalarını ve agent loop'u yöneten çalışma zamanı katmanı olarak tanımlıyor. OpenAI de Agents API tarafında Codex harness'ının context yönetimi, araç kullanımı ve alt ajan koordinasyonunu managed bir runtime içinde sunduğunu anlatıyor. Bunlar aynı ürün değil. Ortak nokta, modeli gerçek bir çalışma çevrimine oturtma ihtiyacı. [26] [27]

Harness bir protokol değildir. Hangi bağlantı standardını kullanacağınızı da tek başına belirlemez. Aynı harness MCP üzerinden bir araca erişebilir, doğrudan bir REST API çağırabilir veya kurumun kendi connector'ını kullanabilir. Bu ayrım önemli, çünkü agentic mimaride runtime ile bağlantı katmanını birbirine bağlamak bizi gereksiz yere tek bir teknolojiye kilitleyebilir.

Araç ve veri bağlantısı: MCP önemli, tek yol değil

Satın alma ajanımızın ilk işi stok ve üretim sistemlerinden veri almak. Bunu yapmak için tek bir yöntem yok. Uygulama MCP kullanabilir; function calling ile kendi backend fonksiyonlarını çağırabilir; OpenAPI ile tanımlanmış bir HTTP servisine, gRPC servisine, native SDK'ya veya özel bir connector'a bağlanabilir. [1] [28] [29] [30]

MCP'nin önemi burada ortaya çıkıyor. Model Context Protocol, AI uygulamalarının araçlara ve kaynaklara erişimi için ortak bir arayüz sunuyor. Bir tool veya veri kaynağı MCP sunucusu üzerinden açıldığında uyumlu istemciler aynı bağlantı modelini kullanabiliyor. VS Code gibi ürünlerde genel kullanıma açılması da bunun yalnızca teorik bir standart olmadığını gösteriyor. [1] [10]

Fakat “araç bağlantısı” ile “MCP” aynı şey değil. Bir kurumun güvenli ve çalışan bir agentic sistemi olması için MCP kullanması gerekmiyor. Özellikle mevcut kurumsal API'ler, servis mesh'i, gateway'ler veya native connector'lar zaten olgunsa doğrudan entegrasyon daha basit olabilir. MCP'nin avantajı taşınabilirlik ve ortak arayüz potansiyelidir; zorunluluk değildir.

Üstelik MCP'nin kendisi de gelişiyor. Güncel revizyon 2026-07-28 ve değişiklikler oturum yapısından başlangıç bağlantısı aşamasına kadar protokol davranışını etkileyebiliyor. “MCP destekliyoruz” cümlesi bu nedenle yeterli değil: hangi revizyon, hangi capability'ler, hangi authentication modeli ve hangi uzantılar? [9]

Daha temel güvenlik soruları da protokolün dışında kalıyor. Araçtan dönen verinin doğru olması, modelin bu veriyi güvenli yorumlaması, çağrının gerçekten yetkili kullanıcı adına yapılması ve kritik işlem öncesinde onay alınması ayrıca tasarlanmalı. MCP bağlantıyı standartlaştırabilir; kurumsal güvenliği otomatik olarak çözmez. [1]

Ajanlar arası iletişim: A2A güçlü bir örnek, kategori daha büyük

Stok açığı belirlendiğinde sıradaki iş tedarikçilerden teklif toplamak olabilir. Karşı tarafta bağımsız bir ajan varsa iki sistemin konuşması gerekir. Bu iletişim özel bir HTTP API, gRPC, mesaj kuyruğu veya kurumların kendi protokolüyle kurulabilir. Açık bir standart kullanmak özellikle farklı vendor ve framework'ler arasında birlikte çalışabilirlik istendiğinde daha değerli hale gelir.

A2A bu katmandaki en güçlü açık standartlardan biri. Bağımsız ve iç yapısı birbirine kapalı ajanların yeteneklerini tanıtması, görev alması, durum paylaşması ve sonuç döndürmesi için ortak bir model sunuyor. A2A v1.0 Mart 2026'da production-ready sürüm olarak yayımlandı; Google Cloud da A2A ajanlarının Cloud Run üzerinde çalıştırılmasına yönelik dokümantasyon sağlıyor. [2] [11] [24]

A2A'nın resmi dokümantasyonu MCP ile ayrımı oldukça net kuruyor: MCP araç ve veri bağlantısını, A2A ise ajanlar arası iletişimi hedefliyor. Bu faydalı bir zihinsel model, fakat bütün mimarinin yalnızca bu iki protokolden oluştuğu anlamına gelmiyor. Aynı platform içindeki iki ajan için özel API daha basit olabilir; kurumlar arası ve vendor bağımsız bir dünyada ise açık birlikte çalışabilirlik standardı daha değerli hale gelir.

Keşif, kimlik ve yetki ayrı bir katman

Bir ajanın başka bir ajanla konuşabilmesi, o ajana güvenebileceğimiz anlamına gelmez. “Bu ajan kim?”, “Kimin adına hareket ediyor?”, “Hangi görevi yapmaya yetkili?” ve “Bu yetki ne zaman sona eriyor?” farklı sorular.

AGNTCY bu alanda dizin, kimlik, mesajlaşma ve gözlemlenebilirlik bileşenleri geliştiren açık kaynak bir altyapı projesi. Tek bir protokol değil. Ajanların bulunması, kimliklerinin taşınması ve farklı altyapı parçalarının birlikte çalışması için çeşitli bileşenler sunuyor. [3]

Ancak AGNTCY de zorunlu katman değil. Bir kurum mevcut IAM, service identity, RBAC/ABAC, secret management ve API gateway altyapısını kullanabilir. Kritik olan ürün adı değil, kimliğin doğrulanması ile yetkinin uygulanmasının birbirinden ayrılmasıdır. Bir ajanın gerçekten tedarikçiye ait olduğunu doğrulamak, onun sizin şirketiniz adına sipariş verebileceği anlamına gelmez. AGNTCY'nin görevle sınırlı yetkilendirme çalışmaları da bu ayrımı açıkça ele alıyor. [14]

ACP neden tek bir alternatif değil?

“ACP var, MCP yerine onu kullanalım” demek de çoğu zaman kategori hatasına yol açıyor. Çünkü ACP kısaltması bugün farklı katmanlardaki en az üç ayrı projeyi ifade edebiliyor.

Agent Communication Protocol adıyla geliştirilen ACP, A2A ile birleşti. Agent Client Protocol ise kod editörleri ile coding agent'ları arasındaki bağlantıya odaklanan başka bir proje. Agentic Commerce Protocol ise OpenAI ve Stripe tarafından alıcı, ajan ve satıcı arasındaki ticaret akışları için geliştirildi. Bunların çözdüğü problemler aynı değil. [4] [5] [15]

AG-UI kullanıcı ile ajan arasındaki arayüzü, AP2 ödeme yetkilendirmesini ele alıyor. Agent Skills ve AGENTS.md gibi açık biçimler ise beceri veya çalışma talimatının taşınmasına yardımcı oluyor. Bu parçaları “MCP alternatifi” diye tek sepete koymak yerine hangi katmanda hangi problemi çözdüklerine bakmak daha doğru. [16] [17] [22] [23]

Gözlemlenebilirlik ve ekonomik kontrol

Teklifler geldiğinde geride model çağrıları, tool kullanımları, başarısız denemeler, tekrarlar ve belki başka ajanlara delegasyon kalıyor. Kurumun yalnızca sistemin çalışıp çalışmadığını değil, hangi görev için ne kadar kaynak tüketildiğini de görebilmesi gerekiyor.

OpenTelemetry'nin GenAI semantik kuralları token kullanımı, model çağrıları ve işlem süresi gibi gözlemlenebilirlik verilerine ortak adlar vermeye çalışıyor. Bu alan hâlen gelişiyor. Telemetri toplamak da tek başına ekonomik anlam üretmiyor; çağrıları görev, kullanıcı, ajan ve iş sonucuyla ilişkilendirmek gerekiyor. [18]

FinOps bu noktada teknoloji harcamasını değer ve finansal sorumlulukla ilişkilendiren operasyonel pratik olarak devreye giriyor. FOCUS ise farklı sağlayıcıların maliyet ve kullanım verisini ortak bir şemaya yaklaştırmayı hedefleyen açık spesifikasyon. Biri yönetim pratiği, diğeri veri standardı. [6] [7]

FOCUS 1.4 yayımlanmış standart. AWS'nin belgelenmiş FOCUS 1.2 dışa aktarımı, bir standardın yayımlanması ile sağlayıcı desteğinin aynı anda ilerlemediğini gösteriyor. 1.5 çalışma kapsamı AI model kimliği, AI faturalama örnekleri ve harcamayı kişi, servis veya ajana bağlayabilecek alanlar üzerinde ilerliyor. Bunları bugünün 1.4 yetenekleri gibi anlatmamak gerekiyor. [19] [20] [25]

Ortak dil tek bir protokol değil

MCP yapay zekânın ortak dili değil. A2A da değil. Harness zaten bir protokol değil. AGNTCY bir altyapı projesi, FOCUS bir veri spesifikasyonu, FinOps ise operasyonel bir pratik.

Bize göre “ortak dil” dediğimiz şey giderek bir birlikte çalışabilirlik yığınına dönüşüyor:

Runtime → Tool & Data Connectivity → Agent Interoperability → Identity & Governance → Observability → Economic Control

Bu yığının her katmanında tek bir kazanan olmak zorunda değil. MCP'nin yanına doğrudan API'ler, function calling veya native connector'lar oturabilir. A2A'nın yanında custom agent APIs yaşayabilir. Kurum mevcut IAM sistemini koruyabilir. Önemli olan bu katmanların birbirinden ayrılabilmesi ve gerektiğinde değiştirilebilmesi.

Açık standartların stratejik değeri de burada. Ortak bir arayüz entegrasyon maliyetini azaltabilir, daha küçük sağlayıcıların sisteme katılmasını kolaylaştırabilir ve vendor değişimini mümkün hale getirebilir. Fakat açık protokol kullanmak tek başına bağımsızlık sağlamaz. Kimlik altyapısı, dağıtım kanalı, özel uzantılar, runtime veya yönetim araçları tek bir sağlayıcıya bağlıysa protokol açık olsa bile sistem pratikte kapalı kalabilir.

Bu yüzden kurumların “MCP destekliyor musunuz?” veya “A2A var mı?” sorularından daha fazlasını sorması gerekiyor: Aynı tool'u MCP olmadan çağırabilir miyim? Başka bir agent communication katmanına geçebilir miyim? Kimlik ve yetki sistemim protokolden bağımsız mı? Log ve maliyet verisini dışarı alabiliyor muyum? Özel bir connector bütün mimariyi tek bir vendor'a kilitliyor mu?

Atlas yorumu

Agentic AI'ın olgunlaşması bizi model yarışından sistem mimarisi yarışına taşıyor. En güçlü modelin seçilmesi artık problemin yalnızca bir parçası. Modelin nasıl çalıştırıldığı, hangi araçlara nasıl bağlandığı, başka ajanlarla nasıl konuştuğu, hangi kimlikle hareket ettiği ve ekonomik hesabının nasıl tutulduğu aynı derecede önemli hale geliyor.

Bu nedenle geleceğin “ortak dili” tek bir sözlük olmayabilir. Daha çok, birbirinden ayrılabilen ve gerektiğinde değiştirilebilen katmanların ortak çalışma kuralları olacak.

Bugünün popüler standardı yarın değişebilir. MCP büyüyebilir, A2A başka biçimlere evrilebilir, yeni protokoller ortaya çıkabilir. Referans mimariyi kalıcı yapan şey bu isimlere bağlı kalmak değil, her teknolojiyi doğru probleme yerleştirebilmek.

Yapay zekânın ortak dili henüz tamamlanmış değil. Ama belki de tamamlanması gereken tek bir dil hiç olmayacak. Asıl hedef, farklı modellerin, araçların, ajanların ve kurumların birbirini anlayabildiği, kontrolün ve değiştirme hakkının kullanıcıda kaldığı bir sistem kurabilmek.