Google Cloud ha publicado el Agent Development Kit (ADK) para cinco lenguajes: Python, Go, TypeScript, Java y Kotlin. Cada versión se adapta al runtime y al sistema de tipos de su lenguaje, pero todas comparten arquitectura y hablan los mismos protocolos abiertos, MCP y A2A. Para equipos con backends poliglotas, quita la excusa de "los agentes solo se hacen en Python".
Qué cambia
Según el anuncio, el ADK deja de ser un framework centrado en Python. Cada lenguaje tiene su repositorio (adk-python, adk-go, adk-js, adk-java, adk-kotlin) y algunas particularidades:
- Python: implementación de referencia, con integraciones de Google Cloud (BigQuery, Spanner, Bigtable), adaptadores para varios modelos (Gemini, Anthropic, OpenAI, LiteLLM) y evaluación con
adk eval. - Go: pensada para producción, con runtime de grafos de ADK 2.0, handlers A2A integrados, trazas OpenTelemetry e imágenes muy pequeñas (unos 2 MiB sobre distroless, según el artículo).
- TypeScript: validación con Zod, grafos de ADK 2.0 y bundle para navegador.
- Java: integración con Maven, Gradle y Spring Boot, API fluida con
LlmAgent.builder(), streaming reactivo con RxJava y puentes para Spring AI y LangChain4j. - Kotlin: esquemas generados en compilación con KSP, sin reflexión en runtime, y ejecución local en Android. Los grafos de ADK 2.0 son experimentales en esta versión.
Todas incluyen cliente MCP, así que una herramienta expuesta como servidor MCP se puede usar desde cualquiera. Para hablar con agentes remotos se usa A2A sobre HTTP, sin importar el lenguaje o framework del otro lado.
El patrón para declarar una herramienta cambia según el lenguaje. En Java, por ejemplo:
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();Y para arrancar un proyecto hay scaffolding con agents-cli, que genera endpoints A2A y configuración de despliegue para Cloud Run, Gemini Enterprise Agent Runtime o GKE:
uvx google-agents-cli setup
agents-cli scaffold create my-go-agent --agent adk_go --deployment-target cloud_run --region us-central1Por qué importa en producción
Lo interesante no es un framework más, sino poder poner el agente en el lenguaje donde ya tienes el equipo, las librerías y la operación. Un servicio en Go con trazas OpenTelemetry y una imagen diminuta encaja mejor en un clúster que un contenedor Python con medio ecosistema de dependencias; un servicio Spring Boot ya tiene su pipeline, sus métricas y su gestión de secretos.
La interoperabilidad por MCP y A2A también reduce el acoplamiento: el agente y sus herramientas pueden vivir en servicios distintos y en lenguajes distintos. El coste es el habitual: más contratos entre servicios que versionar, autenticar y observar. Un fallo en una herramienta MCP remota se vuelve un problema de red y de timeouts, no una excepción local.
Una cautela importante: el artículo no indica el estado de disponibilidad (GA o preview) de cada versión, y deja claro que parte de ADK 2.0 es experimental en Kotlin. No asumiría paridad de funciones entre lenguajes sin comprobarlo.
Qué haría yo
- Comprobar en la documentación oficial (adk.dev) el estado y la madurez del SDK de mi lenguaje antes de comprometerme.
- Empezar con una herramienta pequeña y sin efectos secundarios, expuesta por MCP, y consumirla desde dos lenguajes para validar la interoperabilidad.
- Tratar cada llamada A2A/MCP como una dependencia remota más: timeouts, reintentos acotados, trazas y límites de coste.
- Fijar versiones del SDK y revisar los cambios de ADK 2.0 antes de adoptar los grafos, sobre todo si hay partes experimentales.
- Mantener las evaluaciones del agente en CI, con independencia del lenguaje elegido.