A2A ve MCP: Gelişen ajan ekosistemi için iki tamamlayıcı protokol

AI ajanlarının — kullanıcılar adına akıl yürütme ve eylem gerçekleştiren otonom veya yarı otonom yazılım varlıkları olarak — artan adopte edilmesi, uygulama mimarisinde yeni bir katmanın ortaya çıkmasına neden oluyor.

2025'in başlarında, bu durumu ele almak için iki farklı protokol ortaya çıktı — A2A (Agent-to-Agent) ve MCP (Model Context Protocol). Rollerini anlamanın basit bir yolu şudur:

A2A: Ajanlar birbirleriyle nasıl etkileşime girer

MCP: Ajanlar araçlar veya dış bağlamla nasıl etkileşim kurar

referans: https://google.github.io/A2A/#/topics/a2a_and_mcp

Bunlar, birden fazla ajanın, birden fazla LLM'in ve işbirliği yapması gereken birden fazla bağlam kaynağının bulunduğu sistemler oluşturmanın temel zorluklarını ele alıyor.

Bir çerçeve olarak şunu söyleyebiliriz: “MCP dikey entegrasyon (uygulamadan modele) sağlar, A2A ise yatay entegrasyon (ajandan ajana) sağlar”.

Geliştirici olun ya da olmayın, AI ürünleri veya acentelik sistemleri inşa eden herkesin temel mimariyi anlaması gerekiyor — çünkü ürünleri, kullanıcı etkileşimlerini, ekosistemleri ve uzun vadeli büyümeyi nasıl tasarladığımızı şekillendirir.

Bu makale, her iki protokolü de basit ve anlaşılır bir şekilde tanıtıyor ve geliştiriciler ve AI ürün geliştiricileri için anahtar sonuçları vurguluyor.

A2A (Agent-to-Agent) Nedir?#

A2A (Agent-to-Agent), Google ve 50'den fazla endüstri ortağı tarafından geliştirilen açık bir protokoldür. Amacı, ajanlar arasında birlikte çalışabilirliği sağlamak — kimin tarafından inşa edildiklerinden, nerede barındırıldıklarından veya hangi çerçeveyi kullandıklarından bağımsız olarak.

A2A protokol mekanizması#

A2A, iletişim mekanizması olarak HTTP(S) üzerinden JSON-RPC 2.0 kullanır ve güncellemeleri yayınlamak için Sunucu Gönderili Olaylar (SSE) desteğine sahiptir.

A2A iletişim modelleri#

A2A, iki ajanın nasıl etkileştiğine dair yapılandırılmış bir model tanımlar. Bir ajan, bir isteği veya görevi başlatan “istemci” ajanı rolünü üstlenir ve diğeri ise isteği alan ve yerine getirmeye çalışan “uzak” ajan olarak hareket eder. İstemci ajan, önce hangi ajanın belirli bir işi yapmak için en uygun olduğunu belirlemek amacıyla yetenek keşfi yapabilir.

