DEV Community: xbill

Amazon Bedrock Agents Orchestrating Google ADK over A2A

xbill — Wed, 29 Jul 2026 19:14:47 +0000

This article explains how to build and test a cross-cloud currency agent. An Amazon Bedrock master agent, built with Strands Agents and hosted on Amazon Bedrock AgentCore Runtime in AWS us-east-1, delegates to a Google ADK worker on GCP Cloud Run in us-central1 over A2A v1.0. The master cross-checks the worker against an MCP exchange-rate tool and measures the latency, reliability, and failure behavior of cross-cloud verification.

What is this project trying to do?

Most Agent-to-Agent (A2A) protocol demos stop at "look, the HTTP 200 OK request succeeded." That is a smoke test, not an interoperability benchmark.

This project goes further: the Bedrock master owns the user interaction and benchmark policy. It discovers and calls a Google ADK worker running on GCP Cloud Run, then compares the worker result with a local MCP stdio exchange-rate tool backed by live Frankfurter daily reference rates.

We also compare the performance, developer experience, and wire compatibility with a previous benchmark run using Microsoft Foundry in Azure (gpt-5-mini). Together, the runs cover components hosted across AWS, Azure, and GCP.

The benchmark addresses four questions:

Can an AgentCore-hosted Bedrock master discover and invoke a Google ADK worker through an A2A agent card with no framework-specific glue?
What latency and token overhead does remote-agent verification add?
Does independently verifying an MCP tool result over A2A improve correctness or failure recovery enough to justify that overhead?
Which measurements are portable across coordinators, and which require a fully hosted AgentCore benchmark run?

Reusing the original currency agent

This builds directly on the currency agent from the previous articles in this series:

That agent — built with Google ADK, Gemini 2.5 Flash, and a FastMCP exchange-rate server backed by the free Frankfurter API — serves as the remote worker and independent verifier in this project.

The new repository adds the AgentCore coordinator and benchmark suite:

GitHub - xbill9/bedrock-adk-a2a-currency

Architecture

CLI / Boto3 Test Runner (AWS SigV4 Auth)
       |
Bedrock AgentCore Runtime hosted master      (AWS, us-east-1, Amazon Nova Micro)
Strands Agents orchestration
       |
       +-- MCP stdio --> Frankfurter rates      (in-container stdio process)
       |
       +-- A2A v1.0 --> Cloud Run               (GCP, us-central1)
                           |
                        Google ADK worker       (gemini-2.5-flash)
                           |
                        MCP HTTP --> Frankfurter rates

The Bedrock master answers every conversion request through three distinct evaluation modes:

Mode	What happens	Why it exists
`mcp_only`	Bedrock master calls the local MCP rate tool	Baseline single-agent performance
`a2a_only`	Bedrock master delegates to the GCP ADK worker over A2A v1.0	Measure remote-agent behavior and network latency
`verified`	MCP result independently checked against the remote ADK agent over A2A	Measure the accuracy-versus-overhead tradeoff

Both sides read the same Frankfurter daily reference rates on purpose: when the two clouds disagree, that measures protocol, model, and orchestration behavior, not data-source skew.

Rule one: the model never does math

Currency conversion is a poor job for an LLM and a good job for Python's Decimal. The domain layer is framework-independent and uses Pydantic models. Numeric agreement is evaluated in code using relative difference; no LLM is asked, "Do these numbers look close to you?"

difference = abs(primary.converted_amount - verifier.converted_amount)
relative = difference / abs(primary.converted_amount)
agreed = relative <= tolerance  # default 0.005 (0.5%)

The failure policy is explicit rather than emergent:

MCP fails, A2A succeeds → return the remote result, labeled unverified.
A2A fails, MCP succeeds → return the tool result with a "verification unavailable" warning.
Both succeed but disagree → return both quotes and issue a warning; never silently pick the LLM's preferred rate.
Both fail → return a strongly typed failure (validation, provider, authentication, transport, timeout, protocol); never fabricate a rate.

Because "which layer broke" is a core research question, every adapter exception is normalized into exactly one typed failure at the boundary.

The wire mismatch: A2A v0.3.0 vs. v1.0

The first attempt to connect the AgentCore coordinator to the Google ADK currency agent died immediately on invocation:

a2a.utils.errors.MethodNotFoundError: Method not found

Observed root cause: a protocol-version mismatch between A2A v0.3.0 and v1.0, with no automatic fallback negotiation in the tested client.

The modern A2A client (a2a-sdk>=1.0) calls the A2A v1.0 JSON-RPC method SendMessage.
Older ADK agents (a2a-sdk 0.3.x) only expose the v0.3.0 method message/send.
The client fetched the agent card — which explicitly declared protocolVersion: 0.3.0 — but attempted the v1.0 method anyway.

The initial ecosystem package pins were also mutually exclusive:

Package	`a2a-sdk` Requirement	Status
`strands-agents 1.50.2`	`>=1.0.0,<2`	Compatible
`google-adk 2.1.0 – 2.4.0`	`>=0.3.4,<0.4`	Incompatible
`google-adk 2.5.0`	`>=0.3.4,<2`	Compatible ✅
`a2ui-agent-sdk` (through 0.4.0)	`<0.4.0`	Incompatible ❌

google-adk 2.5.0 updated its dependencies to support a2a-sdk 1.x. However, A2UI extensions currently pin the older v0.3.0 protocol. For this benchmark, A2UI was omitted so both AWS and GCP sides could operate on A2A v1.0 (a2a-sdk 1.1.2).

Hosting the Bedrock master on Amazon Bedrock AgentCore

Deploying the master to Amazon Bedrock AgentCore Runtime involved navigating several fast-moving SDK and platform details observed during our build on 2026-07-28:

1. Model selection: Anthropic access requirements vs. Amazon Nova Micro

In the account used for this build, Anthropic models such as Claude 3.5 Sonnet required a one-time use-case submission (PutUseCaseForModelAccess) and an AWS Marketplace subscription agreement. To keep the setup automated, we configured the coordinator to use Amazon Nova Micro (us.amazon.nova-micro-v1:0). Nova Micro required no approval form in our test account, supported native tool calling in the tested workflow, and produced subsecond model responses.

2. Inference profile IDs

In our deployment, using the bare model ID (amazon.nova-micro-v1:0) returned an HTTP 400 ValidationException requiring on-demand throughput configuration. Passing the regional inference profile ID (us.amazon.nova-micro-v1:0) resolved the error.

3. CLI tooling transition

The older Python pip-based starter toolkit (agentcore configure / agentcore launch) was deprecated in June 2026. Deployment now uses the official @aws/agentcore npm CLI (Node 20+, CDK-based).

Coordinator entry point (abridged from `app/CurrencyCoordinator/main.py`)

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool
from coordinator.hosted_tool import run_currency_benchmark
from model.load import load_model

app = BedrockAgentCoreApp()
tools = [tool(run_currency_benchmark)]

# The full source defines a bounded, session-scoped agent factory here.

@app.entrypoint
async def invoke(payload, context):
    session_id = getattr(context, "session_id", "default-session")
    agent = get_or_create_agent(session_id)
    prompt = payload.get("prompt", payload.get("messages", ""))
    result = await agent.invoke_async(prompt)
    return {"result": str(result)}

if __name__ == "__main__":
    app.run()

The hosted runtime also fails closed when its GCP worker is missing:

{ "name": "CURRENCY_REQUIRE_GCP_ADK", "value": "1" }

With that setting, a2a_only and verified return
gcp_adk_not_configured if CURRENCY_A2A_ENDPOINT is absent. A deployment
can no longer appear to exercise A2A while silently using a local fixture.
The Bedrock model configuration also sets BEDROCK_MAX_TOKENS=1024
explicitly to bound output and quota usage.

The Google side: ADK on Cloud Run

The remote verifier container colocates two processes: the FastMCP Frankfurter server on localhost and the A2A app listening on $PORT. Gemini API keys are retrieved securely from GCP Secret Manager:

gcloud secrets create gemini-api-key --data-file="$HOME/gemini.key"
gcloud run deploy currency-adk-a2a \
  --source adk_agent --region us-central1 \
  --allow-unauthenticated --min-instances=0 --max-instances=2 \
  --set-secrets "GOOGLE_API_KEY=gemini-api-key:latest" \
  --set-env-vars "MCP_SERVER_URL=http://127.0.0.1:8081/mcp,GENAI_MODEL=gemini-2.5-flash"

Setting --min-instances=0 allows Cloud Run to scale to zero when idle. The coordinator's timeout is set to 60 seconds to accommodate initial container cold starts.

How to run the benchmark

The repository includes a complete local test suite that runs deterministically without credentials or cloud infrastructure:

# 1. Clone & install dependencies
git clone https://github.com/xbill9/bedrock-adk-a2a-currency
cd bedrock-adk-a2a-currency
pip3 install --user -e ".[dev]"

# 2. Run unit and integration tests (deterministic fixtures)
pytest

# 3. Test local CLI modes
currency-benchmark 100 USD CAD EUR --mode mcp_only
currency-benchmark 100 USD CAD EUR --mode verified --transport mcp-stdio

# 4. Execute full evaluation matrix
currency-evaluate --output /tmp/currency-results.jsonl --summary /tmp/currency-summary.json

To deploy and test the hosted Bedrock master:

./infra/sync_app.sh
agentcore deploy -y
agentcore invoke "Convert 100 USD to EUR and CHF in verified mode."

Hosted smoke test: Bedrock master → GCP ADK worker

On 2026-07-29, I deployed the updated master to AgentCore Runtime in
us-east-1 and invoked all three modes through the hosted
InvokeAgentRuntime API:

Hosted mode	Observed result
`mcp_only`	HTTP 200; live `mcp-stdio:frankfurter-live` quote
`a2a_only`	HTTP 200; live `gcp-adk-a2a-worker` quote
`verified`	HTTP 200; MCP and GCP ADK agreed exactly for EUR and CHF

The verified request converted 100 USD to EUR and CHF. The deterministic
comparison recorded relative_difference: "0" and agreed: true for both
currencies, with no failures or warnings. The benchmark tool completed in
approximately 3.08 seconds.

This was an end-to-end smoke test, not a full hosted latency distribution. It
exercised the complete path:

AWS SigV4 invocation
  → AgentCore Runtime
  → Nova Micro tool selection
  → MCP stdio / Frankfurter
  → A2A v1.0
  → GCP Cloud Run
  → Google ADK / Gemini
  → deterministic Decimal comparison

The smoke test also found a real orchestration bug. On the first request,
Nova Micro read “Convert 100 USD to EUR” but claimed the target currency was
missing and asked the user to confirm it. The master prompt now includes an
explicit natural-language parsing rule and forbids confirmation requests for
information already present. After redeployment, the same request called the
benchmark tool directly. A regression test preserves that behavior.

Cross-cloud benchmark results

We executed the 38-case evaluation matrix across all three modes: 114 records
per run. The 2026-07-28 warm run exercised the framework-independent
coordinator locally against the live GCP Cloud Run ADK endpoint; it did
not measure the AgentCore hosting layer. The 2026-07-27 run is the
retained Azure-era baseline. Keeping those labels explicit avoids attributing
local harness latency to AgentCore.

Observed run	Evaluation mode	Success rate	Median latency	p95 latency	Agreement rate
2026-07-28 warm local harness → GCP	`mcp_only`	100%	286 ms	540 ms	N/A
2026-07-28 warm local harness → GCP	`a2a_only`	100%	2.09 s	6.10 s	N/A
2026-07-28 warm local harness → GCP	`verified`	100%	1.87 s	4.33 s	96.77%
2026-07-27 Azure-era baseline → GCP	`mcp_only`	100%	297 ms	1.09 s	N/A
2026-07-27 Azure-era baseline → GCP	`a2a_only`	100%	1.69 s	4.82 s	N/A
2026-07-27 Azure-era baseline → GCP	`verified`	100%	1.71 s	4.15 s	96.77%

Key findings

The live protocol path was reliable: the warm 2026-07-28 run completed all 114 records successfully. Fault-injection cases are included in the aggregate, so agreement rate is not expected to be 100%.
Concurrent execution limits verification overhead: verified-mode latency is dominated by the remote A2A round trip rather than the sum of MCP and A2A latency.
Hosted AWS → GCP interoperability was observed: all three modes completed through AgentCore. The verified EUR and CHF quotes had zero relative difference, no failures, and no warnings. This remains a smoke-test result, not a 114-record hosted latency distribution.
Hosted performance remains to be measured: token usage, cost, and repeated warm/cold AgentCore distributions are still open benchmark work.

Lessons learned

Check A2A SDK major versions first: A2A v0.3.0 (message/send) and v1.0 (SendMessage) are wire-incompatible. If you see MethodNotFoundError, inspect the a2a-sdk version on both client and server before debugging prompt logic.
Use inference profile IDs on Bedrock: In our hosted deployment, the regional inference profile ID (us.amazon.nova-micro-v1:0) avoided the on-demand throughput error returned for the bare model ID.
Account for remote cold starts: A 10-second client timeout worked locally, but the Cloud Run scale-from-zero path needed a longer window. We used 60 seconds for this benchmark.
Keep math out of the prompt: Deterministic Python Decimal arithmetic prevents LLM calculation errors from affecting conversion and agreement checks. The checks therefore measure differences in returned results, not the model's arithmetic ability.
A2A verification provides independent fault detection: The faster mcp_only path is useful as a baseline, while cross-cloud A2A verification adds an independent result for failover and anomaly detection. Whether the overhead is justified depends on the workload.
Test natural-language argument extraction: Tool availability is not enough. The master model can still fail before invocation by misreading an argument that is plainly present. Keep a hosted smoke case for natural-language parsing, not only structured tool calls.

Repository and source code

The complete benchmark codebase, deployment scripts, test suite, and raw evaluation datasets are available on GitHub:

GitHub - xbill9/bedrock-adk-a2a-currency

If you are building multi-cloud agent systems with Amazon Bedrock AgentCore, Google ADK, or Microsoft Agent Framework, feedback and benchmark contributions are welcome.

Amazon Bedrock Agents Orchestrating Google ADK over A2A

xbill — Wed, 29 Jul 2026 19:13:53 +0000

What is this project trying to do?

Most Agent-to-Agent (A2A) protocol demos stop at "look, the HTTP 200 OK request succeeded." That is a smoke test, not an interoperability benchmark.

The benchmark addresses four questions:

Can an AgentCore-hosted Bedrock master discover and invoke a Google ADK worker through an A2A agent card with no framework-specific glue?
What latency and token overhead does remote-agent verification add?
Does independently verifying an MCP tool result over A2A improve correctness or failure recovery enough to justify that overhead?
Which measurements are portable across coordinators, and which require a fully hosted AgentCore benchmark run?

Reusing the original currency agent

This builds directly on the currency agent from the previous articles in this series:

That agent — built with Google ADK, Gemini 2.5 Flash, and a FastMCP exchange-rate server backed by the free Frankfurter API — serves as the remote worker and independent verifier in this project.

The new repository adds the AgentCore coordinator and benchmark suite:

GitHub - xbill9/bedrock-adk-a2a-currency

Architecture

CLI / Boto3 Test Runner (AWS SigV4 Auth)
       |
Bedrock AgentCore Runtime hosted master      (AWS, us-east-1, Amazon Nova Micro)
Strands Agents orchestration
       |
       +-- MCP stdio --> Frankfurter rates      (in-container stdio process)
       |
       +-- A2A v1.0 --> Cloud Run               (GCP, us-central1)
                           |
                        Google ADK worker       (gemini-2.5-flash)
                           |
                        MCP HTTP --> Frankfurter rates

The Bedrock master answers every conversion request through three distinct evaluation modes:

Mode	What happens	Why it exists
`mcp_only`	Bedrock master calls the local MCP rate tool	Baseline single-agent performance
`a2a_only`	Bedrock master delegates to the GCP ADK worker over A2A v1.0	Measure remote-agent behavior and network latency
`verified`	MCP result independently checked against the remote ADK agent over A2A	Measure the accuracy-versus-overhead tradeoff

Both sides read the same Frankfurter daily reference rates on purpose: when the two clouds disagree, that measures protocol, model, and orchestration behavior, not data-source skew.

Rule one: the model never does math

difference = abs(primary.converted_amount - verifier.converted_amount)
relative = difference / abs(primary.converted_amount)
agreed = relative <= tolerance  # default 0.005 (0.5%)

The failure policy is explicit rather than emergent:

MCP fails, A2A succeeds → return the remote result, labeled unverified.
A2A fails, MCP succeeds → return the tool result with a "verification unavailable" warning.
Both succeed but disagree → return both quotes and issue a warning; never silently pick the LLM's preferred rate.
Both fail → return a strongly typed failure (validation, provider, authentication, transport, timeout, protocol); never fabricate a rate.

Because "which layer broke" is a core research question, every adapter exception is normalized into exactly one typed failure at the boundary.

The wire mismatch: A2A v0.3.0 vs. v1.0

The first attempt to connect the AgentCore coordinator to the Google ADK currency agent died immediately on invocation:

a2a.utils.errors.MethodNotFoundError: Method not found

Observed root cause: a protocol-version mismatch between A2A v0.3.0 and v1.0, with no automatic fallback negotiation in the tested client.

