Bedrock AgentCore'un A2A Agent Card'i Dört Kat Daha Büyük ve System Prompt'u Taşıyor

Neler karşılaştırıldı

dev.to'da yayımlanan bir yazı dar kapsamlı bir soru soruyordu: aynı mantıksal agent'ı üç bulutta dağıt ve her birinin A2A agent card'ında tam olarak ne yayınladığına bak. Yazar, us-west-2 bölgesindeki Amazon Bedrock AgentCore Runtime üzerinde bir Strands agent'ı, Cloud Run üzerinde bir Google ADK agent'ı ve Azure Container Apps üzerinde bir Microsoft Agent Framework agent'ı çalıştırdı, ardından her kartı çekip dönen baytları olduğu gibi saklayan küçük bir araç kullandı. Tüm ölçümler 25 Ağustos 2026'da alındı.

Bu süreçte hiçbir şey çağrılmadı — model çalıştırması, prompt icrası veya token harcaması yok — dolayısıyla sonuçlar yalnızca discovery işlemini yansıtıyor. Boyut farkı ilk sürpriz: AgentCore kartı 2.109 bayt, Azure'ınki 1.924 ve Cloud Run'ınki yalnızca 528 bayt; yani aynı mantıksal agent için AWS kartı kabaca dört kat daha büyük.

Kart çekmek kendi IAM iznini gerektiriyor

AgentCore'da bir kartı okumak InvokeAgentRuntime kapsamına girmiyor. Ayrı bir aksiyon gerektiriyor: bedrock-agentcore:GetAgentCard; yalnızca invocation izni veren bir policy, resource'lar nasıl kapsamlandırılırsa kapsamlandırılsın bu çekimi reddediyor. GetAgentCard eklendiğinde, onu runtime ARN'ine ve alt öğelerine göre kapsamlandırmak yeterli — wildcard resource gerekmiyor.

Hata, authentication'dan uzak bir yerde ortaya çıktığı için teşhisi zor: endpoint'e ulaşan ama kartta başarısız olan bir credential, istemci tarafında transport veya protokol hatası olarak görünür. Yazarın çözümü, imzalamayı istek başına değil HTTP client üzerinde bir kez yapılandırmak. Üç bulut arasında yalnızca AgentCore, discovery'yi ayrıca verilebilir kılıyor — bunun bir özellik olduğunu bildiğiniz sürece.

Kart invocation yolunun altında duruyor

AgentCore'un agent başına bir hostname'i yok. Runtime, URL-escaped bir ARN üzerinden adreslenir ve kart, gerçek çağrıların kullandığı /invocations/ yolunun altında sunulur; oysa Cloud Run ve Azure Container Apps, kendi hostname'lerinde standart well-known yolunda yayınlar.

Bu yerleşim basit araçları bozuyor. Bir gidiş-dönüşü yalnızca yol /.well-known/ ile başladığında discovery sayan bir tracer, her AgentCore kart çekimini invocation olarak sınıflandırır; yazarın kendi tracer'ı da bunu yaptı ve kural, yolu önek yerine son eke göre eşleştirecek şekilde değiştirilene kadar her AWS çekimini yanlış kategoriye kaydetti.

AgentCore ayrıca kart çekimlerinde de — yalnızca invocation'larda değil — session header'ını zorunlu kılıyor: X-Amzn-Bedrock-AgentCore-Runtime-Session-Id, en az 33 karakter uzunluğunda ve SigV4 imzasının içinde yer alması gerektiğinden imzalamadan önce ayarlanmalı.

Kart system prompt'u ile geliyor

AgentCore kartının büyük bölümü sıradan — ad, açıklama, text/plain girdi ve çıktı modları, JSONRPC transport, protokol sürümü 0.3 — ta ki skills dizisine gelene kadar. Orada yeteneğin (skill) açıklaması, agent'ın system prompt'unun tamamını, 1.258 karakterlik talimat metnini içeriyor ve etiketleri agent'ın arkasındaki modeli adlandırıyor (us.amazon.nova-micro-v1:0).

Yazara göre bu bir AgentCore hatası değil: a2a-sdk kart oluşturucusu, bir Strands agent'ının skill açıklamasını onun instruction'larından dolduruyor. Kart, GetAgentCard çağırma izni olan herkese sunulduğu için, prompt veya model ID'nin herkese açık olmaması gerekiyorsa skill açıklamalarının açıkça ayarlanması öneriliyor.

Kartın biçimi bulutu değil SDK'yı izliyor

Tam alan envanterinde, zorunlu alanların tamamı üç bulutta da görünüyor; 1.0 spesifikasyonundan supportedInterfaces de öyle. securityRequirements hiçbirinde görünmüyor. Eski 0.x alanları olan url ve preferredTransport, AgentCore ve Container Apps'te var ama Cloud Run'da yok; documentationUrl, iconUrl, provider, securitySchemes ve signatures gibi isteğe bağlı alanlar ise hiçbir yerde bulunmuyor.

AgentCore ve Container Apps her satırda aynı — eşleşen capability, skill ve interface anahtarları, aynı 0.1.0 sürüm dizesi, aynı skill ID'si, aynı 1.258 karakterlik açıklama — yalnızca hostname ve bir etiket değerinde farklılaşıyorlar. İki bulut, iki framework, yapısal olarak özdeş kartlar. Açıklama şu: Strands ve Microsoft Agent Framework ikisi de aynı a2a-sdk route helper'ı üzerinden servis yaparken ADK kendi kartını kuruyor; dolayısıyla kartın biçimini, onu barındıran platform değil, onu inşa eden SDK belirliyor. Yazar, iki framework'ün tek bir SDK'ya devretmesinin framework'lerin önemsiz olduğunu kanıtlayamayacağı ve bu ağın bir framework'ü iki SDK arasında test etmediği uyarısını da kabul ediyor.

Hibrit kartlar daha uyumlu olanlar

Hem supportedInterfaces'i hem de 1.0 spesifikasyonunun emekliye ayırdığı eski url ve preferredTransport alanlarını taşıyan AgentCore ve Container Apps, iki istemci nesline aynı anda hizmet veren hibrit kartlar yayınlıyor. Cloud Run yalnızca supportedInterfaces taşıyor. Yazarın uyumluluk tablosunda, url okuyan 0.x dönemi bir istemci AgentCore ve Container Apps ile çalışıyor ama anahtarın bulunmadığı Cloud Run'da başarısız oluyor; supportedInterfaces okuyan istemciler ise her yerde çalışıyor.

Neden önemli

A2A, çok agent'lı sistemlerin discovery sözleşmesi hâline geliyor ve bu karşılaştırma, protokol desteğinin pratikte çok farklı anlamlara gelebileceğini gösteriyor. Operasyonel olarak: AWS'de bedrock-agentcore:GetAgentCard iznini açıkça verin, invocation önekli kart konumu için yola dayalı sınıflandırmayı düzeltin ve imzalı session header'ını unutmayın. Daha büyük yönetişim sorunu şu: bu yığın, agent'ın system prompt'unu ve model ID'sini varsayılan olarak yayınlıyor; dolayısıyla discovery ve gizlilik birlikte yapılandırılmalı. Yapısal olarak birlikte çalışabilirlik, şimdilik agent'ı hangi bulutun çalıştırdığından çok bir framework'ün hangi kart oluşturucuyu kullandığına bağlı — herhangi bir agent ağının taşınabilir olduğunu ilan etmeden önce akılda tutulması gereken bir uyarı.