Build 1 publisher Not yet confirmed elsewhere3 min readPublished Aug 23, 2026, 1:09 PM PDT

Three clouds, one protocol, no stored credentials: the runtime becomes a swappable part

A Bedrock AgentCore agent serving Google and Azure callers over A2A pushes the vendor-specific work into the container contract rather than the agent. The credential claim is the part not yet shown.

The Engineer · Build desk

How we use AI Send a correction

What happened

One research brief is answered by three agents on three clouds: Google ADK on Cloud Run, Azure Agent Framework on Container Apps, Strands on Bedrock AgentCore Runtime.
A coordinator puts the identical question to all three and takes the median of the replies.
Strands has no A2A server of its own, so the agent's respond function sits behind the a2a-sdk reference routes with no adapter and no event-stream translation.
Four AgentCore container requirements depart from normal container practice: port 9000, exposed path /, a separate /ping, and ARM64 images only.
A single deploy command builds the image, pushes to ECR, and creates the runtime plus both IAM roles.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

capability An agent written once can be re-hosted by rebuilding a container, because the calling side never held a vendor SDK to rewrite.
cost Teams on x86 build pipelines pay a cross-compilation step before they can even attempt the swap, and that cost lands on whoever owns CI, not on the agent author.
exposure The health probe payload silently governs session lifecycle: a helpful-looking timestamp field keeps microVMs alive to MaxLifetime, so an operator can leak capacity while every dashboard reads...
constraint Nobody can lean on the credential-free property yet, because the negative controls that would prove the authenticated legs stop short in the published material.

The portable part of this build is one coroutine and a JSON document. A caller on Cloud Run or Container Apps imports no AWS SDK; it fetches `/.well-known/agent-card.json` and sends JSON-RPC over HTTP, and every leg of the mesh runs A2A v1.0 ^[9]. That is what turns the host into a component. The peer contract is the card, and the card can be served by anything.

Which is why the only genuine cross-cloud failure in the walkthrough is an address rather than a protocol. `PUBLIC_URL` cannot be baked into the image, because the card has to advertise the AgentCore invocations URL and that URL does not exist until the runtime ARN does. Omit it and the card offers `0.0.0.0:9000`, which the author reports as the defect that breaks Google ADK's own A2A client against a hosted server ^[12]. Interop broke in the metadata, one layer above everything the frameworks argue about.

The experimental design is worth reading closely. A predecessor project stood up six directed A2A edges between Bedrock AgentCore, Microsoft Foundry and Google ADK ^[14]. Six is the complete directed mesh for three participants, since each of the three calls the other two ^[17], so pairwise reachability was already settled; this run holds the work still and lets the cloud be the only thing that changes ^[14]. That is the difference between a demo and a control.

The coordinator's median is an admission about trust rather than a scoring convenience. With three answers, the middle one wins and a single outlier cannot set the result ^[18], so no vendor's runtime is authoritative inside the mesh. Design for that and a bad leg degrades the answer instead of deciding it.

The choice of AgentCore Runtime over Lambda is argued on shape: generic compute would have made the mesh two agent runtimes and a function ^[15]. What Runtime buys in exchange is per-session microVM isolation, identity and scaling, without caring whether the container holds Strands, LangGraph or CrewAI ^[4]. The framework indifference on the inside is what makes the container contract on the outside the only thing you have to learn.

The claim carrying the most weight is the one the published excerpt does not finish. The stated aim is three agents over one protocol with no stored credentials between them ^[1]. The article then turns to negative controls, on the argument that an authenticated leg is unproven without them, and the supplied text stops mid-command ^[8]. Until those runs are visible, the honest reading is buildable, not verified.

Cheap to check, at least. The agent is a Bedrock `nova-micro` model with a system prompt and one `web_search` tool ^[16], and the deploy path is a single command ^[13]. Nobody needs a large budget to find out whether the credential-free legs hold, which is the most useful property this project has.

What to watch