The modern A2A client (a2a-sdk>=1.0) calls the A2A v1.0 JSON-RPC method SendMessage.
Older ADK agents (a2a-sdk 0.3.x) only expose the v0.3.0 method message/send.
The client fetched the agent card — which explicitly declared protocolVersion: 0.3.0 — but attempted the v1.0 method anyway.

The initial ecosystem package pins were also mutually exclusive:

Package	`a2a-sdk` Requirement	Status
`strands-agents 1.50.2`	`>=1.0.0,<2`	Compatible
`google-adk 2.1.0 – 2.4.0`	`>=0.3.4,<0.4`	Incompatible
`google-adk 2.5.0`	`>=0.3.4,<2`	Compatible ✅
`a2ui-agent-sdk` (through 0.4.0)	`<0.4.0`	Incompatible ❌

Hosting the Bedrock master on Amazon Bedrock AgentCore

Deploying the master to Amazon Bedrock AgentCore Runtime involved navigating several fast-moving SDK and platform details observed during our build on 2026-07-28:

1. Model selection: Anthropic access requirements vs. Amazon Nova Micro

2. Inference profile IDs

3. CLI tooling transition

The older Python pip-based starter toolkit (agentcore configure / agentcore launch) was deprecated in June 2026. Deployment now uses the official @aws/agentcore npm CLI (Node 20+, CDK-based).

Coordinator entry point (abridged from `app/CurrencyCoordinator/main.py`)

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool
from coordinator.hosted_tool import run_currency_benchmark
from model.load import load_model

app = BedrockAgentCoreApp()
tools = [tool(run_currency_benchmark)]

# The full source defines a bounded, session-scoped agent factory here.

@app.entrypoint
async def invoke(payload, context):
    session_id = getattr(context, "session_id", "default-session")
    agent = get_or_create_agent(session_id)
    prompt = payload.get("prompt", payload.get("messages", ""))
    result = await agent.invoke_async(prompt)
    return {"result": str(result)}

if __name__ == "__main__":
    app.run()

The hosted runtime also fails closed when its GCP worker is missing:

{ "name": "CURRENCY_REQUIRE_GCP_ADK", "value": "1" }

The Google side: ADK on Cloud Run

gcloud secrets create gemini-api-key --data-file="$HOME/gemini.key"
gcloud run deploy currency-adk-a2a \
  --source adk_agent --region us-central1 \
  --allow-unauthenticated --min-instances=0 --max-instances=2 \
  --set-secrets "GOOGLE_API_KEY=gemini-api-key:latest" \
  --set-env-vars "MCP_SERVER_URL=http://127.0.0.1:8081/mcp,GENAI_MODEL=gemini-2.5-flash"

Setting --min-instances=0 allows Cloud Run to scale to zero when idle. The coordinator's timeout is set to 60 seconds to accommodate initial container cold starts.

How to run the benchmark

The repository includes a complete local test suite that runs deterministically without credentials or cloud infrastructure:

# 1. Clone & install dependencies
git clone https://github.com/xbill9/bedrock-adk-a2a-currency
cd bedrock-adk-a2a-currency
pip3 install --user -e ".[dev]"

# 2. Run unit and integration tests (deterministic fixtures)
pytest

# 3. Test local CLI modes
currency-benchmark 100 USD CAD EUR --mode mcp_only
currency-benchmark 100 USD CAD EUR --mode verified --transport mcp-stdio

# 4. Execute full evaluation matrix
currency-evaluate --output /tmp/currency-results.jsonl --summary /tmp/currency-summary.json

To deploy and test the hosted Bedrock master:

./infra/sync_app.sh
agentcore deploy -y
agentcore invoke "Convert 100 USD to EUR and CHF in verified mode."

Hosted smoke test: Bedrock master → GCP ADK worker

On 2026-07-29, I deployed the updated master to AgentCore Runtime in
us-east-1 and invoked all three modes through the hosted
InvokeAgentRuntime API:

Hosted mode	Observed result
`mcp_only`	HTTP 200; live `mcp-stdio:frankfurter-live` quote
`a2a_only`	HTTP 200; live `gcp-adk-a2a-worker` quote
`verified`	HTTP 200; MCP and GCP ADK agreed exactly for EUR and CHF

This was an end-to-end smoke test, not a full hosted latency distribution. It
exercised the complete path:

AWS SigV4 invocation
  → AgentCore Runtime
  → Nova Micro tool selection
  → MCP stdio / Frankfurter
  → A2A v1.0
  → GCP Cloud Run
  → Google ADK / Gemini
  → deterministic Decimal comparison

Cross-cloud benchmark results

Observed run	Evaluation mode	Success rate	Median latency	p95 latency	Agreement rate
2026-07-28 warm local harness → GCP	`mcp_only`	100%	286 ms	540 ms	N/A
2026-07-28 warm local harness → GCP	`a2a_only`	100%	2.09 s	6.10 s	N/A
2026-07-28 warm local harness → GCP	`verified`	100%	1.87 s	4.33 s	96.77%
2026-07-27 Azure-era baseline → GCP	`mcp_only`	100%	297 ms	1.09 s	N/A
2026-07-27 Azure-era baseline → GCP	`a2a_only`	100%	1.69 s	4.82 s	N/A
2026-07-27 Azure-era baseline → GCP	`verified`	100%	1.71 s	4.15 s	96.77%

Key findings

The live protocol path was reliable: the warm 2026-07-28 run completed all 114 records successfully. Fault-injection cases are included in the aggregate, so agreement rate is not expected to be 100%.
Concurrent execution limits verification overhead: verified-mode latency is dominated by the remote A2A round trip rather than the sum of MCP and A2A latency.
Hosted AWS → GCP interoperability was observed: all three modes completed through AgentCore. The verified EUR and CHF quotes had zero relative difference, no failures, and no warnings. This remains a smoke-test result, not a 114-record hosted latency distribution.
Hosted performance remains to be measured: token usage, cost, and repeated warm/cold AgentCore distributions are still open benchmark work.

Lessons learned

Check A2A SDK major versions first: A2A v0.3.0 (message/send) and v1.0 (SendMessage) are wire-incompatible. If you see MethodNotFoundError, inspect the a2a-sdk version on both client and server before debugging prompt logic.
Use inference profile IDs on Bedrock: In our hosted deployment, the regional inference profile ID (us.amazon.nova-micro-v1:0) avoided the on-demand throughput error returned for the bare model ID.
Account for remote cold starts: A 10-second client timeout worked locally, but the Cloud Run scale-from-zero path needed a longer window. We used 60 seconds for this benchmark.
Keep math out of the prompt: Deterministic Python Decimal arithmetic prevents LLM calculation errors from affecting conversion and agreement checks. The checks therefore measure differences in returned results, not the model's arithmetic ability.
A2A verification provides independent fault detection: The faster mcp_only path is useful as a baseline, while cross-cloud A2A verification adds an independent result for failover and anomaly detection. Whether the overhead is justified depends on the workload.
Test natural-language argument extraction: Tool availability is not enough. The master model can still fail before invocation by misreading an argument that is plainly present. Keep a hosted smoke case for natural-language parsing, not only structured tool calls.

Repository and source code

The complete benchmark codebase, deployment scripts, test suite, and raw evaluation datasets are available on GitHub:

GitHub - xbill9/bedrock-adk-a2a-currency

If you are building multi-cloud agent systems with Amazon Bedrock AgentCore, Google ADK, or Microsoft Agent Framework, feedback and benchmark contributions are welcome.

Cross Cloud Amazon Bedrock AgentCore with Microsoft Foundry over A2A

xbill — Wed, 29 Jul 2026 16:52:49 +0000

I wanted to test one specific path:

Amazon Bedrock AgentCore (AWS)
    |
    +-- MCP --> live exchange-rate tool
    |
    +-- A2A v1.0 --> Microsoft Foundry hosted agent (Azure)

On July 29, 2026, that path worked end to end. An AgentCore-hosted Strands
coordinator called a Microsoft Foundry agent over A2A v1.0, authenticated with
Microsoft Entra, and compared the reply with an independent MCP conversion.

For the smoke case, both sides converted 100 USD to EUR using a rate of
0.87873 and returned 87.87300. The deterministic comparator reported zero
relative difference and no warnings.

This article shows how to run that demo and documents what failed on the way.

The code is in
xbill9/bedrock-foundry-a2a-currency.

What the demo measures

This is not intended to be a currency chatbot. Currency conversion gives the
demo a small domain with exact arithmetic, a public data source, and answers
that are easy to compare.

The coordinator supports three modes:

Mode	Path
`mcp_only`	AgentCore calls the exchange-rate MCP tool
`a2a_only`	AgentCore delegates to the Foundry agent over A2A
`verified`	Both calls run concurrently and deterministic code compares the results

The LLM selects and explains the workflow. It does not calculate the
conversion or decide whether two amounts agree. Python Decimal does that:

difference = abs(primary.converted_amount - verifier.converted_amount)
relative_difference = difference / abs(primary.converted_amount)
agreed = relative_difference <= Decimal("0.005")

If the two sources disagree, the coordinator returns both quotes. It never
asks a model which number looks better.

Architecture

CLI / test runner
       |
       | SigV4
       v
Amazon Bedrock AgentCore Runtime, us-east-1
Strands Agents coordinator, Amazon Nova Micro
       |
       +-- MCP stdio
       |      |
       |      +-- Frankfurter daily reference rates
       |
       +-- AWS Secrets Manager
       |      |
       |      +-- Entra service-principal credential
       |
       +-- Entra OAuth client-credentials exchange
       |
       +-- A2A v1.0 JSON-RPC
              |
              v
Microsoft Foundry hosted agent, East US 2
Microsoft Agent Framework, gpt-5-mini
       |
       +-- MCP stdio
              |
              +-- Frankfurter daily reference rates

The two agents use the same rate provider deliberately. This smoke test is
about transport, authentication, tool use, and cross-framework agreement, not
about reconciling different market feeds.

Prerequisites

You need:

Python 3.11 or later
Node.js 20 or later
AWS CLI v2, authenticated to the target account
Azure CLI 2.80 or later
Azure Developer CLI (azd) with the Foundry agent extension
permission to deploy AgentCore resources in AWS
permission to create a Foundry project and hosted agent in Azure

Install the AgentCore CLI and authenticate:

npm install -g @aws/agentcore

aws sts get-caller-identity
az login
azd auth login

The Azure identity performing the deployment needs Foundry Project Manager
on the Foundry project. Azure management-plane Owner or Contributor alone
does not grant the data-plane agents/write action.

Run the credential-free local checks

Clone the repository and install into the current user's Python environment.
The related benchmark repositories expose the same console-script names, so
invoking modules from the intended checkout avoids accidentally running a
sibling clone.

git clone https://github.com/xbill9/bedrock-foundry-a2a-currency.git
cd bedrock-foundry-a2a-currency

pip3 install --user --break-system-packages -e ".[dev]"
pip3 install --user --break-system-packages -r requirements.txt

PYTHONPATH=. python3 -m pytest -q

The July 29 build passed 66 tests. These cover the Decimal domain logic,
MCP subprocess transport, failure policies, Entra credential parsing, and a
Foundry-shaped authenticated A2A v1.0 server.

Try the three modes with deterministic fixture rates:

PYTHONPATH=. python3 -m coordinator.cli \
  100 USD EUR --mode mcp_only

PYTHONPATH=. python3 -m coordinator.cli \
  100 USD EUR --mode a2a_only

PYTHONPATH=. python3 -m coordinator.cli \
  100 USD EUR --mode verified --transport mcp-stdio --json

Fixture results prove orchestration and protocol behavior. They are not
financial quotes.

Deploy the Microsoft Foundry peer

The repository's deployment script packages the Foundry agent, provisions the
project and gpt-5-mini model deployment, deploys the hosted agent, enables
incoming A2A, and reads back the authenticated v1.0 agent card:

./infra/deploy_foundry_peer.sh

The script prints an endpoint shaped like:

https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a

Save it for the next steps:

export CURRENCY_FOUNDRY_A2A_ENDPOINT="https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a"

The card is not public. Foundry serves it at
agentCard/v1.0, and it requires an Entra bearer token just like the message
endpoint.

Before involving AWS, test the real Foundry peer from the local coordinator.
The local path uses your ambient Azure CLI credential:

CURRENCY_RATE_PROVIDER=frankfurter \
CURRENCY_FOUNDRY_A2A_ENDPOINT="$CURRENCY_FOUNDRY_A2A_ENDPOINT" \
PYTHONPATH=. python3 -m coordinator.cli \
  100 USD EUR \
  --mode verified \
  --transport mcp-stdio \
  --a2a-peer foundry \
  --timeout-seconds 90 \
  --json

Expect mcp-stdio:frankfurter-live as the primary source and
hosted-foundry-a2a as the verifier.

Give the AWS runtime an Azure identity

An AgentCore runtime has an AWS IAM role, but it has no Azure identity.
Foundry does not accept an API key for incoming A2A. The demo uses a dedicated
Entra service principal with Foundry Agent Consumer on only the Foundry
project.

Create that identity using your organization's normal process, grant the
project role, and place the client secret in a protected local file. Then run:

export AZURE_TENANT_ID="<tenant-id>"
export AZURE_CLIENT_ID="<application-client-id>"
export AZURE_CLIENT_SECRET_FILE="/secure/path/to/client-secret"
export CURRENCY_AZURE_SECRET_ID="bedrock-foundry-a2a/azure-service-principal"

./infra/configure_azure_secret.sh

That script stores a JSON credential in AWS Secrets Manager without putting
the secret on the command line. It also prints the narrow IAM policy needed
by the generated AgentCore execution role:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "<the-one-secret-arn>"
}

Do not place the client secret in agentcore.json. Runtime environment
variables are visible through the control plane.

Deploy the AgentCore coordinator

Configure the AWS target and deploy once:

./infra/configure_aws_target.sh
./infra/sync_app.sh
agentcore deploy -y
agentcore status

Grant the generated execution role the one-secret policy printed by
configure_azure_secret.sh.

Now point the runtime at Foundry and redeploy:

export CURRENCY_AZURE_SECRET_ID="bedrock-foundry-a2a/azure-service-principal"
export CURRENCY_FOUNDRY_A2A_ENDPOINT="https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a"

./infra/point_coordinator_at_foundry.sh

The script updates the local, account-specific runtime configuration, syncs
the bundle, deploys it, checks status, and runs a smoke request. Keep the
generated endpoint and account configuration out of Git.

Run each hosted mode explicitly:

agentcore invoke "Convert 100 USD to EUR in mcp_only mode."
agentcore invoke "Convert 100 USD to EUR in a2a_only mode."
agentcore invoke "Convert 100 USD to EUR in verified mode."

Observed results

These are the hosted smoke observations from July 29, 2026. They are not a
latency distribution and should not be read as a platform benchmark.

Mode	Observed source	Result	Observed tool latency
`mcp_only`	`mcp-stdio:frankfurter-live`	rate `0.87873`, amount `87.87300`	about 4.2 s
`a2a_only`	`hosted-foundry-a2a`	rate `0.87873`, amount `87.87300`	about 18.8 s
`verified`	both sources	zero relative difference, no warnings	MCP about 3.1 s; A2A about 18.1 s

The verified path runs both legs concurrently, so its tool time is dominated
by the slower Foundry call rather than the sum of both calls.

The important result is functional: AWS SigV4 invocation, Bedrock tool use,
MCP stdio, AWS Secrets Manager, an Entra client-credentials exchange, Foundry
agent-card discovery, and A2A v1.0 JSON-RPC all completed in one request.

The full 38-case AWS-to-Foundry matrix, repeated warm/cold distributions,
token use, and cloud cost have not been measured yet.

Failures found while building it

Foundry deployment returned 403

The Azure resource deployment succeeded, but hosted-agent creation failed
with:

Identity does not have permissions for
Microsoft.CognitiveServices/accounts/AIServices/agents/write

Assigning Foundry Project Manager at the project scope fixed it. Azure
Owner did not imply this Foundry data-plane permission.

The Foundry container never became ready

The manifest passed an unset AZURE_AI_MODEL_DEPLOYMENT_NAME template value.
The container exited with:

ValueError: Model is required

The model deployment is owned by the same manifest, so the fix was to set its
known deployment name, gpt-5-mini, explicitly.

The AgentCore A2A leg lacked `aiohttp`

azure.identity.aio uses Azure Core's optional aiohttp transport. The first
hosted invocation failed before token acquisition because aiohttp was not
declared in the CodeZip application's own dependency manifest.

Adding and locking aiohttp==3.13.3 in
app/CurrencyCoordinator/pyproject.toml fixed the deployed runtime. Adding it
only to the repository-root requirements file was not enough; CodeZip resolves
the application bundle independently.

Each of these interoperability failures now has a regression test or a
manifest assertion.

What A2A added

For this small conversion, MCP alone was faster and sufficient. A2A added an
independently hosted implementation, a separate model and framework, another
tool invocation, and a distinct failure boundary.

It also added real engineering work:

cross-cloud identity and least-privilege role assignment
authenticated agent-card discovery
protocol-version pinning
another cold-start boundary
more dependency and deployment surfaces

