Crear agentes de IA con Google ADK: lo que aprendí sobre orquestación, contexto y coste

«Quiero ver mi nómina.» «Dame el importe de mi última nómina.» «Nómina, ya, rápido y volando.» Tres maneras de pedir lo mismo. En un sistema basado en patrones lingüísticos, eso son casi tres casos de uso distintos.

FERNANDO DE LA TORRE
Software Engineer

Nunca me había planteado crear agentes de IA con Google ADK hasta que Jesús Relinque, especialista en asistentes conversacionales con veinte años de desarrollo a la espalda, lo trajo a una Knowledge Sharing como el punto de llegada de un recorrido que empezó mucho antes: Dialogflow Essentials, después Dialogflow CX y, ahora, ADK. Tres generaciones de herramientas para resolver el mismo problema, que alguien escriba lo que necesita y el sistema responda algo útil, con mecanismos de decisión completamente distintos por debajo.

Conviene parar aquí, porque «agente» se ha vuelto una palabra elástica: hoy designa tanto al que escribe código como al que ejecuta tareas en segundo plano. El de Jesús es uno concreto, el conversacional: alguien escribe, el agente responde y la respuesta se juzga al instante. El caso más exigente en latencia y previsibilidad.

Me interesaba entender si, al tener que codificar tú los agentes, ganas algo real al adoptar ADK o simplemente cambias una complejidad por otra. Da igual el tipo de agente, el modelo o el stack. Detrás hay siempre las mismas dos preguntas: cuánto control cedes y si las decisiones de diseño que vienen a cambio son las que tú habrías tomado, y en qué momento el determinismo vale más que la inteligencia. Ahora que escribir el código es la parte barata, equivocarte ahí es lo que sale caro. Esto es lo que aprendí siguiendo el hilo de mis propias dudas durante la sesión.

De los intents al razonamiento: tres mecanismos de decisión distintos

Cada una de las tres generaciones decide la respuesta de una forma distinta:

1. Dialogflow Essentials: detección de patrones lingüísticos sobre una lista de intents. Nada generativo, puro análisis sintáctico y morfológico de lo que escribe el usuario.
2. Dialogflow CX: una máquina de estados visual, con páginas, rutas y condiciones sobre variables de sesión. Sigue sin razonar, pero organiza mejor los flujos complejos.
3. ADK: un LLM que razona la respuesta apoyándose en contexto propio, en lugar de reconocer patrones o seguir condiciones predefinidas.

Essentials fue el punto de partida, y el ejemplo de la nómina del principio explica bien por qué se queda corto en cuanto el dominio crece: afinar los patrones para que «quiero ver mi nómina» y «dame el importe de mi última nómina» no colisionen entre sí es trabajo manual y ese esfuerzo crece más rápido que el número de intenciones. El cuello de botella no era la lógica del sistema, era la finura con el lenguaje. Tanto que apareció un perfil nuevo en el sector: el lingüista computacional, alguien con formación específica en el análisis del lenguaje natural, capaz de traducir la forma en que un usuario real se expresa en los patrones rígidos que el sistema necesitaba para reconocerlo.

CX resuelve la organización de esos flujos, pero deja pendiente algo que ADK sí implementa: el contexto. En CX, esa memoria que se construye mientras el usuario conversa la mantienes y la reinyectas tú en cada paso. Con ADK sigues eligiendo dónde persiste ese estado, pero dejas de pasarlo de mano en mano de un agente a otro.

La frontera entre las dos épocas está en el verbo: con Dialogflow se entrena, con un LLM se guía. Entrenar significa alimentar el sistema con patrones lingüísticos, tantas variantes de la misma pregunta como haga falta, hasta que reconozca la intención. Guiar es otra cosa: le das al LLM una serie de pautas de conducta y el modelo hace el resto sin necesitar ese entrenamiento lingüístico previo. Esas pautas en formato markdown tienen una lógica muy próxima a la de las instrucciones que ya usamos para dirigir el comportamiento de un modelo en cualquier proyecto propio.

Crear agentes de IA con Google ADK: qué aporta el framework

Mi primera duda era de dependencia: si adopto un framework que firma Google, ¿termino atado a Gemini, a Vertex y a una factura de Cloud, aunque el agente lo escriba yo? Jesús lo desmontó en dos frases. ADK no te ata a ningún proveedor. Es abierto y está publicado en GitHub; es agnóstico respecto al modelo y se levanta en local sin necesidad de una cuenta de Google Cloud. Lo que pagas, cuando llega el momento, es el LLM que elijas conectar y la infraestructura donde elijas desplegar, y ninguna de las dos tiene que ser de Google. Así que la pregunta no era a qué te ata, sino qué trabajo te ahorra:

• Conectores para tools ya definidos: invocar una API, consultar una base de datos o enchufar un servidor MCP sin escribir la integración desde cero.
• Gestión automática del contexto: la memoria se inyecta en cada paso del flujo, tanto al agente principal como a los subagentes, sin que tengas que ir guardando datos a mano por el camino.
• Independencia del modelo: el conector admite el LLM que elijas.
• Varios lenguajes soportados, con Python como opción dominante y TypeScript como alternativa válida.