Burada bir soru ortaya çıkıyor, ajanlar birbirini nasıl keşfeder. Her ajan, bir Ajan Kartı (genellikle bir /.well-known/agent.json gibi standart bir URL'de barındırılan bir JSON meta veri belgesi) yayımlayarak yeteneklerini, becerilerini, API uç noktalarını ve kimlik doğrulama gerekliliklerini tanımlar.

Bir müşteri ajan, bir Ajan Kartını okuyarak mevcut görev için uygun bir ortak ajanı belirleyebilir - esasen o ajanın neleri bildiği veya yapabileceği ile ilgili bir dizin sağlar. Hedef bir ajan seçildikten sonra, müşteri ajan bir Görev nesnesi oluşturarak iletir.

referans: https://google.github.io/A2A/#/

Görev yönetimi#

A2A'daki tüm etkileşimler, görevlerin gerçekleştirilmesine odaklanır. Bir görev, isteğin ayrıntılarını içeren ve durumunu takip eden yapılandırılmış bir nesnedir (protokolün şeması tarafından tanımlanır).

A2A'da her ajan iki rolden birini oynar:

• İstemci Ajan: bir görevi başlatır
• Uzak Ajan: görevi alır ve işler

Görevler, herhangi bir türden işi içerebilir: bir rapor oluşturma, veri alma, bir iş akışı başlatma. Sonuçlar eserler olarak döndürülür ve ajanlar, yürütme sırasında koordine etmek veya açıklama yapmak için yapılandırılmış mesajlar gönderebilir.

İşbirliği ve içerik anlaşması#

A2A, basit görev taleplerinden ötesini destekler — ajanlar, metin, JSON, görüntü, video veya etkileşimli içerik içeren zengin, çok parçalı mesajlar alışverişi yapabilir. Bu, her ajanın üstesinden gelebileceği veya görüntüleyebileceği şeye dayalı olarak format müzakeresine olanak tanır.

Örneğin, uzak bir ajan bir grafiği ham veri veya bir görüntü olarak geri gönderebilir ya da bir etkileşimli formu açma talebinde bulunabilir. Bu tasarım, ajanların dahili araçları veya belleği paylaşmasını gerektirmeden esnek, modülarite-agnostik iletişimi destekler.

Kullanım durumu örneği#

A2A'nın bir kurumsal senaryoda nasıl kullanılabileceğine dair gerçek dünya örneği:

Büyük bir şirkette yeni bir çalışan işe alınır. Onboarding sürecine birden fazla sistem ve departman katılır:

• İK, bir kayıt oluşturmalı ve hoş geldiniz e-postası göndermelidir
• BT, bir dizüstü bilgisayar ve şirket hesapları sağlamalıdır
• Tesisler, masa ve erişim kartı hazırlamalıdır

Geleneksel olarak, bu adımlar manuel olarak veya dahili sistemler arasında sıkı bir şekilde bağlantılandırılmış entegrasyonlarla yerine getirilirdi.

Her sisteme özel API'ler yerine, her departman kendi acentasını A2A protokolünü kullanarak ortaya koyar:

Çoklu ajan sistemi — diyelim ki OnboardingPro (örneğin onboarding-agent.company.com) — tüm onboarding iş akışını koordine eder.

1. Keşif: Her ajanın .well-known/agent.json dosyasını okuyarak yetenekleri ve kimlik doğrulamayı anlar.
2. Görev delegasyonu:
   • İK ajanına createEmployee görevi gönderir.
   • BT ajanına setupEmailAccount ve orderHardware görevlerini gönderir.
   • Tesislere assignDesk ve generateBadge gönderir.
3. Yayınlanan güncellemeler: Ajanlar, Sunucu Gönderili Olaylar (örneğin, “laptop shipped”, “desk assigned”) kullanarak ilerleme aktarır.
4. Eser koleksiyonu: Nihai sonuçlar (örneğin, PDF rozeti, onay e-postaları, hesap kimlik bilgileri) A2A eserleri olarak geri döndürülür.
5. Tamamlama: OnboardingPro işe alım müdürüne onboarding tamamlandığında bildirim gönderir.

MCP (Model Context Protocol) Nedir?#

MCP (Model Context Protocol), Anthropic tarafından geliştirilen bir protokoldür ve farklı bir sorunu ele alır: Dış uygulamaların dil modeli tabanlı bir acenteye çalışma anında yapılandırılmış bağlam ve araçlar sağlaması.

Ajanslar arası iletişimi etkinleştirmek yerine, MCP bağlam penceresine odaklanır — bir LLM'nin çalışma belleği. Amacı:

• İlgili araçları, belgeleri, API işlevlerini veya kullanıcı durumu modelinin çıkarım oturumuna dinamik olarak enjekte etmek
• Modellerin işlevler çağırmasına veya belgeleri almasına olanak tanımak, istemciyi veya mantığı sert kodlamadan

MCP ana mimari#

MCP'yi anlamak için önce genel mimariyi — tüm parçaların nasıl birlikte çalıştığını — anlamanız gerekir.

MCP Barındırıcısı: “Konuştuğunuz AI”#

MCP Barındırıcısını AI uygulaması olarak düşünebilirsiniz — Claude Masaüstü veya kodlama asistanınız gibi.

Bu, kullandığınız arayüzdür — yazdığınız veya konuştuğunuz yer.

Modelin daha iyi cevaplar vermesine yardımcı olacak araçları ve verileri çekmeye çalışır.

MCP İstemcisi: “Bağlayıcı”#

MCP İstemcisi, AI barındırıcınızı (Claude gibi) dış dünyaya bağlayan yazılım parçasıdır. Bir anahtar kutusu gibi — farklı MCP Sunucuları ile güvenli, birbiriyle bire bir bağlantılar yönetir. AI bir şeye erişmek istediğinde, istemci üzerinden gider.

ChatGPT, Claude sohbeti veya Cursor IDE gibi araçları MCP barındırıcıları olarak düşünmek faydalıdır — etkileşimde bulunduğunuz arayüzü sağlarlar. Perde arkasında, MCP sunucuları aracılığıyla farklı araçlara ve veri kaynaklarına MCP istemcisi kullanırlar.

referans: https://modelcontextprotocol.io/introduction

MCP Sunucusu: “Araç sağlayıcı”#

Bir MCP Sunucusu, belirli bir aracı veya yeteneği ortaya çıkaran küçük, odaklanmış bir programdır — örneğin:

• Bilgisayarınızdaki dosyaları arama
• Yerel bir veritabanında veri arama
• Dış bir API çağrısı yapma (hava durumu, finans, takvim gibi)

Her sunucu MCP protokolünü izler, böylece AI neler yapabileceğini ve nasıl çağrılacağını anlayabilir.

Yerel veri kaynakları: “Kendi dosyalarınız ve hizmetleriniz”#

Bazı MCP Sunucuları kendi makinenizdeki şeylere bağlanır — örneğin:

• Belgeler ve klasörler
• Kod projeleri
• Veritabanları veya yerel uygulamalar

Bu, AI'nin verilerinizi buluta yüklemeden arayabilmesi, alabilmesi veya hesaplayabilmesi anlamına gelir.

Uzaktan hizmetler: “API'ler ve Çevrimiçi araçlar”#

Diğer MCP Sunucuları internete bağlıdır — onlar konuşur:

• API'ler (örneğin: Stripe, Notion, GitHub)
• SaaS araçları
• Buluttaki şirket veritabanları

Bu sayede AI örneğin “GitHub sunucusuna çağrı yap ve açık PR'ların listesine ulaş” diyebilir.

MCP artık uzak MCP sunucularına bağlanmayı destekliyor. Bu, bir MCP istemcisinin daha güçlü yetenekler kazanması anlamına gelir. Teorik olarak,

Doğru MCP sunucu seti ile kullanıcılar her MCP istemcisini 'her şey uygulaması'na dönüştürebilir.

referans: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Hepsini bir araya getirme#

Şimdi her şeyin birlikte nasıl çalıştığını görmek için bir diyagram kullanacağız.

1. AI'dan karmaşık bir şey istersiniz
2. AI (barındırıcı) yardım için istemciye sorar
3. İstemci doğru MCP sunucusunu çağırır — belki dosyaları kontrol eden veya bir API'ye ulaşan bir tane
4. Sunucu geri veri gönderir veya bir işlev yürütür
5. Sonuç modeli tamamlamak için geri gönderilir

A2A ve MCP — Karşılaştırma#

Nasıl birlikte çalışırlar#

Alternatif olmaktan ziyade, A2A ve MCP tamamlayıcıdır. Birçok sistemde her ikisi de birlikte kullanılacaktır.

Örnek iş akışı#

1. Bir kullanıcı, kurumsal ajan arayüzünde karmaşık bir istek gönderir.
2. Orkestrasyon ajanı, A2A kullanarak alt görevleri özel ajanlara (örneğin, analitik, İK, finans) devreder.
3. Bu ajanlardan biri, bir arama işlevi çağırmak, bir belge almak ya da bir modeli kullanarak bir şey hesaplamak için kendi içinde MCP kullanır.
4. Sonuç, A2A aracılığıyla bir eser olarak döndürülür, son ucundan uca ajan işbirliğini modüler araç erişimi ile mümkün kılar.

Bu mimari, ajanlar arası iletişimi (A2A) ile ajan içi yetenek çağrısını (MCP) birbirinden ayırır — sistemi daha kolay yapılandırılabilir, ölçeklenebilir ve güvenli hale getirir.

Sonuç#

A2A, bir ağ üzerinden diğer ajanlarla konuşmak için ajalar ile ilgilidir — güvenli, asenkron ve görev merkezli.

MCP, bir model oturumuna yapılandırılmış beceriler enjekte etmek, LLM'lerin araçlar ve veriler üzerinde mantıklı bir şekilde düşünmesine olanak sağlamakla ilgilidir.

Birlikte kullanıldıklarında, modüler, çoklu ajan sistemlerini desteklerler; bu sistemler hem genişletilebilir hem de birlikte çalışabilir durumdadır.

MCP ve A2A'nin Temel Altyapısının Ajan Ürün Pazarlarının Geleceğini Nasıl Şekillendirebileceği#

Son olarak, bu temel teknik altyapının AI pazarının geleceğini nasıl şekillendirebileceğine ve AI ürünleri geliştiren insanlar için ne anlama geldiğine değinmek istiyorum.

İnsan bilgisayar etkileşiminin değişimi#

Bu değişimin net bir örneği geliştirici ve hizmet iş akışlarında görülebilir. MCP sunucularının IDE'lere ve kodlama ajanlarına entegresiyle, geliştiricilerin araçlarla etkileşimi temel olarak değişiyor.

Önceden, tipik bir iş akışı doğru hizmeti aramak, barındırmayı ayarlamak, belgeleri okumak, API'leri manuel olarak entegre etmek, IDE'de kod yazmak ve bir düşük kod panosu aracılığıyla özellikleri yapılandırmak anlamına geliyordu. Her adımda bağlam değiştirme ve teknik gereksinimler nedeniyle parçalanmış bir deneyimdi.

Artık, MCP bağlantılı kodlama ajanlarıyla, bu karmaşıklıkların çoğu soyutlanabilir. Geliştiriciler, araçları daha doğal bir şekilde keşfetme ve kullanma yolu bulabilir. API entegrasyonu, genellikle ayrı bir UI veya manuel kurulum gerektirmeden kodlama sürecinin kendisi haline geliyor. (AWS veya Microsoft'un panolarının ne kadar karmaşık olabileceğini bir düşünün.). Etkileşim daha düzgün hale geliyor — öz davranışları yönlendirme hakkındadır, özellikleri birleştirme hakkında değil.

Bu modelde, kullanıcı veya geliştirici etkileşimi özellikleri yapılandırmaktan davranışları yönlendirmeye kayıyor. Bu durum ürün tasarımının rolünü de değiştirir.

Özelleşmiş teknik zorlukları kaplamak için UI'ler kullanmak yerine (örneğin, “bunu kodlamak zor, bir yapılandırma paneli yapalım”), şimdi şunları yapmalıyız:

• Baştan sona deneyimi düşünün
• AI + kullanıcı etkileşimlerinin nasıl ve ne zaman bir araya gelmesi gerektiğini tasarlayın
• AI'nin mantığı ele almasına izin verin ve kullanıcıları niyet ve akış yoluyla yönlendirin

Zorluk, AI ve kullanıcı girişi bir araya geldiğinde karar vermek, AI'nin mantığı ele almasına izin vermek ve kullanıcıları doğru zamanda ve şekilde doğru etkileşimleri nasıl ekleyeceği yönünde rehberlik etmek olacaktır.

Bir geliştirici hizmeti ve API ürünü kullanarak kullanıcı etkileşiminin nasıl değişebileceğine dair bir örnek verdim — ancak aynısı iş yazılımı için de geçerlidir. Uzun bir süre, iş araçları karmaşık ve kullanımı zor olmuştur. Doğal dil etkileşimi, bu iş akışlarının çoğunu basitleştirme potansiyeline sahiptir.

Ajan ürünü paradigmaları ve bunların SaaS üzerindeki etkisi#

MCP sunucularının giderek artan sayıda ortaya çıktığını görüyoruz. Airbnb'nin bir rezervasyon MCP sunucusu sunmasını veya Google Maps'in bir harita MCP sunucusu sağlayacağını hayal edin. Bir ajan (bir MCP istemcisi olarak), bir kerede birçok bu sunucuya bağlanabilir — önceden özel entegrasyonlar veya sıkı bağlı uygulamalar gerektiren iş akışlarının kilidini açar.

Manuel ve katı entegrasyonların yaygın olduğu SaaS dönemine kıyasla, bu model daha otonom iş akışları ve hizmetler arasında daha akıcı bağlantılar sağlar. İşte iki örnek:

1. Belgelerden tasarım

   Notion'da bir PRD yazarsınız. Bir Figma ajanı belgeyi okur ve temel konseptleri düzenleyen bir tel çerçeve otomatik olarak oluşturur — manuel geçişe gerek kalmadan.

2. Rakip araştırması, baştan sona

   Rakip analizi istersiniz. Bir grup ajan webde arama yapar, ilgili hizmetlere sizin adınıza (güvenli kimlik doğrulama ile) kaydolur, sonuçları toplar ve eserleri geriye teslim eder — zaten Notion çalışma alanınıza organize edilmiş bir şekilde.

Kimlik doğrulama ve yetkilendirme sınırları ile ilgili zorluklar#

Ajanlar arası bağlantıların, MCP istemci ile MCP sunucu bağlantılarının artışı ile birlikte, yetkilendirme ve kullanıcı kimliği doğrulama ile ilgili birçok temel ihtiyaç ortaya çıkıyor, çünkü ajan insanlar adına hareket edecek ve bu yolculuk boyunca kullanıcıların kimlik bilgileri güvenli bir şekilde sağlanmalıdır.

Şimdiye kadar ajanlar arası ve MCP'nin yeni yükselişi ile ilgili birkaç senaryo var.

1. Ajan vs SaaS ve WebsiteApp
2. MCP istemcisi (Ajan) vs MCP sunucusu
3. Kullanıcı vs Ajan
4. Ajan vs Ajan

Google'ın belirttiği gibi çoklu kimlik federasyonu ilginç bir kullanım durumu:

Örneğin, Kullanıcı U, Ajan A ile çalışıyor ve A-sisteminin tanımlayıcısı gerekiyor. Eğer Ajan A daha sonra B-sistem tanımlayıcısı gerektiren Araç B veya Ajan B'ye bağımlı hale gelirse, kullanıcı tek bir taleple hem A-sistem hem de B-sistem için kimliklerini sağlaması gerekebilir. (A-sistemi bir kurumsal LDAP kimliği ve B-sistemi bir SaaS sağlayıcı kimliği olduğunu varsayalım).

Logto, OIDC ve OAuth sağlayıcısı olan yeni nesil AI entegrasyonları için uygundur.

Esnek altyapısı ile, yeteneklerini aktif bir şekilde genişletiyoruz ve geliştiricilerin hızlı bir başlangıç ​​yapabilmesi için bir dizi eğitimi yayınladık.

Sorularınız mı var?

Bize ulaşın — ya da girin ve bugün Logto ile neler yapabileceğinizi keşfedin.