Publication of the negative-control runs: whether the AWS leg actually refuses unsigned or wrong-audience calls, not just accepts signed ones.
Whether a fourth host can be added to the mesh with no change to the coordinator, which is the real test of runtime swappability.
Whether the three vendors' A2A clients stay compatible as the card schema moves past v1.0.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence58
Adoption20
Hype gap+12
Incentives48
Confidence44

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
The project's stated aim is to answer one research brief with three agents on three clouds, over one protocol, with no stored credentials between them.
ReportedSupportedSource: dev.to walkthrough, AWS Builders community2 sources— create a free account to open them View cited source
[2]
Google runs an ADK agent on Cloud Run, Azure runs an Agent Framework agent on Container Apps, and AWS runs a Strands agent on Bedrock AgentCore Runtime.
ReportedSupported2 sources— create a free account to open them View cited source
[3]
A coordinator asks all three agents the same question and takes the median of what comes back.
ReportedSupported2 sources— create a free account to open them View cited source
[4]
AgentCore Runtime is a serverless runtime that runs an agent container, isolates each session in its own microVM, and handles identity and scaling; it is framework agnostic, supporting Strands, LangGraph, CrewAI or custom code.
ReportedSupported2 sources— create a free account to open them View cited source
[5]
AgentCore Runtime's container contract requires port 9000 rather than 8080, and the platform exposes path / to callers rather than the /invocations path the container serves.
ReportedSupported2 sources— create a free account to open them View cited source
[6]
A /ping endpoint must be added and is not the same as an existing /health endpoint; a container that fails the ping never reaches the point of being invoked.
ReportedSupported2 sources— create a free account to open them View cited source
[7]
ARM64 is required rather than preferred, so on an x86 host the image must be produced with docker buildx --platform linux/arm64.
ReportedSupported2 sources— create a free account to open them View cited source
[8]
The write-up states that an authenticated leg is unproven without negative controls and that the deploy script carries them as a verb, and the supplied text breaks off mid-command before those controls or their results are shown.
ReportedSupported2 sources— create a free account to open them View cited source
[9]
A2A is an open protocol in which an agent publishes a card at /.well-known/agent-card.json describing what it does and how to reach it, and speaks JSON-RPC over HTTP; this project runs A2A v1.0.
ReportedSupportedView cited source
[10]
Strands ships no A2A server integration, which the author calls the easiest starting position of the three frameworks: the respond function is dropped behind the a2a-sdk reference routes, serving the protocol's own implementation with no adapter and no event-stream translation.
ReportedSupportedView cited source
[11]
The ping response deliberately omits time_of_last_update, because a timestamp that advances on every poll reads as a continuous status change, which stops the idle session timeout from ever firing and leaks sessions until MaxLifetime.
ReportedSupportedView cited source
[12]
PUBLIC_URL has to be set after the runtime ARN exists so the agent card advertises the AgentCore invocations URL; leaving it out makes the card advertise 0.0.0.0:9000, which the author identifies as the defect that breaks Google ADK's own A2A client against a hosted server.
ReportedSupportedView cited source
[13]
One command builds the ARM64 image, pushes it to ECR, and creates the runtime and both IAM roles.
ReportedSupportedView cited source
[14]
The predecessor project put six directed A2A edges between Bedrock AgentCore, Microsoft Foundry and Google ADK; this project keeps the same brief, tool and rubric and lets the cloud be the only thing that moves.
ReportedSupportedView cited source
[15]
AgentCore Runtime was chosen over Lambda because hosting the agent on generic compute would have made the mesh two agent runtimes and a function.
ReportedSupportedView cited source
[16]
The AWS agent is a Strands Agent configured with BedrockModel us.amazon.nova-micro-v1:0, a system prompt, and a web_search tool.
ReportedSupportedView cited source
[17]
Six directed edges is the complete directed mesh for three participants, so the predecessor had already covered every ordered pair.
DerivedSupported1 source— create a free account to open them
[18]
Because the coordinator takes the median of three answers, a single outlier response cannot determine the output.
DerivedSupported1 source— create a free account to open them
[19]
Four of AgentCore Runtime's container requirements diverge from ordinary HTTP container defaults: port 9000 instead of 8080, exposed path / instead of /invocations, a mandatory /ping distinct from /health, and ARM64-only images.
DerivedSupported1 source— create a free account to open them