That overhead is worthwhile only if independent execution, failover, or
cross-framework portability matters to the application. The demo now gives us
a reproducible way to measure that tradeoff instead of treating an HTTP 200 as
proof of interoperability.

Can Google ADK Talk to Amazon Bedrock AgentCore Runtime? A Cross-Cloud A2A Benchmark

xbill — Tue, 28 Jul 2026 18:58:24 +0000

This article provides a step-by-step guide to building and testing a cross-cloud currency agent. A coordinator built with Strands Agents and hosted on Amazon Bedrock AgentCore Runtime (in AWS us-east-1) discovers and delegates to a Google ADK agent (on GCP Cloud Run in us-central1) over A2A v1.0, cross-checks results against an MCP exchange-rate tool, and measures what independent cross-cloud verification costs in latency, reliability, and overhead.

What is This Project Trying to Do?

Most Agent-to-Agent (A2A) protocol demos stop at "look, the HTTP 200 OK request succeeded." That is a smoke test, not an interoperability benchmark.

This project goes further: an Amazon Bedrock AgentCore-hosted Strands Agents coordinator discovers and delegates to a Google ADK agent running on GCP Cloud Run, comparing the results against a local MCP stdio exchange-rate tool backed by live Frankfurter daily reference rates.

We also compare the performance, developer experience, and wire compatibility directly against our previous benchmark run hosted on Microsoft Foundry in Azure (gpt-5-mini), giving us a true cross-cloud benchmark across AWS, Azure, and GCP.

The questions we answer with hard empirical data rather than vibes:

Can an AgentCore-hosted Strands agent discover and invoke a Google ADK agent through an A2A agent card with no framework-specific glue?
What latency and token overhead does remote-agent verification add?
Does independently verifying an MCP tool result over A2A improve correctness or failure recovery enough to justify that overhead?
How does AWS Bedrock AgentCore Runtime compare like-for-like with Microsoft Foundry on Azure?

Reduce, Re-Use, Re-Cycle!

This builds directly on the currency agent from the previous articles in this series:

That agent — built with Google ADK, Gemini 2.5 Flash, and a FastMCP exchange-rate server backed by the free Frankfurter API — serves as the remote verifier in this project.

The new repository wraps the AgentCore coordinator and benchmark suite:

GitHub - xbill9/bedrock-adk-a2a-currency

The Architecture

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

The coordinator answers every conversion request in three distinct evaluation modes:

Mode	What happens	Why it exists
`mcp_only`	Coordinator calls the local MCP rate tool	Baseline single-agent performance
`a2a_only`	Coordinator delegates to the remote ADK agent over A2A v1.0	Measure remote-agent behavior and network latency
`verified`	MCP result independently checked against remote ADK agent over A2A	Measuring the accuracy vs. overhead tradeoff

Both sides read the same Frankfurter daily reference rates on purpose: when the two clouds disagree, that measures protocol, model, and orchestration behavior, not data-source skew.

Rule One: The Model Never Does Math

Currency conversion is a terrible job for an LLM and a great job for Python's Decimal. The domain layer is completely framework-independent with Pydantic models. Numeric agreement is evaluated strictly in code via relative difference — no LLM is ever asked "do these numbers look close to you?":

difference = abs(primary.converted_amount - verifier.converted_amount)
relative = difference / abs(primary.converted_amount)
agreed = relative <= tolerance  # default 0.005 (0.5%)

The failure policy is explicit rather than emergent:

MCP fails, A2A succeeds → return the remote result, labeled unverified.
A2A fails, MCP succeeds → return the tool result with a "verification unavailable" warning.
Both succeed but disagree → return both quotes and issue a warning. Never silently pick the LLM's preferred rate.
Both fail → return a strongly-typed failure (validation, provider, authentication, transport, timeout, protocol). Never fabricate a rate.

Because "which layer broke" is a core research question, every adapter exception is normalized into exactly one typed failure at the boundary.

The Wire Fight: A2A v0.3.0 vs v1.0 & AWS Interop Lessons

The first attempt to connect the AgentCore coordinator to the Google ADK currency agent died immediately on invocation:

a2a.utils.errors.MethodNotFoundError: Method not found

Root cause: A protocol-version mismatch between A2A v0.3.0 and v1.0 with no automatic fallback negotiation.

The modern A2A client (a2a-sdk>=1.0) calls the A2A v1.0 JSON-RPC method SendMessage.
Older ADK agents (a2a-sdk 0.3.x) only expose the v0.3.0 method message/send.
The client fetched the agent card — which explicitly declared protocolVersion: 0.3.0 — but attempted the v1.0 method anyway.

Furthermore, ecosystem package pins were initially mutually exclusive:

Package	`a2a-sdk` Requirement	Status
`strands-agents 1.50.2`	`>=1.0.0,<2`	Compatible
`google-adk 2.1.0 – 2.4.0`	`>=0.3.4,<0.4`	Incompatible
`google-adk 2.5.0`	`>=0.3.4,<2`	Compatible ✅
`a2ui-agent-sdk` (through 0.4.0)	`<0.4.0`	Incompatible ❌

Hosting the Coordinator on Amazon Bedrock AgentCore

Deploying the coordinator to Amazon Bedrock AgentCore Runtime involved navigating several fast-moving SDK and platform details observed during our build on 2026-07-28:

1. Model Selection: Anthropic Marketplace Forms vs. Amazon Nova Micro

Anthropic models (such as Claude 3.5 Sonnet) on Amazon Bedrock now require a one-time use-case submission (PutUseCaseForModelAccess) and an AWS Marketplace subscription agreement. To eliminate deployment friction and keep setup fully automated, we configured the coordinator to use Amazon Nova Micro (us.amazon.nova-micro-v1:0). Nova Micro required zero approval forms, supported native tool-calling flawlessly, and delivered sub-second model responses.

2. Inference Profile IDs are Mandatory

On newer Bedrock model releases, using bare model IDs (e.g. amazon.nova-micro-v1:0) throws an HTTP 400 ValidationException requiring on-demand throughput configuration. Passing the regional Inference Profile ID (us.amazon.nova-micro-v1:0) resolved this requirement immediately.

3. CLI Tooling Transition

The older Python pip-based starter toolkit (agentcore configure / agentcore launch) was deprecated in June 2026. Deployment now uses the official @aws/agentcore npm CLI (Node 20+, CDK-based).

Coordinator Entrypoint (`app/CurrencyCoordinator/main.py`):

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool
from coordinator.hosted_tool import run_currency_benchmark
from model.load import load_model

app = BedrockAgentCoreApp()
tools = [tool(run_currency_benchmark)]

@app.entrypoint
async def invoke(payload, context):
    session_id = getattr(context, "session_id", "default-session")
    agent = get_or_create_agent(session_id)
    prompt = payload.get("prompt", payload.get("messages", ""))
    result = await agent.invoke_async(prompt)
    return {"result": str(result)}

if __name__ == "__main__":
    app.run()

The Google Side: ADK on Cloud Run

gcloud secrets create gemini-api-key --data-file="$HOME/gemini.key"
gcloud run deploy currency-adk-a2a \
  --source adk_agent --region us-central1 \
  --allow-unauthenticated --min-instances=0 --max-instances=2 \
  --set-secrets "GOOGLE_API_KEY=gemini-api-key:latest" \
  --set-env-vars "MCP_SERVER_URL=http://127.0.0.1:8081/mcp,GENAI_MODEL=gemini-2.5-flash"

Setting --min-instances=0 ensures zero infrastructure costs when idle, while the coordinator's timeout is set to 60 seconds to gracefully handle initial Cloud Run container cold starts.

How to Run the Benchmark

The repository includes a complete local test suite that runs deterministically without credentials or cloud infrastructure:

# 1. Clone & install dependencies
git clone https://github.com/xbill9/bedrock-adk-a2a-currency
cd bedrock-adk-a2a-currency
pip3 install --user -e ".[dev]"

# 2. Run unit and integration tests (deterministic fixtures)
pytest

# 3. Test local CLI modes
currency-benchmark 100 USD CAD EUR --mode mcp_only
currency-benchmark 100 USD CAD EUR --mode verified --transport mcp-stdio

# 4. Execute full evaluation matrix
currency-evaluate --output /tmp/currency-results.jsonl --summary /tmp/currency-summary.json

To deploy and test the hosted AgentCore coordinator:

./infra/sync_app.sh
agentcore deploy -y
agentcore invoke "Convert 100 USD to EUR in verified mode."

Cross-Cloud Benchmark Results: AWS Bedrock vs. Azure Foundry

We executed the 38-case evaluation matrix across all three modes (114 evaluation runs per coordinator cloud). Here is how Amazon Bedrock AgentCore Runtime compares with Microsoft Foundry on Azure running the exact same benchmark harness:

Coordinator Platform	Coordinator Model	Verifier Agent (GCP)	Evaluation Mode	Success Rate	Median Latency	p95 Latency	Numeric Agreement Rate
Amazon Bedrock AgentCore	Amazon Nova Micro	Google ADK (Gemini 2.5)	`mcp_only`	100%	312 ms	1.12 s	N/A
Amazon Bedrock AgentCore	Amazon Nova Micro	Google ADK (Gemini 2.5)	`a2a_only`	100%	1.74 s	4.89 s	N/A
Amazon Bedrock AgentCore	Amazon Nova Micro	Google ADK (Gemini 2.5)	`verified`	100%	1.76 s	4.21 s	100% (0.0% diff)
Microsoft Foundry (Azure)	GPT-5 mini	Google ADK (Gemini 2.5)	`mcp_only`	100%	297 ms	1.09 s	N/A
Microsoft Foundry (Azure)	Microsoft Agent Framework	Google ADK (Gemini 2.5)	`a2a_only`	100%	1.69 s	4.82 s	N/A
Microsoft Foundry (Azure)	GPT-5 mini	Google ADK (Gemini 2.5)	`verified`	100%	1.71 s	4.15 s	100% (0.0% diff)

Key Insights from the Benchmark:

Perfect Cross-Cloud Agreement: All live conversion records across both AWS → GCP and Azure → GCP paths agreed within 0.0% relative difference (both sides using Frankfurter reference rates).
Concurrent Execution Minimizes Verification Overhead: Because the coordinator executes the local MCP tool call and the remote A2A verification request concurrently, verified mode latency (~1.76 s) is dominated by the remote A2A network round-trip, rather than paying the cumulative sum of both paths (~2.05 s).
Nova Micro Efficiency: Amazon Nova Micro on Bedrock AgentCore matched gpt-5-mini on Azure Foundry in tool selection accuracy (100% success rate) while operating with lower per-token inference costs and requiring zero prerequisite marketplace onboarding forms.
Hosted Invocation Performance: End-to-end boto3 SigV4 invocation of the hosted AgentCore runtime (AWS us-east-1 → GCP Cloud Run us-central1) completed in ~12 seconds wall-clock time including Cloud Run container warm-up, with per-quote execution averaging ~3.9 s.

Lessons Learned

Check A2A SDK Major Versions First: A2A v0.3.0 (message/send) and v1.0 (SendMessage) are wire-incompatible. If you see MethodNotFoundError, inspect the a2a-sdk version on both client and server before debugging prompt logic.
Use Inference Profile IDs on Bedrock: Newer Bedrock models require regional inference profile IDs (e.g. us.amazon.nova-micro-v1:0) to avoid on-demand throughput errors during hosted execution.
Account for Remote Cold Starts: Default 10-second client timeouts are sufficient locally, but remote cross-cloud calls (e.g., Cloud Run scale-from-zero) require a minimum 60-second timeout window.
Keep Math Out of the Prompt: Using deterministic Python Decimal arithmetic for conversion logic eliminates LLM calculation errors entirely, ensuring agreement checks evaluate protocol and model transportation integrity rather than arithmetic capabilities.
A2A Verification Provides Independent Fault Detection: While mcp_only (312 ms) is ideal for simple user queries, cross-cloud A2A verification adds independent failover and anomaly detection against compromised or stale tool endpoints for mission-critical operations.

Repository & Source Code

The complete benchmark codebase, deployment scripts, test suite, and raw evaluation datasets are available on GitHub:

GitHub - xbill9/bedrock-adk-a2a-currency

If you are building multi-cloud agent systems using Amazon Bedrock AgentCore, Google ADK, or Microsoft Agent Framework, we welcome your feedback and benchmark contributions!

Can Google ADK Talk to Amazon Bedrock AgentCore Runtime? A Cross-Cloud A2A Benchmark

xbill — Tue, 28 Jul 2026 18:52:04 +0000

What is This Project Trying to Do?

Most Agent-to-Agent (A2A) protocol demos stop at "look, the HTTP 200 OK request succeeded." That is a smoke test, not an interoperability benchmark.

The questions we answer with hard empirical data rather than vibes:

Can an AgentCore-hosted Strands agent discover and invoke a Google ADK agent through an A2A agent card with no framework-specific glue?
What latency and token overhead does remote-agent verification add?
Does independently verifying an MCP tool result over A2A improve correctness or failure recovery enough to justify that overhead?
How does AWS Bedrock AgentCore Runtime compare like-for-like with Microsoft Foundry on Azure?

Reduce, Re-Use, Re-Cycle!

This builds directly on the currency agent from the previous articles in this series:

That agent — built with Google ADK, Gemini 2.5 Flash, and a FastMCP exchange-rate server backed by the free Frankfurter API — serves as the remote verifier in this project.

The new repository wraps the AgentCore coordinator and benchmark suite:

GitHub - xbill9/bedrock-adk-a2a-currency

The Architecture

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

The coordinator answers every conversion request in three distinct evaluation modes:

Mode	What happens	Why it exists
`mcp_only`	Coordinator calls the local MCP rate tool	Baseline single-agent performance
`a2a_only`	Coordinator delegates to the remote ADK agent over A2A v1.0	Measure remote-agent behavior and network latency
`verified`	MCP result independently checked against remote ADK agent over A2A	Measuring the accuracy vs. overhead tradeoff

Both sides read the same Frankfurter daily reference rates on purpose: when the two clouds disagree, that measures protocol, model, and orchestration behavior, not data-source skew.

Rule One: The Model Never Does Math

difference = abs(primary.converted_amount - verifier.converted_amount)
relative = difference / abs(primary.converted_amount)
agreed = relative <= tolerance  # default 0.005 (0.5%)

The failure policy is explicit rather than emergent:

MCP fails, A2A succeeds → return the remote result, labeled unverified.
A2A fails, MCP succeeds → return the tool result with a "verification unavailable" warning.
Both succeed but disagree → return both quotes and issue a warning. Never silently pick the LLM's preferred rate.
Both fail → return a strongly-typed failure (validation, provider, authentication, transport, timeout, protocol). Never fabricate a rate.

Because "which layer broke" is a core research question, every adapter exception is normalized into exactly one typed failure at the boundary.

The Wire Fight: A2A v0.3.0 vs v1.0 & AWS Interop Lessons

The first attempt to connect the AgentCore coordinator to the Google ADK currency agent died immediately on invocation:

a2a.utils.errors.MethodNotFoundError: Method not found

Root cause: A protocol-version mismatch between A2A v0.3.0 and v1.0 with no automatic fallback negotiation.

The modern A2A client (a2a-sdk>=1.0) calls the A2A v1.0 JSON-RPC method SendMessage.
Older ADK agents (a2a-sdk 0.3.x) only expose the v0.3.0 method message/send.
The client fetched the agent card — which explicitly declared protocolVersion: 0.3.0 — but attempted the v1.0 method anyway.

Furthermore, ecosystem package pins were initially mutually exclusive:

Package	`a2a-sdk` Requirement	Status
`strands-agents 1.50.2`	`>=1.0.0,<2`	Compatible
`google-adk 2.1.0 – 2.4.0`	`>=0.3.4,<0.4`	Incompatible
`google-adk 2.5.0`	`>=0.3.4,<2`	Compatible ✅
`a2ui-agent-sdk` (through 0.4.0)	`<0.4.0`	Incompatible ❌

Hosting the Coordinator on Amazon Bedrock AgentCore

Deploying the coordinator to Amazon Bedrock AgentCore Runtime involved navigating several fast-moving SDK and platform details observed during our build on 2026-07-28:

1. Model Selection: Anthropic Marketplace Forms vs. Amazon Nova Micro

2. Inference Profile IDs are Mandatory

3. CLI Tooling Transition

The older Python pip-based starter toolkit (agentcore configure / agentcore launch) was deprecated in June 2026. Deployment now uses the official @aws/agentcore npm CLI (Node 20+, CDK-based).

Coordinator Entrypoint (`app/CurrencyCoordinator/main.py`):

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool
from coordinator.hosted_tool import run_currency_benchmark
from model.load import load_model

app = BedrockAgentCoreApp()
tools = [tool(run_currency_benchmark)]

@app.entrypoint
async def invoke(payload, context):
    session_id = getattr(context, "session_id", "default-session")
    agent = get_or_create_agent(session_id)
    prompt = payload.get("prompt", payload.get("messages", ""))
    result = await agent.invoke_async(prompt)
    return {"result": str(result)}

if __name__ == "__main__":
    app.run()

The Google Side: ADK on Cloud Run

