Un equipo en Google Cloud tiene Gemini, Vertex AI y el Agent Development Kit, y un agente que demuestra hermoso. La misma bifurcación en el camino que en todos lados: la elección del modelo no es lo que decide la supervivencia en producción —el trace sí—. Cuando el flujo multi-agente devuelve una respuesta segura y equivocada, ¿puede alguien abrir el trace y ver la coordinación que la produjo? En el stack de Google las herramientas para decir 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. Aquí está la disposición.
Este es el complemento específico de Google al caso general de que OpenTelemetry es el contrato de tracing, y el espejo deliberado de la nota sobre Microsoft —apoyarse en OTel es precisamente lo que mantiene los dos stacks comparables en lugar de dos islas.
La forma del stack
- Plataforma — Vertex AI, con Agent Engine (el runtime gestionado para desplegar y correr agentes) como el lugar donde los agentes de producción de verdad viven.
- Framework — el Agent Development Kit (ADK), el framework de agentes open-source de Google, con tracing incorporado y un camino limpio para exportarlo. ADK es la capa que decide qué se vuelve un span.
- Modelos — Gemini. Un componente del sistema; el trace es lo que te dice cómo se comportó, no el marketing.
- Backend de telemetría — Cloud Trace, dentro de la suite más amplia de Google Cloud Observability (Cloud Trace, Cloud Logging, Cloud Monitoring), donde aterrizan los spans y se consultan.
La fuerza particular del stack de Google es la integración: los traces de ADK fluyen a Cloud Trace con muy poca ceremonia, y Agent Engine expone la ejecución de agentes sin mucha plomería a medida. Esa conveniencia es real, y —exactamente como en Azure— también es de lo que conviene desconfiar un poco.
Mantenlo OpenTelemetry, no solo Google
ADK emite tracing y Cloud Trace ingiere OTel, así que el default sano es instrumentar en OpenTelemetry con las convenciones semánticas GenAI y dejar que Cloud Trace sea el backend en lugar del formato. Obtienes la experiencia nativa —los traces incorporados de ADK, la cascada de Cloud Trace, los dashboards de la suite de Observability— mientras los spans siguen siendo estándar.
La razón es la misma de siempre: un span escrito como un trace OTel portable también puede ir a tu propio store para una carga regulada, o a una plataforma de evaluación para scoring con LLM-as-judge sobre traces de producción, sin cambio de código. Un span escrito como un artefacto solo-de-Cloud-Trace no puede. Usa el backend de Google a fondo; no dejes que se vuelva el único lector que tiene tu telemetría.
Qué capturar en el span
Cloud Trace te mostrará la cascada de llamadas. Los spans que se ganan su lugar llevan el contexto específico de agente encima:
- Fronteras de agente y razonamiento — qué agente corrió, por qué seleccionó la tool que seleccionó, su confianza. ADK te da spans estructurados; tú te aseguras de que el por qué esté en ellos, no solo el qué.
- Versiones — revisión de prompt, tool y política en cada span, para que cuando un agente se adapte y diverja el cambio sea atribuible en lugar de una regresión sin commit.
- Atributos de token y costo —
gen_ai.usage.*por generación; las llamadas a Gemini en un agente multi-paso se componen igual que cualquier otro modelo.
Gobernanza: el Collector y DLP
Para cargas reguladas, enruta a través de un Collector de OTel y redacta PII ahí, antes de que la telemetría salga de tu perímetro, y apóyate en Sensitive Data Protection (Cloud DLP) para clasificación y des-identificación. Misma forma que 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 que llegan a Cloud Trace ya están limpios.
La evaluación honesta
El stack de Google es un lugar excelente para correr agentes trazados —ADK más Agent Engine más Cloud Trace es uno de los caminos con menos fricción desde "el agente funciona en un notebook" hasta "el agente es observable en producción"—. El riesgo es la imagen espejo del de Azure: la integración es tan suave que dejas de notar que tus traces se volvieron silenciosamente con forma de Google. Toma el camino sin fricción; mantén los spans en OpenTelemetry. Entonces el tracing de ADK, las cascadas de Cloud Trace y los dashboards de Observability son apalancamiento que elegiste, no una dependencia en la que quedaste atrapado.
Cierre
En Google Cloud el modelo es la decisión fácil y el trace es la que determina si puedes correr el sistema. Vertex AI, ADK y Cloud Trace te entregan una historia de observabilidad fuerte y bien integrada —tómala, y mantén los spans en OpenTelemetry para que la historia viaje—. Los agentes que sobreviven a producción en cualquier nube son los que puedes ver por dentro; en Google ver es fácil, así que la única disciplina real que queda es asegurarte de que lo que ves podría dejar la nube.