{"slug": "foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed", "title": "Foundry as Master, Bedrock as Remote: The Smoke Test Finally Passed", "summary": "A developer successfully demonstrated a cross-cloud AI agent integration where Microsoft Foundry acts as the master coordinator and Amazon Bedrock AgentCore as a remote specialist, using the Agent2Agent (A2A) protocol. The smoke test on July 30, 2026, verified that Foundry can execute a local MCP baseline, call an AgentCore A2A agent, and apply deterministic verification, with the verified result showing exact agreement between the two paths. The repository, xbill9/foundry-bedrock-a2a-currency, passes 66 deterministic tests and includes a custom JWT authorizer for AgentCore to handle authentication across clouds.", "body_md": "I wanted one specific piece of coverage:\n\n```\nMicrosoft Foundry (master)\n    ├── MCP ──> live exchange-rate baseline\n    └── A2A ──> Amazon Bedrock AgentCore (remote specialist)\n```\n\nOn July 30, 2026, that direction worked end to end.\n\nThis matters because I had already tested the reverse topology—AgentCore as\n\ncoordinator and Foundry as remote. A cross-cloud claim based on only one\n\ndirection is weak. This run proves Foundry can own the request, execute its\n\nlocal MCP baseline, call an AgentCore A2A agent, and apply deterministic\n\nverification.\n\nThe code and sanitized evidence are in\n\n[xbill9/foundry-bedrock-a2a-currency](https://github.com/xbill9/foundry-bedrock-a2a-currency).\n\nThe input was `100 USD → EUR`\n\n. I invoked the Foundry-hosted coordinator through\n\nits Responses endpoint in all three benchmark modes:\n\n| Mode | Path | Observed result | Adapter time |\n|---|---|---|---|\n`mcp_only` |\nFoundry → local MCP | 87.13800 EUR | 359 ms |\n`a2a_only` |\nFoundry → A2A → AgentCore | 87.138 EUR | 25,105 ms |\n`verified` |\nboth paths concurrently | exact agreement | 28,163 ms |\n\nThe verified result reported:\n\n```\n{\n  \"relative_difference\": \"0\",\n  \"agreed\": true,\n  \"failures\": {}\n}\n```\n\nThat is one smoke case, not a latency distribution and not a completed\n\nbenchmark matrix. The useful conclusion is narrower: the Foundry-master cloud\n\nboundary works, including authentication, discovery, invocation, and\n\ndeterministic comparison.\n\nThe repository also passes 66 deterministic tests; one optional integration\n\ntest is skipped without its external dependency.\n\nCurrency conversion makes interoperability easy to falsify. Every quote carries\n\nthe amount, rate, converted amount, observation time, source, and adapter\n\nlatency. Money and rates use Python `Decimal`\n\n.\n\nThe coordinator—not an LLM—checks agreement:\n\n```\ndifference = abs(primary.converted_amount - verifier.converted_amount)\nrelative_difference = difference / abs(primary.converted_amount)\nagreed = relative_difference <= Decimal(\"0.005\")\n```\n\nThe model handles intent and chooses one tool call. Framework-independent code\n\nowns arithmetic, concurrency, timeout policy, and failure reporting.\n\nThe stable application depends on two interfaces:\n\n`ExchangeRateTool`\n\n;`RemoteCurrencyAgent`\n\n.Microsoft Agent Framework and Foundry hosting sit outside those interfaces.\n\nStrands and AgentCore sit outside them on the other side. Flipping the clouds\n\ndid not require rewriting the domain service.\n\nThat is more valuable than merely getting two SDKs into one process. Each cloud\n\ncan be deployed independently, and the benchmark can still compare MCP-only,\n\nA2A-only, and verified execution.\n\nAgentCore's default runtime authorization is IAM/SigV4. That is appropriate for\n\nAWS callers, but a Foundry-hosted container does not automatically have AWS\n\ncredentials.\n\nFor this test I configured AgentCore with a custom JWT authorizer and used a\n\nCognito machine-to-machine client:\n\n```\nFoundry container\n    ├── client_credentials ──> Cognito token endpoint\n    └── Bearer JWT ──────────> AgentCore A2A runtime\n```\n\nThe coordinator's A2A adapter now supports OAuth client credentials, caches the\n\ntoken until shortly before expiry, and retains static bearer support for other\n\npeer profiles. The AgentCore authorizer validates the issuer, client, and\n\nrequired `currencybench/invoke`\n\nscope.\n\nNo token participates in the domain layer.\n\nThe successful diagram hides most of the work. These were observed failures,\n\nnot hypothetical risks.\n\nThe coordinator client uses A2A 1.x. AgentCore's A2A extra currently requires\n\nthe 0.3 line in the deployed server bundle. Installing both into the same\n\nbundle produced an unsatisfiable dependency graph.\n\nThe fix was architectural: pin the AgentCore application bundle to its\n\ncompatible A2A SDK while keeping the Foundry-side client separate. The network\n\nprotocol interoperated even though the Python packages did not share a\n\nversion.\n\nA direct AWS CLI invocation worked, but the Foundry container could not sign an\n\nAWS request. Switching the runtime to custom JWT authorization and adding the\n\nOAuth adapter made the remote callable without embedding AWS credentials.\n\nThe first hosted `a2a_only`\n\ncall failed cleanly:\n\n```\n{\n  \"failures\": {\n    \"a2a\": \"timeout: adapter timed out\"\n  },\n  \"elapsed_ms\": 10010\n}\n```\n\nA direct remote call had already taken about 25 seconds. The adapter was\n\nworking; the benchmark policy was too aggressive for a cold cross-cloud path.\n\nThe hosted timeout is now 60 seconds. The next A2A-only invocation completed in\n\n25.1 seconds.\n\nThe hosted-agent remote build repeatedly ended with `ImageError: Container`\n\n. I switched to a prebuilt, digest-pinned image in Azure\n\nimage not found\n\nContainer Registry.\n\nThe next failure was more precise: registry authentication. Three identities\n\nwere visible—the Foundry account, the project, and the per-agent runtime\n\nidentity. Image pull uses the **project managed identity**. Granting the other\n\ntwo `AcrPull`\n\ndid not help.\n\nThe deployment became active after:\n\nA soft-deleted Foundry account blocked recreation until it was purged. Project\n\nrole assignments also took time to propagate. Those are deployment-plane\n\nfacts, distinct from whether A2A works at runtime.\n\nIn verified mode, Foundry started both adapters. Its MCP leg returned rate\n\n`0.87138`\n\n; the AgentCore specialist returned rate `0.87138`\n\n. Deterministic code\n\ncomputed a relative difference of zero and marked the quotes as agreed.\n\nThe MCP result also carried a stale-observation warning. The coordinator\n\npreserved it rather than letting the model smooth it away.\n\nThe hosted response took about 45 seconds end to end while the measured adapter\n\nwork took 28.2 seconds. That gap includes model and hosted-response overhead.\n\nWith one observation, it would be irresponsible to call either number a\n\nbenchmark.\n\nObserved:\n\nNot yet established:\n\nThat distinction is the point of the project. The result is coverage, not a\n\nvictory lap: Microsoft Foundry works as the main cloud, and Amazon Bedrock\n\nAgentCore works as its authenticated remote A2A specialist.", "url": "https://wpnews.pro/news/foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed", "canonical_source": "https://dev.to/gde/foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed-680", "published_at": "2026-07-31 17:44:17+00:00", "updated_at": "2026-07-31 18:02:53.649883+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools", "artificial-intelligence"], "entities": ["Microsoft Foundry", "Amazon Bedrock AgentCore", "MCP", "A2A", "Cognito", "JWT", "xbill9/foundry-bedrock-a2a-currency"], "alternates": {"html": "https://wpnews.pro/news/foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed", "markdown": "https://wpnews.pro/news/foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed.md", "text": "https://wpnews.pro/news/foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed.txt", "jsonld": "https://wpnews.pro/news/foundry-as-master-bedrock-as-remote-the-smoke-test-finally-passed.jsonld"}}