Google Cloud has published its Agent Development Kit (ADK) for five languages: Python, Go, TypeScript, Java and Kotlin. Each version follows the runtime and type system of its language, but they share one architecture and speak the same open protocols, MCP and A2A. For teams with polyglot backends, it removes the "agents are a Python thing" excuse.
What changes
According to the announcement, ADK is no longer a Python-first framework. Each language has its own repository (adk-python, adk-go, adk-js, adk-java, adk-kotlin) with a few particularities:
- Python: the reference implementation, with Google Cloud integrations (BigQuery, Spanner, Bigtable), model adapters (Gemini, Anthropic, OpenAI, LiteLLM) and evaluation via
adk eval. - Go: aimed at production, with the ADK 2.0 graph workflow runtime, built-in A2A handlers, OpenTelemetry traces and very small images (about 2 MiB on distroless, per the post).
- TypeScript: Zod validation, ADK 2.0 graphs and a browser bundle.
- Java: Maven, Gradle and Spring Boot integration, a fluent
LlmAgent.builder()API, reactive streaming with RxJava, and bridges for Spring AI and LangChain4j. - Kotlin: schemas generated at compile time with KSP, no runtime reflection, and on-device execution on Android. ADK 2.0 graphs are experimental in this version.
All of them ship an MCP client, so a tool exposed as an MCP server can be used from any language. Remote agents talk over A2A on HTTP, whatever language or framework sits on the other side.
How you declare a tool changes per language. In Java, for example:
LlmAgent agent = LlmAgent.builder()
.name("weather_agent")
.model("gemini-3.8-flash")
.instruction("Answer questions about the weather in a city.")
.tools(FunctionTool.create(WeatherTools.class, "getWeather"))
.build();To bootstrap a project there is scaffolding via agents-cli, which generates A2A endpoints and deployment config for Cloud Run, Gemini Enterprise Agent Runtime or GKE:
uvx google-agents-cli setup
agents-cli scaffold create my-go-agent --agent adk_go --deployment-target cloud_run --region us-central1Why it matters in production
The interesting part is not yet another framework but being able to put the agent in the language where your team, libraries and operations already live. A Go service with OpenTelemetry traces and a tiny image fits a cluster better than a Python container dragging half an ecosystem of dependencies; a Spring Boot service already has its pipeline, metrics and secret management.
MCP and A2A interoperability also reduces coupling: the agent and its tools can live in different services and different languages. The cost is the usual one: more contracts between services to version, authenticate and observe. A failing remote MCP tool becomes a network and timeout problem, not a local exception.
One caveat: the post does not state the availability status (GA or preview) of each version, and it says part of ADK 2.0 is experimental in Kotlin. I would not assume feature parity across languages without checking.
What I would do
- Check the official docs (adk.dev) for the maturity of the SDK in my language before committing.
- Start with a small, side-effect-free tool exposed over MCP, and consume it from two languages to validate interoperability.
- Treat every A2A/MCP call as another remote dependency: timeouts, bounded retries, traces and cost limits.
- Pin SDK versions and review the ADK 2.0 changes before adopting graphs, especially where parts are experimental.
- Keep agent evaluations in CI, regardless of the language chosen.