AWS A2A Demo: LangChain Orchestrator, Strands on AgentCore, OAuth Across Accounts

On November 12, 2026, AWS published a deployable A2A reference architecture where a LangChain enterprise orchestrator on Amazon ECS talks to a Strands compliance agent on Amazon Bedrock AgentCore in a separate AWS account — using the Agent-to-Agent protocol without either team importing the other's SDK.

If you sell an agent SaaS or run agents that must call partner-built skills, this is AWS's answer to framework lock-in: discover capabilities through Agent Cards, authenticate with OAuth, and keep tool internals private while still composing workflows.

TL;DR

Why A2A on AWS now

AWS notes A2A is now a Linux Foundation project with industry supporters. Without a standard, every ISV writes custom HTTPS glue per customer framework — the same integration swamp that MCP reduced for tools, but at the agent boundary.

Our A2A versus MCP explainer separates layers: MCP wires one agent to databases and APIs; A2A wires agents to agents where neither should see the other's prompts or tool lists.

AWS's earlier Part 4 interoperability post showed two Strands agents on A2A. November 12 adds cross-framework proof (LangChain plus Strands), cross-account trust, and OAuth in both directions — the pattern regulated enterprises ask for when a compliance vendor sits outside the VPC.

AWS A2A multi-agent delegation with a hub routing tasks to partner agents across accounts

Architecture walkthrough

The post diagrams three agents in two accounts:

Enterprise account

1. Enterprise Orchestrator — user questions enter through API Gateway, forwarded via VPC link and internal NLB to ECS. At startup it downloads the SaaS Agent Card from /.well-known/agent-card.json and registers one LangChain tool per skill.
2. Enterprise Context Agent — serves policy metadata (data classification, escalation contacts). The SaaS agent reaches it only through a partner API endpoint registered at onboarding.

SaaS account

3. Compliance SaaS Agent — Strands @tool functions simulate AWS Config / Security Hub style findings. The Agent Card advertises one curated skill, not internal tool names — so customer models see product capabilities, not implementation.

Request path (simplified)

• User obtains Cognito token, asks a compliance question.
• Orchestrator model decides to invoke the external skill.
• Orchestrator fetches enterprise pool token from Secrets Manager, sends A2A message to AgentCore URL pinned at discovery.
• SaaS agent callbacks to context agent with SaaS pool token for production account lists and policies.
• Results return upstream; orchestrator summarizes for leadership.

Private subnets, no public IPs on enterprise agents, and fail-closed token fetch (no empty bearer) match patterns in Agent Registry governance.

Interoperability: LangChain without Strands

The post's proof point is explicit: orchestrator code uses httpx and JSON-RPC, not Strands SDK. If the ISV rewrote its agent in another A2A framework but kept the card and wire format, enterprise code stays stable.

That mirrors why we track Agent Registry discovery separately from runtime auth: contracts live at the protocol layer, not the Python import layer.

Snippet concept from AWS (abridged):

• Build payload method: message/send with text parts.
• POST to pinned agent_url from card discovery — never trust redirect URLs from messages.
• On 401, refresh OAuth token once and retry.

OAuth bearer tokens crossing account boundaries in the AWS A2A reference architecture

Bidirectional callback security

One-way demos break when the callee needs caller-only data. AWS's SaaS agent:

1. Verifies the callback URL registered at onboarding.
2. Fetches the enterprise context Agent Card anonymously.
3. Obtains SaaS Cognito token.
4. Calls enterprise partner API.

Failures collapse to a single model-facing string — "Enterprise context unavailable" — while details log on the SaaS side. That is how you avoid leaking stack traces into customer-facing agent transcripts.

Compare to Bedrock AgentCore Gateway patterns where one hop returns cited answers; A2A here is multi-hop peer negotiation with separate audit trails per account.

MCP inside, A2A outside

AWS states production SaaS agents might use MCP internally to reach Config APIs while exposing A2A externally. Builders should not conflate the two URLs:

If you already run MCP gateways on AgentCore, think of A2A as the customer-facing flange — especially when customers standardize on LangChain, Strands, or future Linux Foundation adapters.