Sources

1 independent publisher whose own reporting we read for this story.

dev.to
1 article · August 23, 2026
Mix and Match: Serving a Bedrock Agent to Google and Azure

Next2 publishersConfirmedAgentCore's region-wide default role let one public agent's stolen credentials reach every agent in the account

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For a builder, this is a concrete recipe for putting an A2A server in front of a Strands agent on Bedrock AgentCore Runtime and having other vendors' clients call it. The reusable content is where the friction sits: Strands has no A2A server integration, which the author treats as an advantage because the respond function drops straight behind the a2a-sdk reference routes with no adapter or event-stream translation, while the vendor-specific labour moves into the container contract — port 9000, an exposed path of / against a served /invocations, a mandatory /ping distinct from /health, and ARM64-only images built via buildx. The single highest-value detail is that PUBLIC_URL must be set after the runtime ARN exists or the agent card advertises 0.0.0.0:9000 and breaks Google ADK's own A2A client. All of it is one practitioner's account of one repo, so treat it as a starting checklist rather than a verified contract.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence58: 0100
Detailed first-hand build, thinly corroborated
The source is unusually specific for a single item: runnable agent code, the exact model id, the Dockerfile environment, the buildx invocation, the deploy and verify verbs, the two negative-control curls with expected codes, and a timestamped wall-clock transcript with per-call latencies. That specificity is checkable in principle and the repo is said to be public. What holds the score down is that everything rests on one self-published practitioner account with no documentation citations for the vendor container-contract clauses, no independent replication, and a body that ends mid-sentence before the negative-control results and the complete transcript.
Adoption20: 0100
One practitioner project, one disclosed run
Adoption evidence is confined to the author's own mesh: a single three-cloud run on 2026-08-12 from a deployed master, plus a published deploy script and repo. There are no third-party users, no organisational deployments, no benchmarks, no pricing or licensing signals, and the predecessor project cited is the same author's. The protocol and runtimes involved are vendor-shipped, but this cluster supplies no evidence about their uptake beyond this project.
Hype gap+12: −100 understated0 aligned+100 overstated
Slightly ahead of what is shown
The technical claims are mostly modest and matched by artefacts, and the author explicitly flags that an authenticated leg is unproven without negative controls — self-limiting language that narrows the gap. The overshoot is confined to the framing: 'no stored credentials' across three clouds is presented as achieved, yet the supplied text shows only the expected 403s and a truncated transcript rather than observed control results, and the Google and Azure legs are asserted while only the AWS side is demonstrated. Small positive gap rather than a large one.
Incentives48: 0100
Community-channel practitioner advocacy, no disclosed sponsorship
The item is a self-published walkthrough on a developer community platform under an AWS-builders channel, and its framing favours the AWS agent runtime (including an explicit argument for AgentCore Runtime over Lambda on mesh-symmetry grounds). That is a visible reputational and ecosystem-alignment incentive of the kind normal to practitioner content. Nothing in the reporting discloses vendor payment, employment or sponsorship, and the write-up also volunteers friction and defects in the AWS path, which cuts against a purely promotional reading. Scored mid-range on the visible channel and framing only.
Confidence44: 0100
Single source, single publisher, partly truncated
Confidence is limited structurally: one publisher, one item, one author, no corroborating documentation or second account for any of the vendor-behaviour claims, and a supplied body that cuts off before the verification results. The claims that are internally evidenced by code and a dated transcript are reasonably trustworthy; the claims about platform semantics (session leak, SigV4 versus OAuth failure signatures, the ADK client defect) would need outside confirmation before being relied on.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Multi-Cloud DeploymentFollow
Serverless Agent RuntimesFollow
A2A ProtocolFollow
Container Platform ContractsFollow
Workload Identity and Signed RequestsFollow
Agent Interoperability Follow