Bedrock AgentCore's A2A Agent Card Is Four Times Larger and Carries the System Prompt

What was compared

A write-up on dev.to posed a narrow question: deploy the same logical agent on three clouds and see exactly what each publishes on its A2A agent card. The author ran a Strands agent on Amazon Bedrock AgentCore Runtime in us-west-2, a Google ADK agent on Cloud Run, and a Microsoft Agent Framework agent on Azure Container Apps, then used a small harness to fetch each card and store the exact bytes returned. All measurements were taken on 25 August 2026.

Nothing was invoked along the way — no model runs, no prompt execution, no token spend — so the results isolate discovery itself. The size spread is the first surprise: the AgentCore card is 2,109 bytes, Azure's is 1,924 and Cloud Run's is just 528, making the AWS card roughly four times larger for the same logical agent.

Fetching a card needs its own IAM permission

On AgentCore, reading a card is not covered by InvokeAgentRuntime. It requires a separate action, bedrock-agentcore:GetAgentCard, and a policy granting only invocation denies the fetch no matter how its resources are scoped. Once GetAgentCard is present, scoping it to the runtime ARN and its children is enough — no wildcard resource needed.

The failure is awkward to diagnose because it surfaces far from authentication: a credential that reaches the endpoint but fails on the card reads as a transport or protocol error on the client side. The author's fix is to configure signing once on the HTTP client rather than per request. Of the three clouds, only AgentCore makes discovery separately grantable — a feature, provided you know it exists.

The card sits under the invocation path

AgentCore has no per-agent hostname. The runtime is addressed through a URL-escaped ARN, and the card is served beneath the same /invocations/ path the real calls use, while Cloud Run and Azure Container Apps publish at the standard well-known path on their own hostnames.

That placement breaks naive tooling. A tracer that treats a round trip as discovery only when the path starts with /.well-known/ will file every AgentCore card fetch as an invocation; the author's own tracer did this and logged every AWS fetch under the wrong category until the rule was changed to match the path suffix instead.

AgentCore additionally demands its session header on card fetches, not just invocations: X-Amzn-Bedrock-AgentCore-Runtime-Session-Id, at least 33 characters long, and it must fall inside the SigV4 signature, so it has to be set before signing.

The card ships the system prompt

Most of the AgentCore card is unremarkable — name, description, text/plain input and output modes, JSONRPC transport, protocol version 0.3 — until the skills array. There, the skill's description contains the agent's entire system prompt, 1,258 characters of instruction text, and its tags name the model behind the agent (us.amazon.nova-micro-v1:0).

According to the author, this is not an AgentCore bug: the a2a-sdk card builder fills in a Strands agent's skill description from its instructions. Because the card is served to anyone with permission to call GetAgentCard, the advice is to set skill descriptions explicitly if the prompt or model ID should not be public.

Card shape follows the SDK, not the cloud

Across the full field inventory, every required field appears on all three clouds, as does supportedInterfaces from the 1.0 spec; securityRequirements appears on none of them. The legacy 0.x fields url and preferredTransport show up on AgentCore and Container Apps but not Cloud Run, and optional fields such as documentationUrl, iconUrl, provider, securitySchemes and signatures are absent everywhere.

AgentCore and Container Apps agree on every row — matching capability, skill and interface keys, the same version string 0.1.0, the same skill ID, the same 1,258-character description — differing only in hostname and one tag value. Two clouds, two frameworks, structurally identical cards. The explanation is that Strands and Microsoft Agent Framework both serve through the same a2a-sdk route helper, while ADK builds its own card, so the card's shape is set by the SDK that builds it rather than the platform hosting it. The author concedes the caveat that two frameworks delegating to one SDK cannot prove frameworks are irrelevant, and this mesh does not test one framework across two SDKs.

Hybrid cards are the more compatible ones

By carrying both supportedInterfaces and the legacy url and preferredTransport fields that the 1.0 spec retired, AgentCore and Container Apps emit hybrid cards that serve two client generations simultaneously. Cloud Run carries only supportedInterfaces. In the author's compatibility table, a 0.x-era client that reads url works against AgentCore and Container Apps but fails against Cloud Run, where the key is absent, while clients reading supportedInterfaces work everywhere.

Why it matters

A2A is becoming the discovery contract for multi-agent systems, and this comparison shows that protocol support can mean very different things in practice. Operationally: grant bedrock-agentcore:GetAgentCard explicitly on AWS, fix path-based classification for the invocation-prefixed card location, and remember the signed session header. The bigger governance issue is that this stack publishes the agent's system prompt and model ID by default, so discovery and confidentiality must be configured together. Structurally, interoperability currently hinges more on which card builder a framework uses than on which cloud runs the agent — a caution worth holding before declaring any agent mesh portable.