Deploy and cost notes

Prerequisites include two accounts, Anthropic Claude Sonnet 4.6 enabled in Bedrock (plus Nova Lite in enterprise account), and Jupyter with AWS CLI profiles. Notebook 3 deploy takes about 20 minutes; cleanup sections tear down VPC, Fargate, and AgentCore resources.

AWS warns about Bedrock, AgentCore, Fargate, and VPC charges — run cleanup after labs. For teams comparing cloud agent hosts, pair this sample with UAEF evaluation framework thinking: measure cross-org latency and token use before production SLAs.

What to try this week

1. Clone AWS's linked GitHub repo and run notebook 1 onboarding JSON exchange — practice public-only handoffs (issuer URLs, scopes, endpoints).
2. Diff your existing MCP OpenAPI specs against Agent Card skills — decide which capabilities are customer-facing.
3. Map Cognito pools to AgentCore Identity patterns you may already use for MCP OAuth.
4. If you are an ISV, publish one curated skill first; keep scanning tools private until card versioning is stable.

Notebook deployment sequence (from AWS)

AWS orders three Jupyter notebooks:

Only public values cross organizational email — no shared secrets. That matches how regulated banks onboard vendors: metadata first, credentials later via each side's secret store.

Prerequisites worth repeating: two accounts in us-east-1, us-east-2, or us-west-2, Anthropic Claude Sonnet 4.6 enabled (first-time Anthropic form per account), enterprise account also needs Amazon Nova Lite for the context agent.

Security decisions embedded in the sample

• Pinned agent URLs after card discovery — mitigates open-redirect style attacks if a malicious card sneaks into onboarding.
• Separate Cognito pools — enterprise users never receive SaaS pool tokens and vice versa.
• Partner API for callbacks — SaaS cannot hit arbitrary intranet hosts; only registered callback hostnames.
• Synthetic compliance data in demo — production would wire Config/Security Hub/GuardDuty readers behind MCP internally while still exposing one A2A skill externally.

Compare to prompt injection social engineering themes: more integration surface means more identity binding work — A2A adds peers, not fewer auth checks.

When to choose A2A versus MCP-only

Observability gaps to plan

AWS's post focuses on wiring, not trace UX. In production, log:

• OAuth token refresh failures (orchestrator 401 retry path).
• Callback latency — bidirectional flows double network hops.
• Skill name chosen by LLM — detect routing drift after prompt edits.

Pair with Agent DLC if compliance questions require release gates per external skill.

Cost modeling notes

Charges accrue across Fargate tasks, Bedrock tokens (Sonnet 4.6 for two agents, Nova Lite for context), AgentCore runtime, API Gateway, and cross-account data transfer. Demo cleanup sections are mandatory — idle NAT gateways and public ALBs dominate lab bills.

For multi-tenant ISVs, per-customer Agent Cards may mean per-customer OAuth clients; account for Cognito client limits and rotation runbooks.

Failure modes from HN-style operations experience

Although this launch is fresh, similar agent integrations fail predictably:

• Card URL typos at onboarding — orchestrator tools point at stale skills forever until restart.
• Clock skew on JWT expiry — manifests as flaky 401 retries.
• Rate limits on partner API during batch compliance scans — needs queueing on SaaS side.

Document runbooks beside architecture diagrams.

Language note on Linux Foundation A2A

AWS states A2A graduated to Linux Foundation governance, which matters for procurement: standards with foundation homes tend to pick up multi-vendor conformance tests over time. Betting on A2A for ISV edges is partly a bet that LangChain, Strands, Google, and AWS keep Agent Card schemas compatible across minor versions — still validate with contract tests each release.

Related on explainx.ai

• What is A2A versus MCP
• AWS Agent Registry runtime discovery
• Agent Registry push sync
• Bedrock AgentCore seven-layer framework
• AgentCore Web Answer GA
• UAEF agent evaluation
• Agent DLC lifecycle post

Model IDs, notebook timings, and A2A SDK pin versions are accurate as of the November 12, 2026 AWS blog post.