Jesús llevó la decisión al terreno de una pregunta que en desarrollo se repite y que él ilustró con un CMS como Drupal frente a un backend a medida: ¿lo hacemos a mano o cogemos el framework? Aceptar sus reglas, te gusten o no, a cambio de avanzar más rápido; o hacerlo todo a tu manera, con el tiempo y el mantenimiento que eso arrastra. Que lo que construyas esta vez sea un agente de IA no cambia la pregunta.

De una sesión sobre un stack que no usamos a diario, lo que queda no es la herramienta en sí, sino el criterio para valorarla. Conocer cómo resuelven la orquestación, el contexto y las tools tres generaciones distintas de tecnología es lo que permite entrar en una conversación de arquitectura con argumentos propios, en vez de caer por defecto en la de siempre. El código lo escribe cualquiera, incluida la propia IA. La decisión de qué construir y con qué piezas es lo que separa un asistente que funciona en producción de una demo que se cae en el segundo caso de uso.

Orquestación, subagentes y estado compartido

La arquitectura que planteó Jesús para ADK tiene tres piezas fijas, sea cual sea el caso de uso:

1. Un agente orquestador que recibe el flujo en primera instancia y decide a dónde mandarlo, apoyándose si hace falta en el LLM o en un RAG.
2. Subagentes especializados en tareas concretas: uno conecta con el modelo, otro con el repositorio documental, otro con una API externa.
3. Protocolos de comunicación entre agentes que optimizan los tiempos, porque una pregunta compleja puede pasar por el orquestador, el RAG y dos subagentes antes de volver, y en un asistente conversacional la latencia se nota tanto como el acierto.

La idea es hacerte un agente principal y agentitos que hagan tareas mucho más concretas. Divide y vencerás.

JESÚS RELINQUE
Software Architect

El contexto y la memoria se comparten entre el agente principal y los subagentes, y se inyectan solos en cada paso del flujo. Es la ventaja real frente a las dos generaciones anteriores, donde ese trabajo corría por cuenta de quien implementaba el sistema. Jesús fue realista con el límite: en casos de uso muy complejos puede no acabar de funcionar bien, aunque su experiencia general ha sido buena.

Sobre el control de versiones, un agente ADK no deja de ser un microservicio que levantas en local, al que le das unas pautas y en el que implementas la lógica de negocio que haga falta. Versionado, ramas y despliegue funcionan como en cualquier otra aplicación, y Jesús lo considera indispensable.

Dónde está el coste real y por qué esa pregunta es de negocio

Una duda que traía de una experiencia previa con servicios de IA de Google, en los que la GPU condicionaba el precio y algunos ni siquiera dejaban escoger tarjeta, era si podías elegir el cómputo al trabajar con ADK. La respuesta acota bien el problema: ADK no ejecuta inferencia. Se limita a darte las herramientas para conectar con el LLM, con otros agentes o con tus tools; la potencia de cálculo se decide donde tengas contratado el modelo. Tratar esas dos capas como una sola es la vía rápida a una estimación de costes equivocada.

El coste real de un asistente construido con ADK se reparte en tres bloques separados, y fue Wilber, compañero de Orbitant y AI engineer, quien preguntó por el conjunto del ecosistema:

• El framework, gratuito y sin licencias ni cuotas de por medio.
• El consumo del LLM elegido, que varía según el modelo y el volumen de uso.
• La infraestructura de despliegue, por ejemplo Cloud Run u otro servicio gestionado, que se dimensiona según la escala prevista.

Un asistente construido sobre Dialogflow Essentials o CX, con pocos casos de uso y caminos bien definidos, sale barato en tiempo de desarrollo porque no hay LLM que consumir. Con ADK puedes probar sin gastar nada: te descargas el framework y levantas un agente en local. El gasto real aparece cuando defines el uso previsto y decides dónde y cuánto tiene que escalar ese agente.

Visto así, con cada generación sumando más capacidad de decidir, parece que ADK gana siempre la comparación, pero no es tan simple: hay escenarios en los que el negocio necesita que la respuesta sea predecible antes que inteligente. Con reglas predefinidas sabes que «quiero saber el importe de mi nómina» va a recorrer siempre el mismo flujo. Un LLM, por bueno que sea, se puede equivocar y hay casos de uso donde ese fallo penaliza más de lo que aporta el razonamiento.

Ese es el criterio que se queda de una sesión así, y es más transferible que cualquier framework concreto: saber qué ofrece cada arquitectura para poder elegir con argumentos delante de un cliente, sin que la respuesta dependa de la herramienta con la que uno esté más cómodo. El siguiente paso es el que sugirió el propio Jesús, y es el que pienso dar: bajarme ADK, levantar un agente en local y ver de primera mano cómo se comporta el contexto compartido cuando el flujo se complica. Cuando tenga resultados, los cuento aquí.

Preguntas frecuentes

¿Google ADK es de pago?
No. El framework es abierto y gratuito, publicado en GitHub bajo licencia Apache. El coste real viene del consumo del LLM que conectes y de la infraestructura donde despliegues el agente.

¿ADK solo funciona con Gemini?
No. Es agnóstico respecto al modelo: además de Gemini, se integra con LiteLLM para conectar con modelos de otros proveedores como Anthropic o Mistral AI.

¿Puedo probar ADK sin ser cliente de Google Cloud?
Sí. Puedes descargar el framework, desarrollar tu agente y levantarlo en local. Google Cloud solo entra en juego si decides desplegar tu servicio ahí.