MCP ve A2A ötesinde: semantik bir agent runtime katmanı için gerekçe

İki yazı, tek argüman: protokoller semantik değildir

dev.to'da yayımlanan iki yazı — biri İngilizce, biri Portekizce, ikisi de aynı yazarın hesabından — agentic mimarinin nereye gittiğine dair ortak bir sav sunuyor. Argüman şu: günümüz agent altyapısı iletişimi ve yürütmeyi çözmüş durumda, ama anlamı çözememiş. Önerilen çözüm, mevcut protokollerin yerine geçmek yerine onların üzerinde duran bir "semantik agent runtime" katmanı.

Yazılar AllasCode adlı bir projeyle bağlantılı; Portekizce yazı, bu projeyi yazarın Intent çevresinde tasarlanmış, uyarlanabilir ve kendini onaran davranışlara sahip, Zig ile yazılmış kendi runtime'ı olarak tanımlıyor. Önemli bir nokta, yazar bunu tamamlayıcı olarak konumlandırıyor: MCP, A2A, WebAssembly, OpenTelemetry ve LangGraph gibi çerçeveler altta yerinde kalarken, semantik katman protokolden, çerçeveden, modelden veya uygulama dilinden bağımsız kalıyor.

Mevcut yığın gerçekte neyi kapsıyor

İngilizce yazıya göre modern agent yığınının her parçası farklı bir soruya cevap veriyor:

• MCP, bir agent'ın araçlar ve bağlamla nasıl iletişim kurduğunu ele alıyor. Belirtimi araçları, kaynakları, prompt'ları, elicitation'ı, sampling'i, bildirimleri ve yetkilendirmeyi kapsıyor ve protokolü stateless olarak tanımlıyor; uzun ömürlü durum açık tanımlayıcılarla temsil ediliyor.
• A2A, agent'tan agent'a iletişimi ele alıyor ve belgeleri onu açıkça MCP'ye tamamlayıcı olarak çerçeveliyor. Sürüm 1.0, çoklu kiracılık (multi-tenancy), imzalı Agent Card'lar, çoklu protokol bağlamaları, polling, streaming ve webhook'lar gibi üretime yönelik özellikler ekledi.
• WebAssembly ve sandbox'lar yalıtılmış, taşınabilir yürütmeyi ele alırken; tracing, policy engine'lar ve iş akışı motorları gözlemlenebilirlik, izin/ret kararları ve adım koordinasyonunu kapsıyor.

Hepsi faydalı, diyor yazar — ama hiçbiri tek başına, kullanıcının gerçek niyetinin ne olduğunu, hangi aktörün yetkili olduğunu, hangi durum geçişinin gerçekleştiğini, sonucun kabul edilmiş sayılıp sayılmayacağını ya da bunların gerçekleştiğini kanıtlayan kanıtın ne olduğunu söyleyemiyor.

HTTP benzetmesi

Temel benzetme web'den alınıyor. HTTP fiilleri, header'ları ve durum kodlarını tanımlar; bir banka transferinin ne olduğunu tanımlamaz. Bir transfer endpoint'ine yapılan istek işlemi taşıyabilir, ama yetkilendirme, geçerlilik, defter geçişleri, kesinlik ve kanıt soruları üst katmanlara aittir. Yazılara göre aynı ayrım artık agentic sistemlerde de var: MCP, A2A, HTTP ve mesaj broker'ları taşır; WASM, container'lar ve native runtime'lar yürütür; onların üstündeki bir şey, neyin yürütüldüğünü ve bunu doğru yürütmenin ne anlama geldiğini tanımlamalıdır.

Önerilen zincir: Intent'ten Proof'a

Her iki yazının önerdiği model sabit bir semantik zincir:

Intent, yani ne olması gerektiği; Behavior, bunu karşılayan adlandırılmış davranış; Action, davranışı uygulayan somut işlemler; Actor, bunu gerçekleştirmeye yetkili varlık; Runtime, yürütüldüğü yer; Result, gerçekte ne olduğu; Acceptance, sonucun belirtilen ölçütleri karşılayıp karşılamadığı; ve Proof, bunun gerçekleştiğini gösteren kanıt.

Somut bir örnek: "123 numaralı siparişimi iptal et" niyeti bir CancelOrder davranışına çözümleniyor; siparişi doğrulama, iptal politikasını denetleme, siparişi iptal etme ve bir event yayınlama gibi action'lara ayrılıyor — yetkili bir Actor (bir müşteri, bir sipariş servisi, bir yönetici) tarafından, Zig veya Rust'tan bir container'a ya da bir MCP sunucusuna kadar mevcut herhangi bir runtime üzerinde gerçekleştiriliyor.

Tamamlanmış, kabul edilmiş demek değildir

Yazılardaki en keskin ayrım, çoğu kez birbirine karıştırılan üç farklı şey arasında: bir protokol yanıtı, bir yürütüm sonucu ve kabul edilmiş bir sonuç. MCP'nin Tasks uzantısı working, completed, failed ve cancelled gibi durumlarla dayanıklı durum makineleri tanımlar — ama completed raporlayan bir task yalnızca protokol işleminin bittiği anlamına gelir. Bir ödemenin gerçekten tahsil edildiğini, doğru alıcıya, doğru tutarla yapıldığını doğrulamaz. Portekizce yazı özlü bir örnek veriyor: niyet "ürünü yarın almak", sonuç "sipariş oluşturuldu", kabul ret.

Çoklu agent zincirleri sorumu keskinleştiriyor. Bir müşteri agent'ı A2A üzerinden rezervasyon, ödeme ve bildirim agent'larına delege olduğunda, yazılar şunu soruyor: orijinal Intent kimin, her action için kim yetkilendirildi, hangi durum geçişi başarı sayılır, ödeme başarılı olup bildirim başarısız olursa ne olur ve toparlanmadan hangi agent sorumlu?

Neden önemli

Agent araçları geliştiren herkes için bu, bir sonraki rekabetçi katmanın faydalı bir çerçevelendirmesi. MCP hızla araç entegrasyonunda temel gereklilik haline geliyor ve A2A agent delegasyonunu standartlaştırıyor — bu da transport ve keşfin farklılaştırıcı olmaktan çıkması demek. Yazıların ortaya koyduğu açık sorular, özellikle her yürütüm için kabul ölçütleri ve doğrulanabilir kanıt, kurumların agent'lara gerçek işlemler emanet etmeden önce sorduğu sorularla doğrudan örtüşüyor. Bankacılık ve e-ticaretteki alan modelleriyle benzetme — Order, Ledger ve Settlement gibi kavramların transport katmanının üzerinde durması — agent sistemlerinin de muadiline ihtiyaç duyacağına işaret ediyor.

Perspektifi korumakta fayda var: bu, dev.to'da blog yazıları olarak yayımlanmış tek bir projenin önerisi, bir endüstri standardı değil; hem yazı da aynı yazardan geliyor ve kendi runtime'ını savunuyor. Ama betimledikleri temel boşluk — tamamlanmayı raporlayan ama başarıyı hiçbir zaman tanımlamayan protokoller — mevcut halleriyle MCP Tasks ve A2A'nın gerçekten açık bıraktığı bir boşluk.