Imagina esto.
Le das a un agente cinco herramientas y una instrucción.
Tu proceso de reembolsos podría funcionar a la perfección.
Pero entonces, el correo de confirmación falla.
El agente reinicia la secuencia desde cero y repite una acción que ya había funcionado.
¿El resultado? Un doble reembolso.
El prototipo funcionó de maravilla. El sistema de producción, no.
El problema no es el prompt.
El problema es pedirle al modelo que ejecute un proceso que nunca debería estar ejecutando en primer lugar.
A los LLM se les obliga constantemente a hacer enrutamiento, planificación y gestión de errores.
Estas son tareas que el software estándar ya maneja con una previsibilidad perfecta.
Sin embargo, le estamos pidiendo a la IA que haga dos trabajos en conflicto:
- Leer el mundo: Dar sentido a datos impredecibles y no estructurados
- Ejecutar el proceso: Orquestar una secuencia rígida y predefinida de eventos
En lo primero es donde la IA brilla. En lo segundo es donde pertenece el código tradicional.
Cuando el siguiente paso ya se conoce, un modelo no debería tener que adivinarlo.
Imagina un único agente autónomo con cinco herramientas y una gran instrucción:
→ recuperar el historial de compras
→ consultar la política de reembolsos
→ emitir el reembolso si es elegible
→ enviar un correo
→ y cerrar el ticket
Para lograrlo, el agente debe recordar la secuencia, inspeccionar cada resultado de las herramientas e inferir qué viene después.
Si ese correo de confirmación falla después de que se envió el dinero, el modelo intenta reconstruir el flujo de trabajo desde su ventana de contexto en lugar de reanudar desde un estado de ejecución seguro.
El resultado es ese doble reembolso que mencionamos antes.
Cómo ADK 2.0 pone orden en el caos
El ADK 2.0 de Google soluciona esto con un enfoque completamente nuevo.
Vuelve a convertir las acciones predecibles en pasos concretos del flujo de trabajo, insertando IA solo donde realmente se necesita interpretación:
[Gráfico del flujo de reembolso - fuente: "Por qué creamos ADK 2.0"]
En el ejemplo anterior, recuperar el historial de compras, emitir el reembolso y cerrar el ticket son acciones normales de software.
Analizar la queja y redactar un mensaje de confirmación personalizado quedan en manos de la IA.
El resultado es un híbrido hermoso: ejecución fija combinada con razonamiento enfocado.
Pero quizás estés pensando: ¿no es esto solo un regreso a la automatización rígida?
¿Estamos codificando de forma rígida los mismos flujos de trabajo que los agentes debían reemplazar?
Bueno, no exactamente.
El flujo de trabajo define los límites que ya se conocen.
Los agentes siguen manejando las partes que requieren interpretación, lenguaje o criterio.
El objetivo no es eliminar la flexibilidad, sino dejar de obligar al modelo a redescubrir la misma ruta de ejecución en cada ocasión.
Al eliminar esas decisiones innecesarias del modelo, esta arquitectura cambia la ecuación por completo.
El mismo flujo de reembolso. El mismo modelo.
Pero con ADK 2.0, los tokens pasaron de 5,152 a 2,265, y la latencia bajó de 7.2s a 5.7s 🔥
[fuente: "Por qué creamos ADK 2.0"]
Esta estructura actúa como un filtro natural que reduce el uso de tokens a la mitad.
En lugar de pasar el historial completo, los agentes solo ven lo que necesitan (por ejemplo, el agente de políticas solo ve la queja).
Los beneficios son inmediatos:
- Menos ruido en el prompt y mayor privacidad
- Ejecución estrictamente limitada
- Salvaguardas: un modelo puede tomar una mala decisión, pero nunca podrá inventar su propia ruta
El frontend también necesita límites: cómo A2UI mantiene tus interfaces bajo control
Eso es genial. El flujo de reembolso ya está bajo control.
ADK 2.0 definió el camino y evitó que el agente inventara su propia secuencia.
Pero el usuario aún necesita una forma segura de ver y actuar sobre lo que produce el agente.
En otras palabras, ¡el frontend también necesita límites!
Imagina que cada reembolso aprobado ahora requiere la aprobación de un supervisor.
El agente no debería simplemente generar texto que diga:
"Este reembolso está aprobado."
Necesita mostrar una tarjeta estructurada que contenga
- el monto
- la transacción
- el motivo según la política
- botones claros de 'Aprobar/Rechazar'
Aquí es exactamente donde entra en acción el A2UI de Google.
Con A2UI, el agente devuelve un payload JSON declarativo en lugar de código frontend ejecutable.
El host valida ese payload y renderiza solo los componentes que soporta su catálogo.
El agente decide qué información aparece, y la aplicación controla cómo se renderiza.
👇 A continuación hay ejemplos de tarjetas renderizadas con A2UI que te muestran la gran variedad de composiciones de UI que A2UI puede lograr:
La demo Recipe Studio de A2UI sobre MCP de Google muestra esta arquitectura en la práctica:
Fuente: Google Developers Blog.
👆 Puedes ver que un formulario de selección estático se entrega a través de un MCP Resource, mientras que una tarjeta de receta generada dinámicamente se devuelve a través de un MCP Tool.
A2UI renderiza ambos de forma nativa dentro de la aplicación host.
¿Notas la simetría?
- ADK 2.0 limita lo que el agente puede hacer en el backend
- A2UI limita lo que puede crear en el frontend
En ambos casos, el modelo tiene espacio para razonar, pero solo dentro de los límites que la aplicación ha definido.
Volviendo al ejemplo del reembolso que mencionábamos antes, un reembolso estándar podría necesitar solo una tarjeta de aprobación simple.
Pero un caso en disputa que involucre excepciones, archivos adjuntos o reembolsos parciales podría requerir una experiencia más completa.
Ahí es donde una App MCP puede intervenir para proporcionar un espacio de trabajo contenido para interacciones complejas:
→ ADK controla lo que puede suceder
→ A2UI hace que el resultado sea visible y accionable
→ Las Apps MCP manejan los espacios de trabajo complejos
¿Tienes curiosidad por saber más?
Aquí tienes todo lo que necesitas para explorar ADK 2.0, A2UI y la plataforma de agentes más amplia de Google Cloud:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI sobre MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
¡Fue un privilegio colaborar con @googlecloud en este proyecto! 🤝
Si quieres mantenerte al día con lo último en LLM, agentes de IA y flujos de trabajo, puedes seguirme @datachaz para recibir información diaria.
