Loading today’s stories
Build1 distinct publisher3 min readUpdated
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
Compiled by The EngineerSomething wrong?How this is made
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 [4]. 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 [11]. 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 [13]. 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 [13]. 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 [14]. What Runtime buys in exchange is per-session microVM isolation, identity and scaling, without caring whether the container holds Strands, LangGraph or CrewAI [5]. 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 [16]. 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 [15], and the deploy path is a single command [12]. Nobody needs a large budget to find out whether the credential-free legs hold, which is the most useful property this project has.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
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.
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.
A coordinator asks all three agents the same question and takes the median of what comes back.
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.
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.
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.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
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.
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.
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.
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 supplied material 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.
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.
build
A2A holds on the wire. ADK, Strands and Agent Framework are still not substitutable.1 distinct publisher
leadership
Microsoft puts AI agents in Entra, which makes agent sprawl an identity team problem1 distinct publisher
build
AWS puts a number on agent displacement: IaC authoring from 3-4 weeks to minutes1 distinct publisher
build
Basic Auth becomes a gateway problem: AgentCore's Lambda interceptor keeps the password away from the model1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026