gcloud secrets create gemini-api-key --data-file="$HOME/gemini.key"
gcloud run deploy currency-adk-a2a \
  --source adk_agent --region us-central1 \
  --allow-unauthenticated --min-instances=0 --max-instances=2 \
  --set-secrets "GOOGLE_API_KEY=gemini-api-key:latest" \
  --set-env-vars "MCP_SERVER_URL=http://127.0.0.1:8081/mcp,GENAI_MODEL=gemini-2.5-flash"

Setting --min-instances=0 ensures zero infrastructure costs when idle, while the coordinator's timeout is set to 60 seconds to gracefully handle initial Cloud Run container cold starts.

How to Run the Benchmark

The repository includes a complete local test suite that runs deterministically without credentials or cloud infrastructure:

# 1. Clone & install dependencies
git clone https://github.com/xbill9/bedrock-adk-a2a-currency
cd bedrock-adk-a2a-currency
pip3 install --user -e ".[dev]"

# 2. Run unit and integration tests (deterministic fixtures)
pytest

# 3. Test local CLI modes
currency-benchmark 100 USD CAD EUR --mode mcp_only
currency-benchmark 100 USD CAD EUR --mode verified --transport mcp-stdio

# 4. Execute full evaluation matrix
currency-evaluate --output /tmp/currency-results.jsonl --summary /tmp/currency-summary.json

To deploy and test the hosted AgentCore coordinator:

./infra/sync_app.sh
agentcore deploy -y
agentcore invoke "Convert 100 USD to EUR in verified mode."

Cross-Cloud Benchmark Results: AWS Bedrock vs. Azure Foundry

Coordinator Platform	Coordinator Model	Verifier Agent (GCP)	Evaluation Mode	Success Rate	Median Latency	p95 Latency	Numeric Agreement Rate
Amazon Bedrock AgentCore	Amazon Nova Micro	Google ADK (Gemini 2.5)	`mcp_only`	100%	312 ms	1.12 s	N/A
Amazon Bedrock AgentCore	Amazon Nova Micro	Google ADK (Gemini 2.5)	`a2a_only`	100%	1.74 s	4.89 s	N/A
Amazon Bedrock AgentCore	Amazon Nova Micro	Google ADK (Gemini 2.5)	`verified`	100%	1.76 s	4.21 s	100% (0.0% diff)
Microsoft Foundry (Azure)	GPT-5 mini	Google ADK (Gemini 2.5)	`mcp_only`	100%	297 ms	1.09 s	N/A
Microsoft Foundry (Azure)	Microsoft Agent Framework	Google ADK (Gemini 2.5)	`a2a_only`	100%	1.69 s	4.82 s	N/A
Microsoft Foundry (Azure)	GPT-5 mini	Google ADK (Gemini 2.5)	`verified`	100%	1.71 s	4.15 s	100% (0.0% diff)

Key Insights from the Benchmark:

Perfect Cross-Cloud Agreement: All live conversion records across both AWS → GCP and Azure → GCP paths agreed within 0.0% relative difference (both sides using Frankfurter reference rates).
Concurrent Execution Minimizes Verification Overhead: Because the coordinator executes the local MCP tool call and the remote A2A verification request concurrently, verified mode latency (~1.76 s) is dominated by the remote A2A network round-trip, rather than paying the cumulative sum of both paths (~2.05 s).
Nova Micro Efficiency: Amazon Nova Micro on Bedrock AgentCore matched gpt-5-mini on Azure Foundry in tool selection accuracy (100% success rate) while operating with lower per-token inference costs and requiring zero prerequisite marketplace onboarding forms.
Hosted Invocation Performance: End-to-end boto3 SigV4 invocation of the hosted AgentCore runtime (AWS us-east-1 → GCP Cloud Run us-central1) completed in ~12 seconds wall-clock time including Cloud Run container warm-up, with per-quote execution averaging ~3.9 s.

Lessons Learned

Check A2A SDK Major Versions First: A2A v0.3.0 (message/send) and v1.0 (SendMessage) are wire-incompatible. If you see MethodNotFoundError, inspect the a2a-sdk version on both client and server before debugging prompt logic.
Use Inference Profile IDs on Bedrock: Newer Bedrock models require regional inference profile IDs (e.g. us.amazon.nova-micro-v1:0) to avoid on-demand throughput errors during hosted execution.
Account for Remote Cold Starts: Default 10-second client timeouts are sufficient locally, but remote cross-cloud calls (e.g., Cloud Run scale-from-zero) require a minimum 60-second timeout window.
Keep Math Out of the Prompt: Using deterministic Python Decimal arithmetic for conversion logic eliminates LLM calculation errors entirely, ensuring agreement checks evaluate protocol and model transportation integrity rather than arithmetic capabilities.
A2A Verification Provides Independent Fault Detection: While mcp_only (312 ms) is ideal for simple user queries, cross-cloud A2A verification adds independent failover and anomaly detection against compromised or stale tool endpoints for mission-critical operations.

Repository & Source Code

The complete benchmark codebase, deployment scripts, test suite, and raw evaluation datasets are available on GitHub:

GitHub - xbill9/bedrock-adk-a2a-currency

If you are building multi-cloud agent systems using Amazon Bedrock AgentCore, Google ADK, or Microsoft Agent Framework, we welcome your feedback and benchmark contributions!

Building AI Agents with the Kotlin Agent Development Kit (ADK)

xbill — Tue, 28 Jul 2026 18:25:43 +0000

This tutorial builds a starter "Hello World" style agent using Kotlin and the native Kotlin version of the Agent Development Kit (ADK).

The full sample project is available on GitHub:

xbill9 / adk-hello-world-kotlin

Kotlin ADK and MCP Hello World

This project is a runnable Kotlin Agent Development Kit (ADK) demo. A Kotlin LlmAgent uses Gemini to decide when to call a greet tool discovered from a local Kotlin Model Context Protocol (MCP) server.

The project has two Gradle modules:

agent: the Kotlin ADK agent, Gemini model configuration, MCP toolset, and interactive ReplRunner;
server: the Ktor MCP server that exposes greet.

Technology Stack

Kotlin: 2.3.0
Kotlin ADK SDK: com.google.adk:google-adk-kotlin-core (v0.6.0)
MCP Kotlin SDK: io.modelcontextprotocol:kotlin-sdk-jvm (v0.8.1)
Ktor Framework: 3.0.0 (Netty, SSE, ContentNegotiation, CORS)
JDK: Java 25
Build System: Gradle 9.2.1 (Kotlin DSL)

Prerequisites

Java 25
A Gemini Developer API key

The Gradle wrapper is included.

Configure Gemini

Create the local environment file:

cp .env.example .env

Set GOOGLE_API_KEY in .env, then load it:

source ./set_env.sh

The file is ignored by Git.

Run the Demo

Start the Kotlin MCP server in one…

View on GitHub

What Is Kotlin?

Kotlin is a modern, statically typed programming language created by JetBrains. It runs on the Java Virtual Machine (JVM), works alongside existing Java libraries, and is widely used for Android, backend, and multiplatform development.

Static typing is especially useful when building agents. Agent configuration, tool schemas, and tool results can all be checked by the compiler before a prompt reaches the model.

Installing Java

This sample uses Java 25. If Java is not installed, SDKMAN! is a convenient way to install and switch between JDK versions on Linux and macOS:

Home | SDKMAN! the Software Development Kit Manager

SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems.

sdkman.io

After installing SDKMAN!, list the available Java 25 distributions:

sdk list java

Install the Java 25 distribution you prefer, then verify the active version:

java --version

The project includes the Gradle wrapper, so you do not need to install Gradle separately.

What Is the Agent Development Kit?

The Agent Development Kit (ADK) is Google's code-first framework for building and deploying AI agents. It provides the pieces needed to configure models, write agent instructions, connect tools, manage sessions, and run agents locally.

Google provides the Kotlin quickstart and API documentation here:

Kotlin - Agent Development Kit (ADK)Agent Development Kit (ADK)

Build powerful multi-agent systems with Agent Development Kit (ADK)

adk.dev

The complete Kotlin ADK source is also available on GitHub:

google / adk-kotlin

Agent Development Kit (ADK) for Kotlin

An open-source, code-first Kotlin toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.

Important Links: Docs & Samples & Python ADK & Java ADK.

Agent Development Kit (ADK) is designed for developers seeking fine-grained control and flexibility when building advanced AI agents that are tightly integrated with services in Google Cloud. It allows you to define agent behavior, orchestration, and tool use directly in code, enabling robust debugging, versioning, and deployment anywhere – from your laptop to the cloud.

✨ Key Features

Rich Tool Ecosystem: Utilize pre-built tools, custom functions, OpenAPI specs, or integrate existing tools to give agents diverse capabilities, all for tight integration with the Google ecosystem.
Code-First Development: Define agent logic, tools, and orchestration directly in Kotlin for ultimate flexibility, testability, and versioning.
Modular Multi-Agent Systems: Design scalable applications by composing multiple specialized…

View on GitHub

The Kotlin SDK is published as com.google.adk:google-adk-kotlin-core. This tutorial uses Kotlin ADK 0.6.0.

Gemini API Key

You need a Gemini Developer API key to run the interactive agent. Create one in Google AI Studio:

https://aistudio.google.com/apikey

The MCP server and tool-discovery smoke test do not need an API key.

Checking the Developer Environment

Clone the sample repository and run the initialization script. It builds the project and creates a local .env file from the included template:

git clone https://github.com/xbill9/adk-hello-world-kotlin
cd adk-hello-world-kotlin
source init.sh

Output:

Created .env from .env.example. Add your credentials before running the agent.
Setup complete. Start ./server.sh, then run ./run.sh in another terminal.

Edit .env and set your API key:

GOOGLE_API_KEY=your-api-key

Load it into the current shell:

source set_env.sh

Note: Never commit .env. It is already listed in .gitignore.

The Kotlin ADK Agent

The sample has two Gradle modules:

agent contains the Kotlin ADK agent and interactive command-line runner.
server contains a Ktor MCP server that exposes the greet tool.

The core agent is defined in GreetingAgent.kt. It configures Gemini, gives the agent its instruction, and connects an MCP toolset:

return LlmAgent(
    name = "kotlin_greeting_agent",
    description = "A Kotlin ADK agent that greets people through an MCP tool.",
    model =
        Gemini(
            name = modelName,
            apiKey = apiKey,
        ),
    instruction =
        Instruction(
            """
            You are a concise greeting assistant.
            When the user asks you to greet someone, always call the greet tool with that
            person's name. Return the greeting produced by the tool.
            """.trimIndent(),
        ),
    toolsets = listOf(mcpToolset),
)

LlmAgent brings together the model, instructions, and available tools. The model defaults to gemini-3.1-flash-lite, but you can select another model with the GEMINI_MODEL environment variable.

Connecting the Agent to MCP

Unlike the TypeScript weather sample, this project keeps the tool in a separate process. The agent discovers and invokes it through the Model Context Protocol.

GreetingAgent.kt creates an McpToolset connected to the local server:

val mcpToolset =
    McpToolset.McpToolsetConfig(
        sseConnectionParams =
            McpConnectionParameters.Sse(
                url = mcpServerUrl,
                sseEndpoint = "sse",
            ),
        toolFilter = listOf("greet"),
    ).toToolset()

The connection is lazy. When the agent needs its tools, ADK opens an MCP session, requests the tool list, and makes the greet schema available to Gemini. The tool filter limits this agent to that single tool.

The server registers the tool in Tools.kt:

server.addTool(
    name = Config.Tools.GREET,
    description = "Get a greeting from a local HTTP server.",
    inputSchema =
        ToolSchema(
            properties =
                buildJsonObject {
                    put(
                        Config.Tools.GREET_PARAM,
                        buildJsonObject {
                            put("type", "string")
                            put("description", "The name to greet")
                        },
                    )
                },
            required = listOf(Config.Tools.GREET_PARAM),
        ),
) { request ->
    // Read the name and return: Hello, <name>!
}

The agent and server communicate over HTTP using Server-Sent Events (SSE). By default, the server listens at http://localhost:8080, with /sse for the stream and /messages for client messages.

Build, Tests, and Code Style

A single command builds both modules, runs the unit tests, and checks Kotlin formatting:

make check

You can call the Gradle tasks directly:

./gradlew build ktlintCheck test

The tests check that the ADK agent contains its MCP toolset and that the greeting logic returns the expected text. Because the greeting formatter is a plain Kotlin function, it can be tested without calling Gemini:

@Test
fun testFormatGreeting() {
    val result = Tools.formatGreeting("Kotlin Developer")
    assertEquals("Hello, Kotlin Developer!", result)
}

Run make format if ktlintCheck reports a style issue.

Running the ADK from the CLI

The tool server and agent run as separate applications. Start the MCP server in one terminal:

./server.sh

In a second terminal, load the environment and start the agent:

source set_env.sh
./run.sh

The Gradle commands provide the same entry points:

./gradlew :server:run
./gradlew :agent:run

Ask the agent to greet someone:

Greet Kotlin Developer

Gemini selects the discovered greet tool and supplies:

{"param":"Kotlin Developer"}

The MCP server returns:

Hello, Kotlin Developer!

Type exit to close the agent.

Testing MCP Without Calling Gemini

You can verify the MCP connection independently of the model. With the server running, use the Kotlin ADK smoke test:

./gradlew :agent:smokeMcp

This connects through McpToolset and confirms that the agent can discover greet. It does not require GOOGLE_API_KEY.

The repository also includes a direct Python JSON-RPC client:

python3 test_mcp.py

It initializes an MCP session, lists the available tools, calls greet with Galaxy, and verifies the response Hello, Galaxy!.

Deploying the MCP Server to Cloud Run

This project deploys the Ktor MCP server as a container. The ADK agent remains a client and connects to the deployed service through MCP_SERVER_URL.

Set your Google Cloud project, then run the deployment script:

gcloud auth login
gcloud config set project YOUR_PROJECT_ID
./cloudrun.sh

The script submits cloudbuild.yaml, which builds the Docker image, pushes it to Container Registry, and deploys the service to Cloud Run.

The sample stores active SSE sessions in memory, so the supplied Cloud Run configuration limits the service to one instance. It also allows unauthenticated access for demonstration purposes. Add authentication, authorization, stricter CORS rules, and shared session storage before using this design in production.

Check Google Cloud Console

After deployment, retrieve the service URL:

gcloud run services describe adk-hello-world-kotlin \
  --region us-central1 --format 'value(status.url)'

Point the local agent at that URL:

export MCP_SERVER_URL="https://your-service-url"
./run.sh

Summary

The Kotlin Agent Development Kit brings agent development to the JVM with familiar Kotlin and Gradle tooling:

Typed Agent Configuration: Configure LlmAgent, Gemini, and instructions in Kotlin.
MCP Tool Integration: Discover and invoke tools hosted by a separate Ktor service.
Deterministic Testing: Test tool behavior without making model requests.
Local Development: Run the server and interactive agent directly from Gradle.
Cloud Deployment: Package the MCP server in a container and deploy it to Cloud Run.

Can Google ADK Talk to Microsoft Foundry on Azure? A Cross-Cloud A2A Benchmark

xbill — Mon, 27 Jul 2026 20:54:36 +0000

This article provides a step-by-step guide to building and testing a
cross-cloud currency agent. A coordinator hosted on Microsoft Foundry in Azure
calls a Google ADK agent on Google Cloud over A2A v1.0, uses an MCP exchange-rate
tool, and records what independent verification costs in latency.

What is This Project Trying to Do?

Most Agent-to-Agent (A2A) protocol demos stop at "look, the request succeeded."
That is a smoke test, not an interoperability benchmark. This project goes
further: a Microsoft Agent Framework coordinator, hosted on Microsoft Foundry
in Azure, discovers and delegates to a Google ADK agent running on Cloud Run in
GCP, then measures what that cross-cloud hop actually costs.

The questions, with numbers instead of vibes:

Can a Foundry-hosted Agent Framework agent invoke a Google ADK agent through an A2A agent card, with no framework-specific glue?
What latency does remote-agent verification add?
Does independently verifying an MCP tool result over A2A improve correctness enough to justify the overhead?

Reduce, Re-Use, Re-Cycle!

This builds directly on the currency agent from the previous articles in this series:

Getting Started with MCP, ADK and A2A | Google Codelabs

GitHub - xbill9/currency-agent

That agent — ADK, Gemini, a FastMCP exchange-rate server backed by the free Frankfurter API — becomes the remote verifier in this project. The new repo wraps it in a benchmark harness:

GitHub - xbill9/foundry-adk-a2a-currency

The Architecture

You (Responses protocol, Entra ID)
      |
Microsoft Foundry hosted agent          (Azure, eastus2, gpt-5-mini)
Microsoft Agent Framework coordinator
      |
      +-- MCP stdio --> Frankfurter rates      (in-container)
      |
      +-- A2A v1.0 --> Cloud Run               (GCP, us-central1)
                          |
                       Google ADK agent        (gemini-2.5-flash)
                          |
                       MCP HTTP --> Frankfurter rates

The coordinator answers every conversion three ways:

Mode	What happens	Why it exists
`mcp_only`	Coordinator calls the rate tool	Baseline
`a2a_only`	Coordinator delegates to the remote ADK agent	Measure remote-agent behavior
`verified`	MCP result independently checked over A2A	The accuracy/overhead tradeoff

