Un equipo en Google Cloud tiene Gemini, Vertex AI y el Agent Development Kit, y un agente que en la demo luce precioso. La bifurcación es la de siempre: lo que decide la supervivencia en producción no es la elección del modelo, sino el trace. Cuando el flujo multiagente devuelve una respuesta convincente y equivocada, ¿puede alguien abrir el trace y ver la coordinación que la produjo? En el stack de Google las herramientas para responder que sí están ahí y están inusualmente bien integradas, y la disciplina que las mantiene portables es la misma que las mantiene honestas. Este es el reparto.
Es el complemento específico de Google al argumento general de que OpenTelemetry es el contrato de tracing, y el espejo deliberado de la nota sobre Microsoft: apoyarse en OTel es justo lo que mantiene comparables ambos stacks, en lugar de dejarlos como dos islas.
La forma del stack
- Plataforma — Vertex AI, con Agent Engine (el runtime gestionado para desplegar y ejecutar agentes) como el sitio donde viven de verdad los agentes de producción.
- Framework — el Agent Development Kit (ADK), el framework de agentes open source de Google, con tracing incorporado y una vía limpia para exportarlo. ADK es la capa que decide qué se convierte en un span.
- Modelos — Gemini. Un componente del sistema; quien te dice cómo se comportó es el trace, no el marketing.
- Backend de telemetría — Cloud Trace, dentro del conjunto Google Cloud Observability (Cloud Trace, Cloud Logging, Cloud Monitoring), donde aterrizan los spans y donde se consultan.
La fuerza particular del stack de Google es la integración: los traces de ADK llegan a Cloud Trace con muy poca ceremonia, y Agent Engine expone la ejecución de agentes sin apenas fontanería a medida. Esa comodidad es real y —exactamente igual que en Azure— también es de lo que conviene desconfiar un poco.
Mantenlo en OpenTelemetry, no solo en Google
ADK emite tracing y Cloud Trace ingiere OTel, así que la opción sana por defecto es instrumentar en OpenTelemetry con las convenciones semánticas GenAI y dejar que Cloud Trace sea el backend en lugar del formato. Te quedas con la experiencia nativa —el tracing incorporado de ADK, la cascada de Cloud Trace, los dashboards de Observability— y los spans siguen siendo estándar.
La razón es la de siempre: un span escrito como trace OTel portable puede ir también a tu propio almacén para una carga regulada, o a una plataforma de evaluación para puntuar con LLM como juez sobre traces de producción, sin tocar el código. Un span escrito como artefacto exclusivo de Cloud Trace no puede. Exprime el backend de Google; solo no dejes que sea el único lector que tenga tu telemetría.
Qué capturar en el span
Cloud Trace te va a mostrar la cascada de llamadas. Los spans que se ganan su sitio llevan encima el contexto propio del agente:
- Fronteras de agente y razonamiento — qué agente se ejecutó, por qué eligió esa tool y con cuánta confianza. ADK te da spans estructurados; tú te aseguras de que dentro esté el por qué y no solo el qué.
- Versiones — revisión de prompt, de tool y de política en cada span, para que cuando un agente se adapte y diverja el cambio sea atribuible y no una regresión sin commit.
- Atributos de token y costo —
gen_ai.usage.*por generación; en un agente de varios pasos, las llamadas a Gemini se acumulan igual que las de cualquier otro modelo.
Gobernanza: el Collector y DLP
Para cargas reguladas, enruta a través de un Collector de OTel y redacta ahí la PII, antes de que la telemetría salga de tu perímetro, y apóyate en Sensitive Data Protection (Cloud DLP) para clasificar y desidentificar. Misma forma que en la guía de Azure, distintos nombres de producto: redacta una vez en el Collector, gobierna en la plataforma, y los prompts y argumentos de tools llegarán limpios a Cloud Trace.
El veredicto justo
El stack de Google es un sitio excelente para ejecutar agentes trazados: ADK más Agent Engine más Cloud Trace es uno de los caminos con menos fricción entre «el agente funciona en un notebook» y «el agente es observable en producción». El riesgo es la imagen especular del de Azure: la integración es tan suave que dejas de notar que tus traces adquirieron forma de Google sin que nadie lo decidiera. Toma el camino sin fricción y mantén los spans en OpenTelemetry. Así el tracing de ADK, las cascadas de Cloud Trace y los dashboards de Observability son una palanca que elegiste, no una dependencia en la que caíste.
En Google Cloud, elegir el modelo es la parte que se resuelve en una tarde; el trace es lo que determina si puedes operar el sistema. Vertex AI, ADK y Cloud Trace te dan una observabilidad sólida y bien integrada: tómala, y mantén los spans en OpenTelemetry para que pueda viajar contigo. Los agentes que sobreviven a producción, en cualquier nube, son los que puedes mirar por dentro. En Google mirar es fácil, así que la única disciplina que queda es asegurarte de que lo que miras podría irse de la nube.