The Setup: A Multi-Cloud Currency Workflow #
The goal was to create a currency conversion pipeline where a Strands Agents coordinator handles the orchestration. To keep the data honest, both the AWS side and the GCP side were pulling from the same Frankfurter daily reference rates. If the two clouds disagreed on a conversion, we knew the issue was with the protocol or the model orchestration, not the data source.
The architecture looked like this:
CLI / Boto3 Test Runner (AWS SigV4 Auth)
|
Bedrock AgentCore Runtime hosted agent (AWS, us-east-1, Amazon Nova Micro)
Strands Agents coordinator
|
+-- MCP stdio --> Frankfurter rates (in-container stdio process)
|
+-- A2A v1.0 --> Cloud Run (GCP, us-central1)
|
Google ADK agent (gemini-2.5-flash)
|
MCP HTTP --> Frankfurter rates
To get a real baseline, we ran the tests in three specific modes:
: The coordinator just uses the local MCP rate tool (Baseline).mcp_onlya2a_only: The coordinator delegates everything to the remote ADK agent via A2A v1.0.** verified**: The coordinator gets a result from the local tool and then independently verifies it against the remote ADK agent.
Deployment and Execution #
For anyone looking for a practical tutorial on how to replicate this, the core logic involves wrapping the AgentCore coordinator and using a benchmark suite to measure the delta between local and remote calls. We used Amazon Nova Micro on the AWS side and Gemini 2.5 Flash on the GCP side.
One critical architectural decision we made was enforcing a strict rule: the LLM never does the actual math. Currency conversion is a nightmare for LLMs but trivial for Python's Decimal
library. By off the calculation to the MCP tool, we isolated the benchmark to focus on the AI workflow and communication overhead.
Key Findings and Analysis #
Instead of relying on "vibes," we compared this run against a previous benchmark using Microsoft Foundry on Azure. Here is the breakdown of the cross-cloud performance:
Interoperability: The AgentCore-hosted agent successfully discovered and invoked the Google ADK agent through an A2A agent card without needing any custom framework glue.Latency Overhead: Remote-agent verification introduces a noticeable spike in response time compared to local MCP calls.Reliability: The "verified" mode significantly improved failure recovery. When the local tool lagged or produced an anomaly, the A2A cross-check acted as a safety net.Cloud Comparison: AWS Bedrock AgentCore Runtime showed competitive performance when compared to our previous Azure/Foundry tests, though the network hop to GCP remains the primary bottleneck.
This deep dive proves that while cross-cloud A2A is possible and reliable, the tradeoff is a hit to latency. For mission-critical data where accuracy is non-negotiable, that overhead is a price worth paying.
https://github.com/xbill9/bedrock-adk-a2a-currency
Next Agentic AI Deployment: My Team's Transition to LLM Agents →