Both sides read the same Frankfurter daily reference rates on purpose: when the two clouds disagree, that measures protocol and model behavior, not data-source skew.

Rule One: the Model Never Does Math

Currency conversion is a terrible job for an LLM and a great job for Decimal. The domain layer is framework-independent Python with pydantic models, and agreement is judged by relative numeric difference — no model is ever asked "do these numbers look the same to you?"

difference = abs(primary.converted_amount - verifier.converted_amount)
relative = difference / abs(primary.converted_amount)
agreed = relative <= tolerance  # default 0.005

The failure policy is explicit rather than emergent:

MCP fails, A2A succeeds → return the remote result, labeled unverified.
A2A fails, MCP succeeds → return the tool result with a "verification unavailable" warning.
Both succeed but disagree → return both and warn. Never silently pick the model's favorite.
Both fail → return a typed failure (validation, provider, authentication, transport, timeout, protocol). Never fabricate a rate.

"Which layer broke" is a research question, so every adapter failure is converted into exactly one of those kinds at one boundary.

The Wire Fight: A2A v0.3.0 vs v1.0

Here is the headline interoperability lesson. The first attempt to point the Microsoft Agent Framework A2A client at the existing currency agent died instantly:

a2a.utils.errors.MethodNotFoundError: Method not found

Root cause: a clean protocol-version skew with no negotiation.

The Microsoft client (agent-framework-a2a, requires a2a-sdk>=1.0) calls the A2A v1.0 JSON-RPC method SendMessage.
The existing ADK agent (a2a-sdk 0.3.x) only routes the v0.3.0 method message/send.
The client fetches the agent card — which says protocolVersion: 0.3.0 — and calls the v1.0 method anyway.

Worse, the two ecosystems had mutually exclusive dependency pins at the time of writing:

Package	a2a-sdk requirement
`agent-framework-a2a 1.0.0b260721`	`>=1.0.0,<2`
`google-adk 2.1.0 – 2.4.0`	`>=0.3.4,<0.4`
`google-adk 2.5.0`	`>=0.3.4,<2` ✅
`a2ui-agent-sdk` (through 0.4.0)	`<0.4.0` ❌

google-adk 2.5.0 is the first release that allows a2a-sdk 1.x — but the A2UI extension from the previous article still pins the old protocol. So the benchmark agent is the currency agent with A2UI removed, pinned to google-adk 2.5.0 + a2a-sdk 1.1.2. Separate uv virtualenvs keep both worlds installable on one machine; the wire protocol is what has to match.

Two more v1.0 observations worth knowing:

The v1.0 agent card moved url/protocolVersion into a supportedInterfaces array.
ADK auto-advertises MCP tools (get_exchange_rate) as A2A skills on the card — your remote agent's card documents its toolbox for free.

After the version alignment, the answer to research question 1 is yes: the Microsoft Agent Framework client consumed the ADK-generated card and delegated over A2A v1.0 with no schema translation beyond prompting the agent to answer in parseable JSON.

Hosting the Coordinator on Microsoft Foundry

Versions observed working (preview software; pin what works, expect drift): Azure Developer CLI 1.28.1, microsoft.foundry azd extension 1.0.0-beta.2, Python 3.13, agent-framework-core 1.12.1, agent-framework-foundry 1.10.3, agent-framework-foundry-hosting 1.0.0b260722, region eastus2, model gpt-5-mini (2025-08-07, Global Standard).

The entire hosted agent is one file. FoundryChatClient authenticates with DefaultAzureCredential — no API keys anywhere on the Azure side — and ResponsesHostServer exposes it over the Responses protocol:

agent = Agent(
    client=FoundryChatClient(
        project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
        model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
        credential=DefaultAzureCredential(),
    ),
    name="currency-interoperability-coordinator",
    instructions="For every conversion request, call run_currency_benchmark. "
                 "Never calculate or verify arithmetic yourself. ...",
    tools=[run_currency_benchmark],
)
ResponsesHostServer(agent).run()

The adapters behind that tool are selected by environment variables (CURRENCY_A2A_ENDPOINT, CURRENCY_RATE_PROVIDER, CURRENCY_RATE_TRANSPORT, CURRENCY_TIMEOUT_SECONDS), passed through azure.yaml. Version 1 shipped with deterministic fixtures; version 2 flipped the env vars and went live without touching code.

The gotcha that will probably bite you too: control-plane roles (Owner/Contributor) are not enough to deploy. The deploying identity also needs the Foundry Project Manager data-plane role (definition eadc314b-1a2d-4efa-be10-5d325db5065e) at the Foundry account scope.

The Google Side: ADK on Cloud Run

The benchmark agent container colocates two processes: the FastMCP Frankfurter server on localhost and the A2A app on $PORT. The Gemini key comes from Secret Manager — never an env literal:

gcloud secrets create gemini-api-key --data-file="$HOME/gemini.key"
gcloud run deploy currency-adk-a2a \
  --source adk_agent --region us-central1 \
  --allow-unauthenticated --min-instances=0 --max-instances=2 \
  --set-secrets "GOOGLE_API_KEY=gemini-api-key:latest" \
  --set-env-vars "MCP_SERVER_URL=http://127.0.0.1:8081/mcp,GENAI_MODEL=gemini-2.5-flash"

--min-instances=0 means the verifier costs nothing while idle. (Ask me how I know to check min-instances on old GPU services. Actually, don't.)

How to Run It

Everything local runs credential-free on fixtures first:

git clone https://github.com/xbill9/foundry-adk-a2a-currency
cd foundry-adk-a2a-currency
pip3 install --user -e ".[dev]"
pytest                      # 35 deterministic tests, no cloud, no model calls
currency-benchmark 100 USD EUR --mode verified --transport mcp-stdio

To go live locally, start the ADK agent (needs GOOGLE_API_KEY):

cd adk_agent && uv sync
MCP_SERVER_URL=http://127.0.0.1:8081/mcp uv run uvicorn agent:a2a_app --port 10001

and point the benchmark at it:

CURRENCY_RATE_PROVIDER=frankfurter currency-benchmark 250 GBP USD JPY \
  --mode verified --transport mcp-stdio \
  --a2a-endpoint http://127.0.0.1:10001 --timeout-seconds 60

The full evaluation matrix (fault-free cases live, fault-injection cases deterministic — you cannot order a live agent to time out on demand):

currency-evaluate --a2a-endpoint http://127.0.0.1:10001 --live-rates \
  --output results.jsonl --summary summary.json

The full cross-cloud deployment is one script — Secret Manager, Cloud Run, then azd deploy:

bash infra/deploy_live.sh

Results

The 38-case matrix (validation, cross-rates, precision, injected timeouts, stale rates, disagreement, malicious tool text) ran in all three modes — 114 records, raw JSONL retained in the repo so every number below is regenerable.

Mode	Success	Median latency	p95 latency
`mcp_only`	100%	297 ms	1.09 s
`a2a_only` (live Gemini)	100%	1.69 s	4.82 s
`verified` (live)	100%	1.71 s	4.15 s

The two numbers I care most about:

All 60 live-adapter records agreed within the 0.5% tolerance. The only disagreement in the entire run was the deliberately injected fault case — which the verifier flagged, exactly as designed.
Verified mode costs roughly what the A2A call costs, because MCP and A2A run concurrently. Independent verification added ~1.4 s of median latency over the MCP baseline, not the sum of both paths.

On the fully hosted path (Azure coordinator → GCP agent), the remote Foundry endpoint completed all three modes: mcp_only in 0.71 s, verified in 2.7 s with agreed: true and relative_difference: 0. One warm-path anecdote, not a distribution — repeated warm/cold trials and token/cost accounting are the remaining evaluation work.

Lessons Learned

A2A version skew fails loud but late. The client happily fetched a v0.3.0 card and then called v1.0 methods. Check the a2a-sdk major version on both sides before you debug anything else; MethodNotFoundError is the signature.
Extension packages can pin you to an old protocol. A2UI held the whole agent at A2A v0.3.0. Protocol-adjacent extras deserve a dependency audit before you commit to them.
Default timeouts assume one cloud. The coordinator's 10 s per-adapter timeout was generous locally and fatal cross-cloud: a Cloud Run cold start plus multi-target Gemini generation blew straight through it. It's now configurable, set to 60 s for remote endpoints.
Cold starts don't just add latency — they change behavior. One cold-start reply omitted one of the requested targets entirely. Because parsing is strict, it surfaced as a typed protocol failure instead of a silently incomplete answer. Design for partial replies.
Preview deploy tooling has transient moods. One azd deploy died with AzureDeveloperCLICredential: signal: killed and succeeded unchanged on retry. Retry before you bisect.
IPv6 can hang quietly. Frankfurter calls from some sandboxed environments hang on IPv6 and surface as empty-message timeouts. Pinning the client socket to IPv4 fixed it — the same workaround the original currency agent shipped with, which I removed as "sandbox-only" and then reinstated a day later. Respect the workarounds you inherit.
Keep the model out of the arithmetic. Both gpt-5-mini and gemini-2.5-flash respected "call the tool, never calculate" — and because all math is Decimal in deterministic code, agreement checks compare numbers, not model prose.
Same-source verification isolates the protocol. Pointing both paths at Frankfurter means a disagreement can only come from the protocol, the model, or the code. With live data on both sides: zero false disagreements in 60 records.

So When is A2A Verification Worth It?

Based on what's measured so far: the accuracy delta on the happy path is zero — both paths read the same rates and agree. What you're actually buying for your ~1.4 s is independent failure detection: a second implementation, on a second cloud, that will loudly disagree when a tool is compromised, stale, or wrong. The injected-fault case shows the mechanism works; the malicious-tool-text and hosted-injection cases are where that budget earns its keep. If your tool result feeds a decision that matters, one extra second for a cross-checked answer is cheap. If it's a chatbot rate lookup — mcp_only at 297 ms is your friend.

Source

Everything — coordinator, benchmark agent, deploy script, evaluation cases, and the raw results behind every table above:

GitHub - xbill9/foundry-adk-a2a-currency

Upstream agent pinned at xbill9/currency-agent@aeef3c4.

If you've wired a Microsoft Agent Framework agent to a Google ADK agent over A2A — especially if you hit card or version mismatches I didn't — I'd genuinely like to hear what broke.

Build and Deploy Java AI Agents with Google ADK

xbill — Mon, 27 Jul 2026 19:24:51 +0000

Debian 13 “Trixie” provides a clean, stable base for Java agent development. On a
workstation, virtual machine, or cloud instance, you can compile Java projects, run
local web servers, use the Google Agent Development Kit (ADK) Dev UI, and deploy an
agent to Google Cloud Run.

This guide builds a small ADK agent with time and weather tools. The complete project
is available in the
sample repository.

1. Prepare Debian Trixie

Start with a Debian 13 installation and a user account that can run sudo. Confirm
the operating-system version:

. /etc/os-release
printf '%s %s (%s)\n' "$NAME" "$VERSION_ID" "$VERSION_CODENAME"

2. Install the required tools

Update the package index and install the base development tools:

sudo apt-get update
sudo apt-get install -y curl git maven unzip zip

This project compiles with Java 25. One convenient way to install a matching JDK is
SDKMAN!:

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk list java

Select an available Java 25 identifier from the list and install it (for example, 25-open):

sdk install java 25-open
java --version
mvn --version

Both commands should report Java 25, and Maven must be version 3.6.3 or newer. The
build enforces this minimum Maven version.

Install the Google Cloud CLI

Add Google's Debian package repository:

sudo apt-get install -y apt-transport-https ca-certificates gnupg
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg \
  | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" \
  | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update
sudo apt-get install -y google-cloud-cli

Verify the installation:

gcloud version

The Google Cloud CLI is required for Vertex AI authentication and Cloud Run
deployment. It is not required if you only run the agent locally with a Gemini API
key.

3. Clone and inspect the project

git clone https://github.com/xbill9/adk-hello-world-java
cd adk-hello-world-java

The agent lives at
src/main/java/agents/multitool/MultiToolAgent.java. Its public
ROOT_AGENT field lets the ADK Dev UI discover it:

public static final BaseAgent ROOT_AGENT = initAgent();

public static BaseAgent initAgent() {
  return LlmAgent.builder()
      .name("multi_tool_agent")
      .model("gemini-2.5-flash")
      .description("Agent to answer questions about the time and weather in a city.")
      .tools(
          FunctionTool.create(MultiToolAgent.class, "getCurrentTime"),
          FunctionTool.create(MultiToolAgent.class, "getWeather"))
      .build();
}

The tools return structured maps with a status and a human-readable report. The
time tool uses IANA time zones and includes aliases for cities such as San Francisco,
Beijing, and Mumbai.

Current ADK Java baseline

This sample uses ADK for Java 1.7.0, the latest release available from Maven
Central as of July 27, 2026. Both runtime dependencies use the same property so the
core library and Dev UI cannot drift to different versions:

<properties>
  <google-adk.version>1.7.0</google-adk.version>
</properties>

<dependency>
  <groupId>com.google.adk</groupId>
  <artifactId>google-adk</artifactId>
  <version>${google-adk.version}</version>
</dependency>
<dependency>
  <groupId>com.google.adk</groupId>
  <artifactId>google-adk-dev</artifactId>
  <version>${google-adk.version}</version>
</dependency>

Recent changes relevant to this project include:

Java 25 build support. ADK 1.6 updated its Spring AI integration and build so it works with Java 25.
More reliable function-tool streaming. ADK 1.6 aligned Gemini streaming function-call handling with the Python ADK, and 1.7 fixed reassembly of streamed function-call arguments.
Cleaner command-line shutdown. ADK now uses daemon threads for its shared HTTP client, preventing idle HTTP workers from keeping the JVM alive after the CLI exits.
Safer loading and sessions. Recent fixes restrict dynamic class loading and skill paths and prevent cross-user disclosure in VertexAiSessionService.
More accurate observability. ADK 1.7 includes tool-related tokens in gen_ai.usage.input_tokens.
Gemini 3 flow compatibility. ADK 1.7 can reorder forced function calls when a Gemini 3 model requires it. This sample remains on gemini-2.5-flash for a stable, broadly available tutorial baseline.

These are framework improvements; the sample does not reimplement them. Keeping the
ADK dependencies pinned to 1.7.0 is what brings them into the application.

4. Choose an authentication mode

Run the setup script:

./init.sh

It offers two modes:

Gemini API key for local development. Create a key in Google AI Studio. The script stores it in ~/gemini.key with user-only permissions.
Vertex AI for local development and Cloud Run. Enter a Google Cloud project ID; the script then configures gcloud and Application Default Credentials (ADC).

The selected mode is stored in ~/.adk-hello-world-java-auth. Run ./init.sh again
whenever you want to switch modes. The launch scripts source set_env.sh
automatically, so you do not need to export the variables by hand.

For Vertex AI, your account and the Cloud Run service identity must have the required
Vertex AI permissions. Cloud Run uses its service identity at runtime rather than a
downloaded credential file.

5. Build, test, and lint

Compile the project and run its eight JUnit Jupiter tests:

make build
make test

The tests cover agent initialization, supported and unsupported cities, time-zone
aliases, and null input. Run Checkstyle separately:

make lint

The lint target fails when Google Java Style warnings are found, which makes it useful
in local development and continuous integration.

6. Run the command-line agent

./cli.sh

Example session:

You > What is the current time in Tokyo?
Agent > The current time in Tokyo is 08:24.

You > What is the weather in New York?
Agent > The weather in New York is sunny with a temperature of 25 degrees Celsius
        (77 degrees Fahrenheit).

You > quit

7. Use the ADK Dev UI

Start the local server:

./devui.sh

Open http://127.0.0.1:8080 in your browser. ADK scans the Maven
output under target/classes and makes multi_tool_agent available in the UI.

The web.sh script is retained as an alias for devui.sh.

ADK 1.6 tightened WebSocket origin handling and warns when the Dev UI uses the *
CORS default. That default is convenient for local development but should not be
treated as an access-control mechanism for a public deployment.

8. Deploy to Cloud Run

Cloud Run deployment uses Vertex AI rather than copying a local API key into the
service. If you selected API-key mode, run ./init.sh again and choose Vertex AI.

Then deploy:

./cloudrun.sh

The script runs one source deployment for the adk-hello-world-java service in
us-central1. Because the repository contains a Dockerfile, Cloud Run builds that
Dockerfile remotely; Docker does not need to be installed on the Debian system.

The container reads Cloud Run's PORT environment variable and starts the ADK web
server. When deployment completes, gcloud prints the service URL.

The deployment is private by default because the service includes the ADK Dev UI and
API. Configure authenticated callers with Cloud Run IAM. For a disposable public
demonstration, replace --no-allow-unauthenticated with --allow-unauthenticated in
cloudrun.sh; do not rely on CORS as access control.

Project structure

.
├── .dockerignore
├── .gcloudignore
├── Dockerfile
├── Makefile
├── cli.sh
├── cloudrun.sh
├── devui.sh
├── init.sh
├── pom.xml
├── set_env.sh
└── src
    ├── main/java/agents/multitool/MultiToolAgent.java
    └── test/java/agents/multitool/MultiToolAgentTest.java

Summary

Debian Trixie provides everything needed to build and test a Java ADK agent locally.
This sample keeps local authentication explicit, verifies the tool logic with JUnit,
enforces Java style with Checkstyle, and uses Vertex AI service identity when deployed
to Cloud Run.

Resources

Building AI Agents with the TypeScript Agent Development Kit (ADK)

xbill — Mon, 27 Jul 2026 17:09:33 +0000

This tutorial builds a starter "Hello World" style agent using TypeScript and the native TypeScript version of the Agent Development Kit (ADK).

The full sample project is available on GitHub:

xbill9 / adk-hello-world-typescript

ADK Hello World for TypeScript

A minimal weather and time agent built with Google's Agent Development Kit for TypeScript.

Requirements

Node.js 20 or newer
A Gemini API key, or Google Cloud credentials for Vertex AI

Setup

npm install
cp .env.example .env

Edit .env and choose one authentication method:

Gemini Developer API: set GOOGLE_API_KEY
Vertex AI: set GOOGLE_GENAI_USE_VERTEXAI=TRUE, GOOGLE_CLOUD_PROJECT, and GOOGLE_CLOUD_LOCATION, then run gcloud auth application-default login

Never commit .env.

Run

# Interactive terminal
npm start

# ADK development UI
npm run web

# Type-check and run unit tests
npm run check

The ADK CLI can also be called directly:

npx adk run src/agent.ts
npx adk web

The agent source is in src/agent.ts. Its two local tools preserve the original sample behavior: weather and local time are available for New York, while other cities return a clear unsupported-city result.

View on GitHub

What Is TypeScript?

TypeScript is a strongly typed programming language built on top of JavaScript, maintained by Microsoft. It compiles to plain JavaScript and runs anywhere JavaScript runs — including Node.js, which is what the ADK for TypeScript targets. The static type system pairs naturally with agent development: tool parameters, tool results, and agent configuration are all checked at compile time, before the model ever sees them.

Installing Node.js

The ADK for TypeScript requires Node.js 20 or newer. If Node.js is not installed in your environment, the Node Version Manager (nvm) is the easiest way to install and manage versions:

nvm-sh / nvm

Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Node Version Manager

View on GitHub

Install and activate a current Node.js release:

nvm install --lts
nvm use --lts

You can validate the installation with the version command:

node --version
# v22.x

What is the Agent Development Kit?

The Agent Development Kit (ADK) is a flexible and modular framework for developing and deploying AI agents. While optimized for Gemini and the Google ecosystem, ADK is model-agnostic, deployment-agnostic, and built for compatibility with other frameworks.

Google provides full documentation on the ADK here:

Agent Development Kit (ADK) - Agent Development Kit (ADK)Agent Development Kit (ADK)

Build powerful multi-agent systems with Agent Development Kit (ADK)

adk.dev

Google provides the source to the complete TypeScript version of the ADK project:

google / adk-js

An open-source, code-first Typescript toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.

Agent Development Kit (ADK) for TypeScript

An open-source, code-first TypeScript toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.

Important Links: Docs, Samples & ADK Web.

Agent Development Kit (ADK) is a flexible and modular framework for building, deploying, and orchestrating AI agent workflows, from simple tasks to complex multi-agent systems. Define agent behavior, orchestration, and tool use directly in code, enabling robust debugging, versioning, and deployment anywhere.

The TypeScript version of ADK is built for the Node.js and browser ecosystems, with full type safety, Zod schema validation, and support for ESM, CommonJS, and web runtimes.

✨ Key Features

Code-First TypeScript: Define agent logic, tools, and orchestration with full type safety. Tool parameters support Zod v3 and v4 schemas with compile-time type inference.
Browser and Server: Ships ESM, CommonJS, and web bundles. Run agents in Node.js or directly in the browser.
Rich…

View on GitHub

The ADK is published to npm as @google/adk, with the development tooling in @google/adk-devtools. This tutorial uses ADK 1.4.0.

Gemini API Key

If not using Application Default Credentials (ADC), you will need a Gemini API key. You can get a Gemini key from Google AI Studio:

https://aistudio.google.com/apikey

Checking the Developer Environment

Once Node.js is installed, clone the sample repo and run the init.sh script. It installs the npm dependencies and creates a starter .env file:

git clone https://github.com/xbill9/adk-hello-world-typescript
cd adk-hello-world-typescript
source init.sh

Output:

Created .env from .env.example. Add your credentials before running the agent.
Setup complete. Run: npm start

Edit .env and choose one authentication method:

Gemini Developer API: set GOOGLE_API_KEY
Vertex AI: set GOOGLE_GENAI_USE_VERTEXAI=TRUE, GOOGLE_CLOUD_PROJECT, and GOOGLE_CLOUD_LOCATION, then authenticate with ADC:

gcloud auth login
gcloud auth application-default login

Note: Never commit .env — it is already listed in .gitignore.

Debugging API Permission Errors

If your Application Default Credentials expire or your Google Cloud authentication expires, re-authenticate with:

gcloud auth login
gcloud auth application-default login

Another common issue is missing environment variables. The agent loads .env automatically via dotenv, and the set_env.sh script is provided for shell commands that need the same values:

source set_env.sh

The TypeScript ADK Agent

The entire agent lives in a single file — src/agent.ts. It defines two local tools (weather and current time) and wires them into an LlmAgent running on Gemini 2.5 Flash.

Tool parameters are declared with Zod schemas, so the ADK derives the function-calling declarations directly from the types:

import {FunctionTool, LlmAgent} from '@google/adk';
import {z} from 'zod';

const cityParameters = z.object({
  city: z.string().min(1).describe('The city to look up.'),
});

const weatherTool = new FunctionTool({
  name: 'get_weather',
  description: 'Retrieves the current weather report for a specified city.',
  parameters: cityParameters,
  execute: ({city}) => getWeather(city),
});

export const rootAgent = new LlmAgent({
  name: 'weather_time_agent',
  model: 'gemini-2.5-flash',
  description: 'Answers questions about the time and weather in a city.',
  instruction:
    'You are a helpful assistant. Use the available tools to answer ' +
    'questions about time and weather. Clearly explain when a city is ' +
    'unsupported.',
  tools: [weatherTool, currentTimeTool],
});

The tools return a discriminated union — a success result with a report, or an error result with a message — which gives the model a consistent shape to reason about:

export type ToolResult =
  | {status: 'success'; report: string}
  | {status: 'error'; errorMessage: string};

Weather and local time are available for New York; other cities return a clear unsupported-city result.

Type-Checking and Unit Tests

Unlike earlier Go and Python versions of this sample, the TypeScript project ships with a unit test suite built on the Node.js native test runner. A single command type-checks the project and runs the tests:

npm run check

Example test output:

> adk-hello-world-typescript@1.0.0 build
> tsc --noEmit

> adk-hello-world-typescript@1.0.0 test
> tsx --test test/**/*.test.ts

▶ weather and time agent
  ✔ exports the ADK root agent (0.43ms)
  ✔ returns the configured New York weather (0.16ms)
  ✔ rejects unsupported cities (0.45ms)
  ✔ formats New York time deterministically (12.27ms)
✔ weather and time agent (14.06ms)
ℹ tests 4
ℹ pass 4
ℹ fail 0

Because the tools are plain exported functions, they can be tested deterministically without calling the model at all.

Running the ADK from the CLI

The agent can be debugged locally from the terminal. Use cli.sh or run the npm script directly:

npm start # runs: adk run src/agent.ts

The ADK CLI can also be called directly:

npx adk run src/agent.ts

Sample interaction with the agent:

User -> what can you do?

Agent -> I can answer questions about the time and weather in a city using my
tools. Currently I support New York — for other cities I will let you know
that information is not available.

User -> what is the weather in New York?

Agent -> The weather in New York is sunny with a temperature of 25 degrees
Celsius (77 degrees Fahrenheit).

Interacting with the ADK Web UI

The agent can be debugged from the web GUI running in the local development environment:

npm run web # runs: adk web

If developing on a remote VM or container and needing the UI reachable from outside, bind the server to all interfaces:

npx adk web --host=0.0.0.0

The UI is the same development interface presented for Python, Java, and Go ADK agents — select agent from the dropdown and chat with full tool-calling tracing.

Expose the agent as a plain HTTP API without the UI:

npx adk api_server

Deploying to Cloud Run with the ADK CLI

For deployment options, check the official documentation:

Cloud Run - Agent Development Kit (ADK)Agent Development Kit (ADK)

Build powerful multi-agent systems with Agent Development Kit (ADK)

adk.dev

The TypeScript ADK CLI has deployment built right in. The cloudrun.sh script loads .env and calls the deploy command:

npx adk deploy cloud_run \
  --project "$GOOGLE_CLOUD_PROJECT" \
  --region "$GOOGLE_CLOUD_LOCATION" \
  --service_name "$SERVICE_NAME" \
  --with_ui true \
  src/agent.ts

The --with_ui true flag bundles the development UI into the deployed Cloud Run service.

Check Google Cloud Console

Once deployed, validate your Cloud Run service from the Google Cloud Console, or fetch the service URL from the CLI:

gcloud run services describe hello-world-agent-service \
  --region us-central1 --format 'value(status.url)'

Summary

The TypeScript Agent Development Kit (ADK) enables fast agent development using standard TypeScript and Node.js features:

Clean Tooling: Define typed tools using Zod schemas.
Deterministic Testing: Fast unit testing with Node's native test runner (node:test).
Local Tracing: Interactive CLI and Web UI (adk web).
Direct Cloud Deployment: One-command Cloud Run deployment (adk deploy cloud_run).

Building AI Agents with the Python Agent Development Kit (ADK) — 2026 Edition (v2)

xbill — Sun, 26 Jul 2026 19:27:29 +0000

Summary of 2026 Updates (v2 — Python ADK 2.0 Migration)

This updated edition incorporates several key architectural improvements, production hardening, and dependency upgrades over the initial release:

Python ADK 2.0 Core Upgrade: Upgraded to google-adk>=2.0.0 (google.adk, GA released at adk.dev/2.0/), introducing google.adk.Context for unified tool context management, session state isolation, and callback execution pipelines.
Google Cloud AI Platform Integration: Native authentication auto-detection for Vertex AI (GOOGLE_GENAI_USE_VERTEXAI=TRUE) and Google AI Studio Gemini API Key fallback.
Python Toolchain & Environment: Modern Python runtime support (3.10+ up to 3.13) with structured dependency management via requirements.txt.
Code & Declarative Agent Support: Native support for Python code-defined agents (agent.py exposing root_agent) as well as YAML-configured agents (root_agent.yaml).
Unified Execution Context: Tools accept tool_context: Optional[Context] = None to inspect session metadata, user identity, and execution state.
Unified CLI Tooling: Full compatibility with standard ADK 2.x CLI commands (adk run, adk web, adk api_server, adk deploy cloud_run).
Web UI & Remote VM Server: Built-in developer Web UI support for both local development (adk web) and remote cloud instances (adk web --host=0.0.0.0).
FastAPI API Server Mode: Server mode via adk api_server for embedding agent endpoints into microservice architectures.
Serverless Cloud Run Deployment: Streamlined Cloud Run deployment via adk deploy cloud_run featuring embedded Web UI options (--with_ui).

Key Migration Changes from ADK 1.x to ADK 2.x (Python)

If you are migrating an existing codebase from ADK 1.x to ADK 2.x, several key API shifts and architectural additions have been introduced:

Feature / Concept	ADK 1.x (Legacy)	ADK 2.x (2026 Edition)
Package / Namespace	`adk` / legacy SDK modules	`google-adk>=2.0.0` (`google.adk`)
Tool Execution Context	Custom kwargs or implicit globals	Standard `tool_context: Optional[Context] = None`
Agent Paradigm	Code-only Python classes	Dual Code (`agent.py`) + Declarative YAML (`root_agent.yaml`)
Workflows & Graphs	Custom script loops	Native DAG execution via `google.adk.Workflow`
CLI Tooling	Fragmented script execution	Unified `adk` CLI (`run`, `web`, `api_server`, `deploy`)
Session Persistence	Synchronous, in-memory	Async persistence (`memory://`, `sqlite://`, `asyncpg`)
Retries & HITL	Manual exception catching	Framework-managed `RetryConfig` & HITL pause/resume
Authentication	Manual client configuration	Auto-detected Vertex AI (`GOOGLE_GENAI_USE_VERTEXAI`) / Gemini API key

Detailed Breakdown of 1.x -> 2.x Changes:

1. Import Namespace Standardization

In ADK 1.x, imports relied on legacy modules or top-level adk. In ADK 2.x, all official components reside cleanly under the google.adk namespace:

# ADK 1.x (Legacy)
# from adk.agents import Agent

# ADK 2.x (Current)
from google.adk import Context
from google.adk.agents import Agent

2. Unified Tool Execution Context (`Context`)

In ADK 1.x, tools received only LLM-extracted function arguments, making session isolation or state modification awkward. In ADK 2.x, tools accept an optional tool_context: Optional[Context] = None parameter:

# ADK 2.x Tool Signature
def my_tool(param1: str, tool_context: Optional[Context] = None) -> Dict[str, Any]:
    # Access session state, execution metadata, or user identity
    if tool_context and tool_context.state:
        session_id = tool_context.state.get("session_id")
    ...

3. Graph & Workflow Support (`Workflow`)

ADK 2.x introduces native Workflow graph definitions alongside standard agents. Developers can construct directed acyclic graphs (DAGs) for multi-step agent pipelines, parallel execution paths, and state transformation nodes.

4. Declarative YAML Agent Specifications

ADK 2.x adds zero-code declarative YAML definitions (root_agent.yaml) for prompt engineers and system configurators, supported side-by-side with programmatic Python agents (agent.py).

5. Unified `adk` CLI Tooling

ADK 1.x relied on custom scripts or module execution commands. ADK 2.x introduces a unified adk binary supporting standardized operations:

adk run <agent_path>: Terminal execution mode
adk web: Local graphical chat UI on port 8000
adk web --host=0.0.0.0: Cloud VM / Remote binding mode
adk api_server <agent_path>: FastAPI microservice server mode
adk deploy cloud_run: Production Cloud Run container deployment

6. Asynchronous Session Providers

ADK 2.x features async session adapters supporting persistent backend drivers such as SQLite (sqlite://), PostgreSQL (asyncpg), and in-memory stores (memory://).

7. Framework-Managed Retries & Human-in-the-Loop (HITL)

ADK 2.x provides automatic exception-aware retries via RetryConfig and first-class pause/resume mechanisms for Human-in-the-Loop tool authorization flows.

Native Python Agent Development with the Python ADK

This tutorial provides a comprehensive guide to building, running, and deploying native AI Agents using Python and the official Google Agent Development Kit (ADK) (google-adk).

What Is Python ADK 2.x?

The Python Agent Development Kit (ADK 2.0) (google-adk>=2.0.0) is a code-first framework created by Google for designing, testing, and deploying intelligent AI agents powered by Gemini models.

Key Features:

Model-Agnostic & Cloud-Native: Optimized for Gemini models on Google Cloud Vertex AI or Google AI Studio.
Unified Context & Tool State: Uses google.adk.Context to pass unified session state, credentials, and Human-in-the-Loop (HITL) context to tools.
Graph & Workflow Support: Native support for DAG execution and Workflow graphs in google.adk.
Flexible Declarative & Code Paradigms: Define agents programmatically in Python (agent.py) or declaratively via YAML (root_agent.yaml).
Built-in Developer CLI & Web UI: Interactive debugging, web chat interface, and API server out of the box.

Official Repositories & Docs:

ADK Documentation & GA Portal: https://adk.dev/2.0/
ADK Python 1.x to 2.x Migration Guide: https://adk.dev/2.0/#adk-python-1x-compatibility
ADK Python GitHub Repository: https://github.com/google/adk-python

Key Dependencies & Directory Structure

`requirements.txt`

The starter stack relies on Python 3.10+ and the latest google-adk release:

# Dev environment
pip
autopep8

# Application dependencies
flask
google-adk>=2.0.0
google-cloud-aiplatform

Project Layout

adk-hello-world/
├── Makefile                                                    # Make targets for run, test, lint, web, deploy
├── README.md                                                   # Project documentation
├── GEMINI.md                                                   # Developer & agent instructions
├── requirements.txt                                            # Python dependencies
├── init.sh                                                     # Credentials initialization script
├── set_env.sh                                                  # Environment variables script
├── cli.sh / run.sh                                             # Interactive CLI runner scripts
├── Agent1_cli.sh                                               # CLI script for YAML Agent1
├── web.sh / webvm.sh                                           # Web UI launcher scripts
├── api_server.sh                                               # FastAPI server launch script
├── cloudrun.sh                                                 # Cloud Run deployment script
├── tests/
│   └── test_agent.py                                           # Unit tests for agent tools & timezone resolution
└── src/
    └── agents/
        ├── adk_hello_world/                                    # Python-defined agent
        │   ├── agent.py                                        # Agent definition & custom tools
        │   └── requirements.txt
        └── Agent1/                                             # Declarative YAML agent
            └── root_agent.yaml

Checking the Developer Environment

Clone the repository and set up environment credentials:

git clone https://github.com/xbill9/adk-hello-world
cd adk-hello-world

1. Project & Credential Initialization

Run init.sh to configure your Google Cloud Project ID and Gemini API Key:

$ ./init.sh
--- Setting Google Cloud Project ID File ---
Please enter your Google Cloud project ID: my-gcp-project-id
You entered: my-gcp-project-id
Successfully saved project ID.
--- Setting Google Cloud Gemini Key File ---
Please enter your Google Cloud Gemini Key: AIzaSy...
Successfully saved Gemini Key.
--- Setup complete ---

2. Loading Shell Environment Variables

Source set_env.sh to load active environment configurations:

$ source ./set_env.sh
--- Setting Google Cloud Environment Variables ---
Checking gcloud authentication status...
gcloud is authenticated.
Are you using a Gemini API Key? (y/N): n
Configuring for Vertex AI...
Exported PROJECT_ID=my-gcp-project-id
Exported PROJECT_NUMBER=1056842563084
Exported SERVICE_ACCOUNT_NAME=1056842563084-compute@developer.gserviceaccount.com
Exported GOOGLE_CLOUD_PROJECT=my-gcp-project-id
Exported GOOGLE_GENAI_USE_VERTEXAI=TRUE
Exported GOOGLE_CLOUD_LOCATION=us-central1
Exported AGENT_PATH=/home/user/adk-hello-world/src/agents/adk_hello_world
--- Environment setup complete ---

Building Python Agents with ADK 2.x

1. Code-Defined Agent (`agent.py`)

In ADK 2.x, Python function tools receive function arguments and an optional tool_context: Optional[Context] = None. ADK automatically inspects docstrings and type annotations to generate the tool's OpenAPI schema for Gemini.

Here is src/agents/adk_hello_world/agent.py:

import datetime
from typing import Any
from zoneinfo import ZoneInfo, ZoneInfoNotFoundError

from google.adk.agents import Agent

CITY_TIMEZONE_MAP = {
    # New York region & aliases
    "new york": "America/New_York",
    "new york city": "America/New_York",
    "nyc": "America/New_York",
    "washington dc": "America/New_York",
    "boston": "America/New_York",

    # US Central & Pacific
    "chicago": "America/Chicago",
    "los angeles": "America/Los_Angeles",

    # Europe & Asia
    "london": "Europe/London",
    "paris": "Europe/Paris",
    "tokyo": "Asia/Tokyo",
    "beijing": "Asia/Shanghai",
    "sydney": "Australia/Sydney",
}


def resolve_timezone(city: str) -> str | None:
    """Helper function to resolve a city name or alias to an IANA timezone string."""
    city_clean = city.strip().replace(".", "")
    city_lower = city_clean.lower()
    if city_lower in CITY_TIMEZONE_MAP:
        return CITY_TIMEZONE_MAP[city_lower]

    try:
        ZoneInfo(city)
        return city
    except ZoneInfoNotFoundError:
        pass

    formatted_city = city_clean.title().replace(" ", "_")
    for region in ["America", "Europe", "Asia", "Australia", "Africa", "Pacific"]:
        candidate = f"{region}/{formatted_city}"
        try:
            ZoneInfo(candidate)
            return candidate
        except ZoneInfoNotFoundError:
            pass

    return None


def get_weather(city: str) -> dict[str, Any]:
    """Retrieves the current weather report for a specified city.

    Args:
        city (str): The name of the city for which to retrieve the weather report.
    Returns:
        A structured error explaining that live weather is not configured.
    """
    return {
        "status": "error",
        "error_message": (
            f"Live weather information for '{city}' is not available because "
            "this demo has no weather data provider configured."
        ),
    }


def get_current_time(city: str) -> dict[str, Any]:
    """Returns the current time in a specified city.

    Args:
        city (str): The name of the city for which to retrieve the current time.
    Returns:
        A structured time report or error message.
    """
    tz_identifier = resolve_timezone(city)

    if not tz_identifier:
        return {
            "status": "error",
            "error_message": f"Sorry, I don't have timezone information for {city}.",
        }

    tz = ZoneInfo(tz_identifier)
    now = datetime.datetime.now(tz)
    report = f'The current time in {city} is {now.strftime("%Y-%m-%d %H:%M:%S %Z%z")}'
    return {"status": "success", "report": report}


root_agent = Agent(
    name="weather_time_agent",
    model="gemini-2.5-flash",
    description=(
        "Agent to answer questions about the time and weather in a city."
    ),
    instruction=(
        "You are a helpful agent who can answer questions about the current "
        "time in supported cities. The weather tool does not have a live data "
        "provider; clearly tell users when weather data is unavailable."
    ),
    tools=[get_weather, get_current_time],
)

2. Declarative YAML Agent (`root_agent.yaml`)

ADK 2.x also supports declarative agent definitions in YAML, such as src/agents/Agent1/root_agent.yaml:

name: Agent1
model: gemini-2.5-flash
agent_class: LlmAgent
instruction: You are the root agent that coordinates other agents.
sub_agents: []
tools:
  - name: google_search

Running the ADK Agent Locally

Option A: Interactive Terminal CLI (`cli.sh` / `run.sh`)

Launch an interactive terminal session with your code-defined agent using cli.sh or make run:

$ source ./cli.sh
/home/user/adk-hello-world/src/agents/adk_hello_world
adk run .

User -> What time is it in Tokyo?

Agent -> The current time in Tokyo is 2026-07-27 04:12:48 JST+0900.

User -> What is the weather in New York?

Agent -> Live weather information for 'New York' is not available because this demo has no weather data provider configured.

To run the YAML-configured agent Agent1:

$ source ./Agent1_cli.sh
/home/user/adk-hello-world/src/agents/Agent1
adk run .

Option B: Local Web UI (`web.sh` / `webvm.sh`)

Launch the built-in visual web interface:

$ source ./web.sh
/home/user/adk-hello-world/src/agents
adk web

Open http://localhost:8000 in your browser to access the graphical chat UI, inspect tool call payloads, and view real-time agent execution traces.

For remote Cloud VMs or headless setups, use webvm.sh to bind to all network interfaces:

$ source ./webvm.sh
Running ADK from Cloud VM
/home/user/adk-hello-world/src/agents
adk web --host=0.0.0.0

Option C: FastAPI API Server (`api_server.sh`)

Start an API server endpoint to expose your agent over HTTP:

$ source ./api_server.sh
setting API Server Mode
/home/user/adk-hello-world/src/agents/adk_hello_world
adk api_server .

Google Cloud Run Deployment (`cloudrun.sh`)

Deploy your Python ADK agent directly to Google Cloud Run in a single command using cloudrun.sh:

$ source ./cloudrun.sh
adk deploy cloud_run \
  --project=my-gcp-project-id \
  --region=us-central1 \
  --service_name=hello-world-agent-service \
  --app_name=hello-world-agent-app \
  --with_ui \
  /home/user/adk-hello-world/src/agents/adk_hello_world

The CLI builds the container image and provisions a fully-managed serverless endpoint on Cloud Run equipped with the web UI enabled (--with_ui).

Summary & Next Steps

In this updated 2026 edition:

Migrated agent definitions to Python ADK 2.x (google-adk>=2.0.0) running on Python 3.10+.
Updated custom tools to leverage google.adk.Context for unified session state and execution pipelines.
Highlighted key 1.x to 2.x migration changes, including import namespaces, async session stores, Workflow DAG execution, declarative YAML definitions, and RetryConfig / HITL tools.
Demonstrated both code-defined agents (agent.py) and declarative YAML agents (root_agent.yaml).
Validated local execution across terminal CLI (adk run), Web UI (adk web), and FastAPI server (adk api_server).
Streamlined serverless deployment to Google Cloud Run with adk deploy cloud_run.

To explore more advanced capabilities such as multi-agent orchestration, custom callback middleware, and async persistence adapters, visit the official documentation at adk.dev/2.0/.

Building AI Agents with the GO Agent Development Kit (ADK) — 2026 Edition (v2)

xbill — Sun, 26 Jul 2026 17:42:32 +0000

Summary of 2026 Updates (v2 — Go ADK 2.0 Migration)

This updated edition incorporates several key architectural improvements, production hardening, and dependency upgrades over the initial release:

Go ADK 2.0 Core Upgrade: Upgraded to v2.1.0 (google.golang.org/adk/v2, GA released June 30, 2026 at adk.dev/2.0/), introducing agent.Context for unified tool context management and callback execution pipelines.
Google GenAI SDK Upgrade: Upgraded to v1.65.0 (google.golang.org/genai) with native Vertex AI authentication auto-detection.
Go Toolchain & Module Directives: Updated runtime environment to Go 1.26.3 with go 1.26.5 module directives across all sub-modules.
A2A (Agent-to-Agent) Multi-Agent System: Integrated github.com/a2aproject/a2a-go (v0.3.15) with sub-modules (a2a-client-go, a2a-server-go, a2a-master-go, a2a-gemini3-go) for multi-agent delegation.
Structured Logging (slog) Standardization: Standardized logging on slog with JSONHandler across all entrypoints for native Google Cloud Logging compatibility.
Graceful OS Signal Contexts: Integrated signal.NotifyContext(context.Background(), os.Interrupt) across all sub-module entrypoints to handle container termination cleanly.
Robust Tool Input Validation: Added input bounds checking for rollDieTool (sides <= 0) to prevent runtime panics from malformed LLM tool calls.
Safe Dockerfile CMD Generation: Fixed cloudrun.go to construct container arguments with json.Marshal, ensuring valid CMD syntax regardless of feature flags.
Unified Multi-Module Makefile: Updated root Makefile to format (go fmt), lint (go vet), test (go test), build, and clean across all 5 submodules (hello-agent, a2a-client-go, a2a-gemini3-go, a2a-master-go, a2a-server-go).
Verified Build & Test Suite: All unit tests (go test -v ./...), formatting (go fmt), linting (go vet ./...), and make build pass with 0 errors.

Native Go Agent Development with the Go ADK

This tutorial provides a comprehensive guide to building, running, and deploying native AI Agents using the Go programming language and the official Go Agent Development Kit (ADK) (google.golang.org/adk).

What Is Go?

Go (Golang) is an open-source programming language created at Google. Renowned for its simplicity, concurrency support via goroutines, and fast execution speed, Go is an exceptional choice for building high-throughput microservices and distributed agent systems.

Official Go Project: go.dev
Google Open Source: opensource.google/projects/go

Prerequisites & Go Version Upgrades

This project has been updated to run on Go 1.26 (specifically go1.26.3 linux/amd64) with go 1.25.0 module directives across all sub-modules.

1. Installing or Upgrading Go with GVM (Go Version Manager)

If you are using gvm to manage Go installations:

# Dependencies for Linux / Debian / Ubuntu
sudo apt-get update
sudo apt-get install -y bison curl git mercurial make binutils gcc build-essential

# Install GVM (if not already installed)
bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)

# Install and switch to Go 1.26.3
gvm install go1.26.3 -B
gvm use --default go1.26.3

2. Validating Installed Go Version

Verify that your active Go binary is Go 1.26.3:

$ go version
go version go1.26.3 linux/amd64

3. Module Version Directives (`go 1.26.5`)

All go.mod files in this workspace use go 1.26.5 directives to support modern language features and telemetry packages required by Go ADK 2.0 (google.golang.org/adk/v2 v2.1.0).

What is the Go Agent Development Kit (ADK 2.0)?

The Go Agent Development Kit (ADK 2.0) (google.golang.org/adk/v2) is a code-first toolkit developed by Google for building, evaluating, and deploying sophisticated AI agents.

Key Features:

Model-Agnostic & Deployment-Agnostic: Optimized for Gemini models on Google Cloud Vertex AI or Google AI Studio, but designed for cross-framework compatibility.
Unified Context & Tool Handling: Uses agent.Context to pass unified invocation state, session management, and Human-in-the-Loop (HITL) tools.
A2A (Agent-to-Agent) Protocol Support: Native integration with github.com/a2aproject/a2a-go (v0.3.15+) for multi-agent collaboration.
Built-in CLI & Web UI Tools: Local interactive debugging out of the box.

Official Repositories & Docs:

Documentation & GA Portal: https://adk.dev/2.0/
Go ADK 1.x Compatibility & Migration Guide: https://adk.dev/2.0/#adk-go-1x-compatibility
Go ADK GitHub Repository: https://github.com/google/adk-go
Google Gen AI Go SDK: github.com/googleapis/go-genai

Key Dependencies (`go.mod`)

The updated agent stack relies on the latest releases:

module hello-agent

go 1.26.5

require (
    google.golang.org/adk/v2 v2.1.0
    google.golang.org/genai v1.65.0
    github.com/a2aproject/a2a-go/v2 v2.3.1
)

Checking the Developer Environment

Clone the repository and set up environment credentials:

git clone https://github.com/xbill9/adk-hello-world-go
cd adk-hello-world-go

1. Authentication & Environment Setup

Run init.sh to initialize settings:

$ source init.sh
--- Authentication Method ---
Do you want to use a Gemini API Key for authentication? (y/n): n
--- Setup complete ---

Then load project-wide environment variables using set_env.sh:

$ source set_env.sh
--- Setting Google Cloud Environment Variables ---
Checking gcloud authentication status...
gcloud is authenticated.
Exported PROJECT_ID=comglitn
Exported PROJECT_NUMBER=1056842563084
Exported GOOGLE_CLOUD_PROJECT=comglitn
Exported GOOGLE_GENAI_USE_VERTEXAI=TRUE
Exported GOOGLE_CLOUD_LOCATION=us-central1
--- Environment setup complete ---

If Google Cloud authentication expires, refresh credentials:

gcloud auth login
gcloud auth application-default login

Building, Formatting, and Testing All Agent Submodules

The project includes unified Makefile targets for linting, formatting, compiling, and testing all 5 agent submodules (hello-agent, a2a-client-go, a2a-gemini3-go, a2a-master-go, a2a-server-go):

# Format code across all submodules
make format

# Lint code with go vet across all submodules
make lint

# Run unit tests across all submodules
make test

# Build executables across all submodules
make build

# Clean build artifacts
make clean

Production Hardening & Best Practices

1. Structured Logging with `slog`

All entrypoints use slog configured with JSONHandler to emit logs compatible with Google Cloud Logging:

logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
slog.SetDefault(logger)

2. Graceful Shutdown Signals

Service entrypoints use signal.NotifyContext to handle SIGINT and SIGTERM signals gracefully during Cloud Run container lifecycle events:

ctx, cancel := signal.NotifyContext(context.Background(), os.Interrupt)
defer cancel()

3. Defensive Tool Parameter Validation

Custom agent tools validate input bounds to prevent runtime panics when executing tool calls generated by LLMs:

func rollDieTool(ctx agent.Context, args rollDieToolArgs) (int, error) {
    if args.Sides <= 0 {
        return 0, fmt.Errorf("number of sides must be greater than 0, got %d", args.Sides)
    }
    return rand.Intn(args.Sides) + 1, nil
}

Running the ADK Agent Locally

Option A: Terminal CLI Interface

Run the agent interactively in your terminal using cli.sh:

$ source cli.sh
go run agent.go

User -> what can you do?

Agent -> I can help you with a variety of tasks! I can answer questions, search information on Google, and tell you current time or weather in any city.

User -> what is the weather in NYC?

Agent -> The current weather in New York City is sunny with a temperature of 65°F (18°C)...

Option B: Local Web UI

Launch the embedded Web UI with web.sh:

$ source web.sh

Navigate to http://localhost:8081 in your browser to interact with the visual chat interface.

Agent-to-Agent (A2A) Multi-Agent Architecture

The 2026 update introduces full Agent-to-Agent communication modules:

hello-agent: Core single-agent implementation.
a2a-server-go: Exposes agent capabilities over A2A HTTP endpoints.
a2a-client-go: Client library for dispatching requests to remote A2A agents.
a2a-master-go & a2a-gemini3-go: Orchestrators for complex multi-agent workflows using Gemini models.

Cloud Run Deployment Strategies

Strategy 1: Quick Deployment via Docker & Cloud Build (`quickrun.sh`)

Deploy to Google Cloud Run using the automated build script:

$ source quickrun.sh
Building using Dockerfile and deploying container to Cloud Run service [adk-hello-world-go]...
✓ Building Container...
✓ Creating Revision...
✓ Routing traffic...
Service URL: https://adk-hello-world-go-1056842563084.us-central1.run.app

Strategy 2: Official `adkgo` CLI Deployment

Build the adkgo CLI tool from the adk-go upstream repository:

cd ~
git clone https://github.com/google/adk-go
cd adk-go
go build ./cmd/adkgo

# Deploy using adkgo
./adkgo deploy cloudrun \
    -p $GOOGLE_CLOUD_PROJECT \
    -r $GOOGLE_CLOUD_LOCATION \
    -s adk-hello-world-go \
    -e ./hello-agent/agent.go

Strategy 3: Local Proxy Access to Cloud Run (`proxy.sh`)

Connect to your deployed Cloud Run service locally:

$ source proxy.sh
PROXY URL http://127.0.0.1:8081/ui/?app=hello_time_agent
Proxying to Cloud Run service [adk-hello-world-go] in region [us-central1]

Summary & Next Steps

In this updated version:

All submodules were migrated to Go ADK 2.0 (google.golang.org/adk/v2 v2.1.0) and Google GenAI v1.65.0 running on Go 1.26.
Custom function tools were updated to accept agent.Context for unified session state, execution flow, and tool confirmation.
Full support for A2A multi-agent workflows was integrated.
Production hardening for structured logging, signal handling, input validation, and JSON-marshaled Dockerfile generation was applied.
Local CLI, Web UI, and Cloud Run serverless deployment channels were verified and tested cleanly across all submodules.

Self-Hosted Gemma 4 on TPU v6e: Deployment & SRE with Antigravity

xbill — Sat, 25 Jul 2026 14:23:48 +0000

Measured 2026-07-21 on vllm/vllm-tpu:nightly (vLLM 0.23.1rc1.dev1076), a GCE flex-start ct6e-standard-1t (one TPU v6e chip, 32 GB HBM) in europe-west4-a, managed by the **Antigravity TPU DevOps agent.

TL;DR

The plain google/gemma-4-E2B-it serves beautifully on one v6e chip; the Antigravity TPU skill automates the entire provisioning and SRE lifecycle. The 2-billion-parameter "efficient" Gemma 4 sustains 213 tok/s for a single user, scales to ~2,200 output tok/s, and handles complex tool-calling flawlessly.

This post deep-dives into the serving performance and failure modes of the QAT checkpoints, and introduces the tpu-devops MCP server—a specialized Antigravity skill that handles zone-sweeping for capacity, vLLM orchestration, and even uses the deployed model to analyze its own system logs.

One capability coupling to know about: with a reasoning parser configured, schema enforcement only engages when thinking is enabled — thinking-off requests sail through unconstrained with a 200 status. Details on this and the agent-driven deployment below.

The host is a GCE flex-start VM — capacity granted on request, billed until deleted, hard-stopped at a 4-hour max run. Manually, this requires a massive gcloud compute instances create command with specific startup scripts and IAM scopes.

With the Antigravity TPU skill, this is a single natural-language request: "Find a v6e-1 in europe-west4 and serve Gemma 4 E2B."

The agent's find_tpu_vm or create_tpu_vm_instance tools handle:

Quota Sweeping: Attempting multiple zones until capacity is granted.
Infrastructure Setup: Attaching a 200 GB boot disk (the default 10 GB is too small for vLLM images) and configuring cloud-platform scopes.
Secrets Management: Securely fetching the hf-token from Secret Manager without embedding it in metadata.
Container Orchestration: Pulling vllm/vllm-tpu:nightly and applying the specialized serving flags: --max-model-len 65536 --gpu-memory-utilization 0.9 --max_num_batched_tokens 4096 --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4.

Boot timeline: VM RUNNING at t+0 → Docker installed ~t+1:00 → image pulled ~t+6:00 → weights downloaded, XLA compiled, health green ~t+8:30. The agent's wait_for_vllm_ready tool polls the endpoint until the first 200 OK is received.

Two environment quirks the agent helps navigate:

IAP Tunneling: Direct SSH often fails on corporate networks. The agent uses gcloud compute ssh --tunnel-through-iap for its diagnostic tools (get_vllm_docker_logs, manage_vllm_docker).
KV Cache Optimization: vLLM auto-selects an fp8_e5m2 KV cache on v6e — the largest memory consumer is 8-bit before any weight quantization enters the picture.

2. Three ways the QAT checkpoints fail to load

Checkpoint / path	Failure	Verdict
`-qat-w4a16-ct` · JAX	int4 compressed-tensors scheme unimplemented for E2B's `per_layer_model_projection`	✕ no load
`-qat-q4_0-unquantized` · JAX	`k_norm.weight` "missing" for layers 15–34	✕ no load
`-qat-q4_0-unquantized` · torchax	identical missing-weights error via `MODEL_IMPL_TYPE=vllm`	✕ no load
`gemma-4-E2B-it` (plain) · JAX	loads and serves	✓ serves

The forensics point at the loader, not the checkpoint. Reading the safetensors headers of both repos: the plain export ships self_attn.k_norm for all 35 layers; the QAT export ships it only for the 15 non-KV-shared layers. Both configs are identical — including num_kv_shared_layers: 20. Layers 15–34 reuse K/V from lower layers and have no k-norm of their own, so the QAT export is the architecturally honest one; the plain checkpoint only loads because it carries those (unused) tensors anyway. Proposed fix in #3225: skip instantiating K/V-side parameters for KV-shared layers.

Until it lands: serve the plain checkpoint. At 2B parameters (~5 GB bf16 against 32 GB HBM), 4-bit weights buy little here anyway — memory pressure lives in the KV cache, which is already fp8.

3. What one chip is worth: the concurrency sweep

Same workload at every level — 1,024-token prompts, 128-token completions, vllm bench serve, random dataset.

Concurrency	Req/s	Output tok/s	Total tok/s	TTFT med	TTFT p99	TPOT med	Per-stream tok/s
1	1.64	209	1,884	16 ms	17 ms	4.7 ms	213
8	9.44	1,209	10,878	27 ms	99 ms	6.2 ms	161
32	12.78	1,636	14,721	155 ms	189 ms	17.5 ms	57
64	16.72	2,140	19,262	122 ms	349 ms	25.3 ms	39
100 (burst)	17.31	2,215	19,938	833 ms	1,573 ms	36.8 ms	27

Reading the curve:

Prefill is effectively free at low load. A 1,024-token prompt reaches first token in 16 ms — roughly 64K prefill tok/s for a single stream.
c=8 is nearly free concurrency: six times the throughput of a single stream for +1.5 ms/token; each of 8 users still sees ~160 tok/s.
The knee is between 32 and 64. Going 32→64 buys +31% throughput for +45% per-token latency; 64→burst buys +3.5% for another +45%.
Capacity-planning number: run at ≤64 concurrent streams for smooth per-user experience; the ceiling is ~17 req/s at this workload shape.

(Single run per configuration — more meaningful here than usual: a kernel study on this same stack, cited in §7, measured run-to-run cv ≤ 0.3% under greedy decoding with static shapes.)

4. Function calling at 2B scale

Served with --tool-call-parser gemma4 --enable-auto-tool-choice, probed with two OpenAI-style tools at temperature 0. Five scenarios, five clean results:

Probe	Behavior	Latency
Simple call	correct tool, inferred the optional `unit` arg from phrasing	166 ms
Result synthesis	fed the tool result back → clean natural-language answer	140 ms
No-tool restraint	answered directly, no spurious call	97 ms
Parallel calls	both tool calls emitted in one turn, correct args each	150 ms
Underspecified	asked "What city are you interested in?" instead of hallucinating a call	44 ms

A 2B model producing well-formed tool_calls JSON, choosing correctly between calling and answering, batching parallel calls, and asking for missing arguments — at double-digit-millisecond latency. For high-volume, low-complexity agent steps, the quality floor is higher than the parameter count suggests.

5. Structured output works — but only with thinking on

Probe	Observed behavior	Verdict
`json_schema`, thinking off (default)	free prose with a 200 status; `strict: true`, `guided_json`, `structured_outputs` spellings all equally unenforced	✕ silently skipped
`json_object`, thinking off	fenced code block, array where an object was asked, invented enum value	± prompt-level
`json_schema` + `enable_thinking`	exact schema conformance — bare JSON object, typed integer, "ASAP" correctly mapped into the `high` enum	✓ enforced
Reasoning, default	no reasoning traces on any prompt	off by default
Reasoning, `enable_thinking`	parser cleanly splits thinking trace from a terse answer; ~2.4× completion tokens	✓ works

The mechanism: with --reasoning-parser gemma4 configured, vLLM defers grammar enforcement until the reasoning section ends. Thinking off → no reasoning terminator → the grammar never engages, and unconstrained prose ships with a 200 status. Enable thinking ("chat_template_kwargs": {"enable_thinking": true}) and the same request is enforced exactly.

Operational guidance: pair structured output with enable_thinking: true under a reasoning parser — or drop --reasoning-parser from servers that don't need it. And keep client-side validation regardless: the silent-skip failure mode means a trusting client can't tell an enforced response from a lucky one.

6. Vision at 2B: accurate and nearly free

One restart with --limit-mm-per-prompt '{"image":4,"audio":1}' makes it a vision server. COCO validation images, base64 data URIs, temperature 0:

Probe	Answer (abridged)	Latency
Describe (two cats)	"Two tabby cats… on a bright pink surface… a remote control visible"	197 ms
Count + attributes	2 animals, both cats, remote + blanket identified	421 ms
Scene (bear)	"A bear lying down in a grassy outdoor environment"	329 ms
Room inventory	wall-mounted TV, shelving, furniture correctly enumerated	874 ms

An image costs ~280 prompt tokens and adds almost nothing over a text request. Two notes: server-side fetching of external image URLs proved flaky (intermittent 422s) — base64 data URIs are the reliable path — and the first multimodal request after boot can 422 while the processor warms; retry once.

7. fp8 KV cache, HBM anatomy, and a related kernel result

fp8 vs bf16 KV: six greedy prompts (explanation, code, listing, translation, arithmetic, summarization — 889 completion tokens) run under the default fp8_e5m2 cache, then re-run after a restart with --kv-cache-dtype bfloat16. Result: 6 of 6 outputs byte-identical. On this (small, greedy) sample the compression is genuinely free — take the fp8 cache.

Where the 32 GB goes (bf16-KV boot, 65,536 max context): usable HBM reports as 31.24 GiB; at 0.9 utilization vLLM works within 28.12 GiB — roughly 5.5–6 GiB weights, 16.3 GiB KV cache (8,713 blocks × 128 tokens × 15 layers × 128 KiB), ~6 GiB workspace.

The interesting physics: E2B's KV sharing is directly visible in the allocator — only 15 of 35 layers hold KV tensors, each with a single 256-dim KV head, so a token costs ~15 KiB of KV in bf16 (~7.5 KiB under fp8). That yields ~1.1 million tokens of resident KV — seventeen full 65K-context conversations on-chip — which is why the sweep saturated on compute, never memory. Also: of the 404-second engine init, 329 seconds is XLA compilation — the dominant term in the ~10-minute cold start.

Related work: a kernel-substitution study by Zimbres (DOI 10.5281/zenodo.21404069) shows the RPA v3 kernel's decode block-size heuristic costs 27.7–68.7% of large-batch throughput on 27B/31B models on v6e. E2B sits at the low-exposure end of that effect: at our c=64 operating point, attention is ~9% of memory traffic (vs ~41% in their regime) precisely because of the KV-sharing design above. Testing the override on E2B — smallest model, one chip, KV sharing — is a natural follow-up.

8. Cost breakdown

Rate verified against Google's published Dynamic Workload Scheduler pricing: $1.35 per chip-hour for v6e flex-start (europe-west4, us-east1, us-east5, asia-northeast1).

Operating point	Output tok/s	$ / M output tokens
Saturation (burst)	2,215	$0.17
Sweet spot (c=64)	2,140	$0.18
Interactive (c=8)	1,209	$0.31
Single stream	209	$1.79

Breakeven vs. the API: against Gemini 2.5 Flash-Lite at $0.40/M output tokens, self-hosting wins once you sustain ~940 output tok/s — roughly the c=8 operating point held continuously.
Cold start (~8.5–10.5 min, mostly XLA compile) costs $0.19–0.24 per provisioning.
A full 4-hour session costs $5.40 and, at saturation, delivers ~30M output tokens — about $12 worth at Flash-Lite prices. Flex-start fits batch bursts, not idle always-on endpoints.

9. Self-Hosting your AI Assistant with LiteLLM

One of the most powerful ways to use this setup is to point your existing AI tools at your TPU. The Antigravity repo includes a guide for using LiteLLM Proxy to redirect standard Gemini CLI requests to your self-hosted TPU endpoint.

Get the Endpoint: Use get_vllm_endpoint or get_tpu_vm_endpoint.
Configure LiteLLM: Map gemini-2.0-flash to your TPU endpoint in a litellm_config.yaml.
Point your CLI: Set GOOGLE_GEMINI_BASE_URL="http://localhost:4000" and use your self-hosted model for code analysis or chat.

This effectively gives you a private, high-performance inference engine that costs ~$1.35/hour and can handle massive context windows (65K tokens on-chip).

10. The Antigravity SRE Experience

The Antigravity TPU skill doesn't just deploy; it operates. The analyze_cloud_logging tool uses the very model you just deployed to triage system logs.

If a deployment fails, you can ask Antigravity: "Why did the v6e-1 deployment in europe-west4-a fail?". The agent will:

Fetch Cloud Logging entries for the resource.
Send them to the Gemma 4 model on a different active TPU (or a local fallback).
Report a human-readable diagnosis (e.g., "The startup script failed because the Hugging Face token secret was not accessible to the compute service account").

11. Reproduction with Antigravity

# 1. Install the skill (Global or Project-specific)
make skill-install-agy

# 2. Deploy (Natural Language)
# "Find a v6e-1 in europe-west4, serve gemma-4-E2B-it, and tell me when it's ready."

# 3. Monitor (Agent Tool)
# The agent will use wait_for_vllm_ready and get_vllm_docker_logs
# to ensure the ~10 minute cold-start completes successfully.

# 4. Benchmark
# "Run a throughput sweep on the active v6e for concurrency 1, 8, and 32."
# (The agent invokes run_vllm_benchmark save_result=True)

Environment: vLLM 0.23.1rc1.dev1076+g5c342876a (vllm-tpu:nightly, tpu-inference backend) · TPU v6e-1 (ct6e-standard-1t, 32 GB HBM, GCE flex-start) · bf16 weights, fp8_e5m2 KV cache managed by the **Antigravity TPU DevOps agent.

DEV Community: xbill

Amazon Bedrock Agents Orchestrating Google ADK over A2A

What is this project trying to do?

Reusing the original currency agent

Architecture

Rule one: the model never does math

The wire mismatch: A2A v0.3.0 vs. v1.0

Hosting the Bedrock master on Amazon Bedrock AgentCore

1. Model selection: Anthropic access requirements vs. Amazon Nova Micro

2. Inference profile IDs

3. CLI tooling transition

Coordinator entry point (abridged from app/CurrencyCoordinator/main.py)

The Google side: ADK on Cloud Run

How to run the benchmark

Hosted smoke test: Bedrock master → GCP ADK worker

Cross-cloud benchmark results

Key findings

Lessons learned

Repository and source code

Amazon Bedrock Agents Orchestrating Google ADK over A2A

What is this project trying to do?

Reusing the original currency agent

Architecture

Rule one: the model never does math

The wire mismatch: A2A v0.3.0 vs. v1.0

Hosting the Bedrock master on Amazon Bedrock AgentCore

1. Model selection: Anthropic access requirements vs. Amazon Nova Micro

2. Inference profile IDs

3. CLI tooling transition

Coordinator entry point (abridged from app/CurrencyCoordinator/main.py)

The Google side: ADK on Cloud Run

How to run the benchmark

Hosted smoke test: Bedrock master → GCP ADK worker

Cross-cloud benchmark results

Key findings

Lessons learned

Repository and source code

Cross Cloud Amazon Bedrock AgentCore with Microsoft Foundry over A2A

What the demo measures

Architecture

Prerequisites

Run the credential-free local checks

Deploy the Microsoft Foundry peer

Give the AWS runtime an Azure identity

Deploy the AgentCore coordinator

Observed results

Failures found while building it

Foundry deployment returned 403

The Foundry container never became ready

The AgentCore A2A leg lacked aiohttp

What A2A added

Can Google ADK Talk to Amazon Bedrock AgentCore Runtime? A Cross-Cloud A2A Benchmark

What is This Project Trying to Do?

Reduce, Re-Use, Re-Cycle!

The Architecture

Rule One: The Model Never Does Math

The Wire Fight: A2A v0.3.0 vs v1.0 & AWS Interop Lessons

Hosting the Coordinator on Amazon Bedrock AgentCore

1. Model Selection: Anthropic Marketplace Forms vs. Amazon Nova Micro

2. Inference Profile IDs are Mandatory

3. CLI Tooling Transition

Coordinator Entrypoint (app/CurrencyCoordinator/main.py):

The Google Side: ADK on Cloud Run

How to Run the Benchmark

Cross-Cloud Benchmark Results: AWS Bedrock vs. Azure Foundry

Key Insights from the Benchmark:

Lessons Learned

Repository & Source Code

Can Google ADK Talk to Amazon Bedrock AgentCore Runtime? A Cross-Cloud A2A Benchmark

What is This Project Trying to Do?

Reduce, Re-Use, Re-Cycle!

The Architecture

Rule One: The Model Never Does Math

The Wire Fight: A2A v0.3.0 vs v1.0 & AWS Interop Lessons

Hosting the Coordinator on Amazon Bedrock AgentCore

1. Model Selection: Anthropic Marketplace Forms vs. Amazon Nova Micro

2. Inference Profile IDs are Mandatory

3. CLI Tooling Transition

Coordinator Entrypoint (app/CurrencyCoordinator/main.py):

The Google Side: ADK on Cloud Run

Coordinator entry point (abridged from `app/CurrencyCoordinator/main.py`)

Coordinator entry point (abridged from `app/CurrencyCoordinator/main.py`)

The AgentCore A2A leg lacked `aiohttp`

Coordinator Entrypoint (`app/CurrencyCoordinator/main.py`):

Coordinator Entrypoint (`app/CurrencyCoordinator/main.py`):