En Google I/O 2025, Google presentó una serie de actualizaciones a Google AI Studio y a la API de Gemini que cambiaron en silencio lo que se necesita para lanzar un agente en producción. La novedad principal son los agentes gestionados en la API de Gemini, con conexiones integradas al ecosistema de Google y un flujo de autoría dentro de AI Studio que permite a un equipo funcional pasar del boceto al agente desplegado en una sola tarde. El lanzamiento importa porque gran parte del trabajo pesado que antes recaía sobre el equipo de ingeniería ahora forma parte de la plataforma, y la barrera para poner un agente real en manos de usuarios reales se redujo de manera significativa.
Este artículo recorre lo que se lanzó, qué cambia sobre el trabajo práctico de construir un agente, dónde la responsabilidad sigue en manos del operador y cómo un socio de Google Gemini como ProvenROI encaja para las empresas que quieren avanzar rápido sin pasar seis meses aprendiendo la plataforma.
Lo que Google lanzó realmente
El anuncio cubrió mucho terreno, y las partes relevantes para los equipos que construyen agentes se agrupan en varios bloques que vale la pena entender por separado antes de entrar en las implicaciones.
El primer bloque es el runtime de agentes gestionados dentro de la API de Gemini. Hasta este lanzamiento, construir un agente sobre Gemini significaba orquestar las llamadas al modelo, las llamadas a herramientas, el estado, los reintentos, el streaming, el manejo de errores, las barreras de seguridad y el despliegue por cuenta propia. El runtime de agentes gestionados se encarga de la mayor parte de eso por ti. Defines el objetivo del agente, las herramientas a las que tiene acceso, las políticas bajo las que opera y las superficies que atiende, y el runtime gestiona la orquestación. El equipo de ingeniería queda liberado para centrarse en las partes que realmente diferencian al agente: el diseño, las herramientas, los datos y la experiencia de usuario.
El segundo bloque son las integraciones con el ecosistema de Google. Los agentes Gemini ahora tienen conexiones nativas a Google Workspace, incluidos Gmail, Calendar, Drive, Docs, Sheets y Meet, así como a Google Search, Google Maps, YouTube y el conjunto más amplio de superficies de datos de Google que la mayoría de las empresas ya usan. Las integraciones no son un conjunto de claves API que debes unir manualmente. Forman parte del runtime gestionado, con autenticación, permisos y límites de tasa manejados por la plataforma.
El tercer bloque es la experiencia de autoría en Google AI Studio. Studio ahora admite un tipo de proyecto de agente que combina la selección del modelo, las instrucciones del sistema, la configuración de las herramientas, la configuración de integraciones, las ejecuciones de prueba, el conjunto de evaluación y el despliegue en un único espacio de trabajo. Un equipo puede construir, iterar y lanzar un agente sin salir de Studio, y el mismo proyecto produce tanto el prototipo en AI Studio como el endpoint de la API de producción.
El cuarto bloque es la capa de evaluación y observabilidad. El runtime de agentes gestionados captura trazas estructuradas de cada ejecución del agente, con las llamadas a herramientas, el razonamiento intermedio, la latencia, el coste y el resultado disponibles para revisión. El conjunto de evaluación admite tanto evaluación automatizada basada en rúbricas como evaluación humana con una cola de revisión integrada. La observabilidad es una de las partes del lanzamiento que los operadores con experiencia en producción suelen notar primero, porque resuelve un problema que la mayoría de los equipos solía manejar con una maraña de registros personalizados.
El quinto bloque es la historia de despliegue y escalado. Un agente Gemini construido en AI Studio puede desplegarse en un endpoint gestionado con un solo clic, servirse con la latencia y el rendimiento que proporciona la infraestructura de Google y escalar sin que el equipo de ingeniería tenga que pensar en el runtime. El agente también puede integrarse directamente en las superficies de Google, incluidos Gmail y Docs, con el embedding gestionado por la plataforma.
La combinación de esos cinco bloques es lo que importa. Cada uno por separado sería una mejora incremental útil. Juntos cambian la cantidad de esfuerzo requerida para lanzar un agente serio, pasando de una inversión de ingeniería de varios trimestres a unas pocas semanas de trabajo focalizado en diseño e integración.
Qué cambian los agentes gestionados en el trabajo práctico
Para los equipos que han construido agentes de la manera difícil durante los últimos dos años, el cambio a agentes gestionados en la API de Gemini va a sentirse como una alteración sustancial en el trabajo diario. Algunos de los cambios merecen ser destacados específicamente.
La orquestación es ahora responsabilidad de la plataforma. El bucle de llamada al modelo, llamada a la herramienta, actualización de estado, manejo de errores, reintento y síntesis de la respuesta solía ser la mayor parte del trabajo de ingeniería. El runtime gestionado se encarga de todo eso. La atención del equipo se desplaza a diseñar el agente en lugar de construir el runtime que lo ejecuta.
La autenticación y la autorización para el acceso a herramientas las maneja la plataforma. El patrón antiguo de unir flujos OAuth, cuentas de servicio y gestión de permisos para cada herramienta que usa el agente era una de las partes más frágiles al construir un agente integrado con Workspace. El nuevo patrón consiste en declarar las integraciones que quieres y dejar que la plataforma gestione la autenticación, con el flujo de consentimiento presentado al usuario final de manera nativa y clara por Google.
La evaluación forma parte de la plataforma en lugar de ser una construcción separada. El conjunto de evaluación admite tanto evaluación automatizada basada en rúbricas como una cola para revisión humana, con las ejecuciones muestreadas en producción y los resultados retroalimentando el ciclo de iteración. Los equipos que antes dedicaban semanas a construir un arnés de evaluación ahora pueden dedicar ese tiempo a diseñar la rúbrica y los casos de prueba que realmente importan.
La observabilidad está integrada. Cada ejecución se captura con la traza completa, las llamadas a herramientas, la latencia, el coste y el resultado, y la traza es consultable desde Studio y desde la API. Los equipos que antes montaban registros personalizados, trazado personalizado y atribución de costes personalizada ahora pueden empezar con la capa de la plataforma y añadir piezas personalizadas solo donde sean realmente necesarias.
El despliegue es un clic en lugar de un proyecto. La canalización de despliegue que antes llevaba un sprint configurarla ahora forma parte de Studio. El equipo de ingeniería puede concentrarse en el diseño del agente y la lógica de integración en lugar de en la infraestructura de despliegue que pone el agente frente a los usuarios.
El efecto acumulado es que el tiempo de la idea al agente desplegado para un equipo que conoce la plataforma ahora se mide en semanas en lugar de trimestres. Para un equipo que aún no conoce la plataforma, la curva de aprendizaje es el coste principal restante, y la curva es lo bastante empinada como para que un socio acreditado de Google Gemini marque la diferencia entre una victoria rápida y un desvío largo.
Las integraciones del ecosistema de Google en la práctica
La historia de las integraciones es una de las partes del lanzamiento que se entiende mejor con un recorrido concreto, porque el argumento abstracto de "integración profunda con el ecosistema de Google" puede ocultar cuánto trabajo realiza realmente la plataforma por el equipo.
Toma como ejemplo un agente de seguimiento de ventas. La tarea del agente es leer el correo y el calendario del representante de ventas, identificar las reuniones que necesitan una nota de seguimiento, redactar la nota de seguimiento basándose en las notas de la reunión y en cualquier documento relacionado en Drive, presentar el borrador para revisión y enviar la nota una vez que el representante la apruebe. Construir ese agente de la manera difícil implica flujos OAuth para Gmail, Calendar y Drive, un almacén de estado para rastrear qué reuniones ya se han gestionado, una cola para borradores pendientes de aprobación, una interfaz de usuario para que el representante revise y edite los borradores y una canalización de despliegue para mantener todo en funcionamiento. El equipo que lo construye a la manera antigua afronta varios meses de trabajo incluso antes de que el diseño del prompt del agente esté afinado.
Construir el mismo agente con el runtime de agentes gestionados tiene una forma de trabajo diferente. Las integraciones para Gmail, Calendar y Drive se declaran en la configuración del agente. El estado y la cola de aprobación los gestiona el runtime. La interfaz de revisión puede ser la cola de revisión integrada de Studio o un embed en Workspace presentado dentro de Gmail, según dónde prefiera trabajar el representante. El despliegue es un clic. El trabajo de ingeniería que queda es el diseño del prompt, la selección de herramientas, la rúbrica para definir qué constituye una buena nota de seguimiento y la integración con los sistemas propietarios del equipo que no sean nativos de Google. Los meses de plomería se convierten en semanas de diseño y ajuste.
El patrón se repite en la mayoría de los casos de uso de agentes que las empresas quieren lanzar. Un agente de preparación de reuniones que lee el calendario, extrae los documentos relevantes de Drive, resume los correos previos pertinentes y presenta un resumen de una página antes de que empiece la reunión. Un agente asistente de investigación que ejecuta una consulta en Google Search, recopila los resultados relevantes, sintetiza una respuesta estructurada y guarda la respuesta en Drive para referencia posterior. Un agente de atención al cliente que vigila señales específicas en Gmail y Calendar, extrae datos relacionados de Sheets y presenta una lista priorizada de acciones. Cada uno de esos agentes solía suponer un trimestre de trabajo de ingeniería. Ahora cada uno requiere unas semanas si el diseño es claro y el equipo conoce la plataforma.
La integración nativa con Google también hace a los agentes más útiles en las superficies donde realmente se realiza el trabajo. Un agente de seguimiento que puede mostrar sus borradores dentro de Gmail es más útil que el mismo agente que obliga al representante a iniciar sesión en una herramienta separada para revisar los borradores. Un agente de preparación de reuniones que puede colocar su resumen en el evento de Calendar es más útil que el mismo resumen entregado por correo electrónico. La capacidad de la plataforma para incrustar el agente en las superficies de Google es una de las partes del lanzamiento que se traduce en mayor adopción, porque elimina la fricción de cambiar de herramienta para obtener el valor.
Dónde la plataforma sigue dependiendo del operador
El runtime de agentes gestionados es realmente un avance, y también no es todo el trabajo. El diseño del agente sigue siendo responsabilidad del equipo, incluyendo qué hace, qué no hace, las herramientas que tiene, las políticas bajo las que opera y la forma en que maneja la ambigüedad. Los equipos que lanzan los mejores agentes dedican más tiempo al diseño que a la implementación, y el runtime gestionado hace que esa proporción sea aún más marcada. La rúbrica para evaluar el agente también corresponde al equipo. La plataforma proporciona la infraestructura de evaluación, pero el equipo define cómo se ve lo bueno, qué modos de fallo vigilar y cuál es el umbral para lanzar.
La integración con los sistemas propietarios del equipo recae en el equipo. Las integraciones del ecosistema de Google cubren mucho terreno, pero la mayoría de las empresas tiene un conjunto significativo de sistemas internos que no forman parte del stack de Google, y el agente necesita acceder a ellos para ser útil. El cambio organizacional para lograr la adopción del agente también depende del equipo. Lanzar es la mitad del trabajo. La otra mitad es lograr que los usuarios lo utilicen realmente, lo que implica formación, documentación, bucles de retroalimentación y el trabajo blando de generar confianza. Y el programa continuo de monitorización, evaluación y mejora del agente recae en el equipo. Los agentes que generan valor compuesto a lo largo del tiempo son los que se operan como un programa y no como un proyecto.
El umbral para un agente listo para producción
La frase "production ready" se usa de manera imprecisa en el ámbito de los agentes, y vale la pena especificar qué significa para un agente Gemini que se despliega en las operaciones diarias de una empresa. Un agente listo para producción tiene un objetivo claramente definido que se relaciona con un resultado empresarial, con criterios de éxito explícitos y el equipo capaz de responder para qué sirve el agente en una sola frase. Tiene herramientas limitadas al conjunto mínimo necesario, resistiendo la tentación de conceder accesos amplios porque los alcances estrechos son más fáciles de evaluar y menos propensos a comportarse de forma inesperada. Tiene un conjunto probado de políticas para ambigüedad, errores y casos límite escritas en las instrucciones del sistema. Cuenta con una suite de evaluación que se ejecuta continuamente y una cola de revisión humana para los casos que la rúbrica no cubre. Y tiene un operador nombrado que vigila las métricas, gestiona la cola y dirige la iteración durante toda la vida del agente.
El entorno administrado hace que alcanzar ese estándar sea más factible que antes, aunque el estándar en sí no ha cambiado. Un agente administrado que se lanza sin un objetivo claro, herramientas acotadas, políticas probadas, una suite de evaluación y un responsable no está más listo para producción que ese mismo agente construido a la antigua usanza.
Patrones y antipatrón comunes
Los patrones que funcionan tienden a repetirse en los equipos que lanzan agentes Gemini con éxito. Empezar con un alcance estrecho: un solo agente con una única función y dejar que tenga éxito antes de ampliarlo. Conectar el agente a las superficies que el usuario ya utiliza, de modo que aparezca dentro de Gmail o Calendar en lugar de vivir en una aplicación separada que el usuario tenga que recordar visitar. Invertir en la rúbrica de evaluación en la primera semana para que las decisiones sobre el modelo y las herramientas se tomen con una imagen clara de lo que significa «bueno». Ejecutar la suite de evaluación desde el primer día en lugar de añadirla a posteriori. Tratar el agente como un programa con un operador nombrado y una cadencia semanal en lugar de un proyecto que se entrega y se olvida.
Los antipatrón también se repiten. Dar al agente acceso a todas las herramientas porque el acceso es barato acarrea costes posteriores en modos de fallo y en trabajo de evaluación. Omitir la disciplina de las instrucciones del sistema porque el modelo es suficientemente listo para averiguarlo produce agentes que sorprenden al operador. Lanzar sin una cola de revisión humana porque existe la suite de evaluación pasa por alto los casos que la rúbrica no cubre, que suelen ser los que más importan. Tratar el lanzamiento como la línea de meta en lugar de como el inicio del programa operativo deja que el agente se deteriore a medida que cambia el entorno. Construir aislado de los usuarios que usarán el agente resulta en algo que no encaja con el flujo de trabajo real que tienen.
Qué buscar en un partner de Google Gemini
Las mejoras de la plataforma han bajado el umbral lo suficiente como para que más equipos puedan crediblemente construir sus propios agentes Gemini con respecto a hace un año. Para los equipos que quieren moverse más rápido de lo que permite la curva de aprendizaje interna, o que quieren un partner que ya haya ejecutado el playbook en problemas similares, elegir el partner de Google Gemini adecuado es una de las decisiones de mayor apalancamiento del programa.
Un partner creíble ha construido y desplegado agentes Gemini en producción, idealmente con más de un cliente y más de un caso de uso. La capacidad de señalar agentes que están realmente en producción, con los resultados empresariales que han generado, es la evidencia más directa de capacidad. Un partner cuyos estudios de caso son demostraciones y pilotos en lugar de programas desplegados sigue teniendo su capacidad, en gran medida, en el terreno teórico.
Un partner creíble tiene una metodología clara que cubre el diseño, la evaluación, el despliegue y la operación continua. La metodología es el músculo que hace que el trabajo sea repetible entre clientes. Un partner cuyo proceso es «lo resolvemos sobre la marcha» tiende a tardar más y a generar resultados más variables que uno cuyo proceso es producto de varias decenas de compromisos anteriores.
Un partner creíble tiene experiencia integrada en la pila de Google. La API de Gemini es una pieza del panorama. Las integraciones con Google Workspace, la infraestructura de Google Cloud y el ecosistema Google en general importan para cualquier agente que vaya a vivir dentro de un flujo de trabajo nativo de Google. Un partner que conoce Gemini de forma aislada tiende a entregar agentes que funcionan de forma aislada. Un partner que conoce la pila completa tiende a entregar agentes que encajan en la empresa.
Un partner creíble tiene la capacidad de diseño y producto para moldear el agente, no solo la capacidad de ingeniería para construirlo. El trabajo de ingeniería es ahora, en gran medida, responsabilidad de la plataforma. Lo que queda es el diseño de lo que hace el agente, cómo se comporta y dónde encaja en el día del usuario. Un partner cuya fortaleza es puramente la ingeniería tiende a entregar agentes técnicamente sólidos pero operativamente débiles. Un partner que puede moldear el agente de extremo a extremo tiende a entregar agentes que se adoptan.
Un partner creíble tiene la disciplina de evaluación que la plataforma ahora permite. La suite de evaluación es parte de la plataforma, y un partner que no la utiliza bien tendrá agentes que derivan en producción. La prueba honesta es pedir al partner que explique la rúbrica de evaluación y el proceso de revisión para un compromiso con un cliente reciente y ver si la respuesta es detallada y específica o vaga y aspiracional.
Un partner creíble tiene la capacidad de gestión del cambio para lograr la adopción del agente por parte de los usuarios finales. El lanzamiento del agente es el inicio del valor, no el final. Un partner que envía el agente y desaparece suele dejar al cliente con un agente que acumula polvo. Un partner que permanece durante el trabajo de adopción suele dejar al cliente con un agente que realmente cambia cómo se realiza el trabajo.
Un partner creíble tiene informes honestos. La cadencia de revisiones operativas semanales, informes de liderazgo mensuales y revisiones comerciales trimestrales frente al objetivo original es la disciplina que demuestra que el trabajo fue real. Un partner cuyos informes son solo reel highlights y sin meses bajos es un partner cuyos datos merecen escrutinio.
Cómo trabaja ProvenROI como partner de Google Gemini
El enfoque de ProvenROI para el trabajo con agentes Gemini sigue la misma disciplina que la firma aplica en sus otros compromisos, con las especificidades adaptadas a la forma de los programas de agentes. La pregunta de partida siempre es qué resultado empresarial se supone que debe producir el agente, con la respuesta referenciada en métricas que el equipo directivo utiliza para tomar decisiones de inversión.
El compromiso suele comenzar con un diagnóstico focalizado. El equipo trabaja con el cliente para identificar los casos de uso candidatos para agentes, los puntúa según los criterios de valor empresarial, viabilidad técnica y probabilidad de adopción, y recomienda un punto de partida lo bastante estrecho como para poder desplegarse en un trimestre y lo bastante significativo como para justificar la inversión. El diagnóstico produce un pequeño conjunto de artefactos claros que el equipo directivo usa para comprometerse con la fase de construcción.
La fase de construcción sigue la forma natural del entorno de ejecución administrado, con el trabajo de diseño realizado en Google AI Studio, la integración hecha con los conectores del ecosistema Google y los sistemas propietarios del cliente, la rúbrica de evaluación definida en la primera semana y ejecutada desde el primer día, y el despliegue realizado a través del endpoint administrado del Studio o embebido en las superficies de Google donde los usuarios ya trabajan. La fase de construcción suele durar un trimestre y termina con el agente en producción y el programa operativo puesto en marcha a su alrededor.
La fase operativa es la parte que compone. El agente se supervisa con la suite de evaluación, se trabaja la cola de revisión, se corrigen las regresiones, los nuevos modos de fallo se incorporan a la rúbrica y el agente se mejora con la cadencia que exige el ciclo operativo. Los informes al equipo directivo son honestos. Un mes plano es un mes plano, con el diagnóstico y el ajuste recomendado. Los resultados de la evaluación del agente, las métricas de adopción de usuarios, las métricas de resultado empresarial y el coste se informan lado a lado según la cadencia que el equipo directivo necesita para tomar decisiones de inversión, y la confianza que se compone a partir de esos informes es lo que hace que el compromiso sea duradero durante el año y más allá.
Cómo decidir si construir, asociarse o ambas cosas
Construir internamente suele tener sentido para empresas con un conjunto claro de casos de uso de agentes en la hoja de ruta, un equipo de ingeniería con capacidad para aprender la plataforma y ejecutar el programa operativo, y la paciencia para permitir que el primer agente tarde más a cambio del conocimiento institucional que se genera. La vía interna es más lenta al principio y más barata a escala. Asociarse suele tener sentido para empresas que quieren moverse con rapidez en un caso de uso de alto valor sin esperar la curva de aprendizaje interna, que tienen un compromiso directivo para lanzar el primer agente en un trimestre en lugar de un año, o que quieren un partner creíble que ejecute el programa operativo mientras el equipo interno se centra en otros trabajos.
El modelo híbrido suele ser la opción más sólida. Un partner lanza el primer agente y pone en marcha el programa operativo. El equipo interno trabaja junto al partner durante la construcción, absorbiendo la metodología y la experiencia en la plataforma. El partner permanece en el programa operativo durante el primer año o pasa a un rol consultivo una vez que el equipo interno está listo para asumirlo. El siguiente agente lo construye el equipo interno con el partner como caja de resonancia. El modelo da a la empresa la rapidez de la asociación en el primer agente y la estructura de costes de la propiedad interna en los agentes posteriores.
Lo que el lanzamiento significa para el mercado de agentes en general
El listón para lanzar un agente útil ha bajado de forma significativa, y las empresas que esperaban a que madurara la capa de la plataforma ahora tienen menos motivos para esperar. Es probable que en los próximos 12 meses se vea una ola de agentes en producción lanzados por equipos que no habrían intentado el trabajo hace un año, y las compañías que se muevan primero dentro de sus categorías construirán ventajas que se componen. La diferenciación está pasando de la ingeniería del agente al diseño del mismo, porque las plataformas convergen hacia una forma similar de entorno de ejecución administrado, integración del ecosistema, evaluación y despliegue. La ventaja del ecosistema Google es real para las empresas que ya operan en Google Workspace o Google Cloud, y el papel del partner está cambiando de construir el entorno de ejecución a aportar la disciplina de diseño, el rigor de evaluación, la gestión del cambio y el programa operativo que la plataforma no proporciona.
Conclusión
Los agentes administrados en la API de Gemini suponen un avance real para los equipos que construyen agentes y para las empresas que quieren usarlos. La orquestación, las integraciones, la evaluación, la observabilidad y el despliegue ahora forman parte de la plataforma, y el tiempo desde la idea hasta el agente desplegado ha pasado de trimestres a semanas para los equipos que conocen la plataforma.
El trabajo que queda es el trabajo que siempre fue más importante. El diseño de lo que hace el agente. La rúbrica de lo que significa «bueno». La integración con los sistemas propietarios de la empresa. La gestión del cambio que logra la adopción del agente. El programa continuo que lo mantiene valioso con el tiempo. La plataforma no ha eliminado ese trabajo. Ha despejado el camino para que los equipos puedan centrarse en él.
Para las empresas que evalúan si construir, asociarse o hacer ambas cosas, la respuesta correcta depende de la hoja de ruta, la capacidad interna, el valor del primer agente y el papel a largo plazo de los agentes en el negocio. Un partner creíble de Google Gemini puede acortar el tiempo hasta un agente funcional y aportar la disciplina de diseño y evaluación que la plataforma no proporciona. Un equipo interno sólido puede construir la capacidad a largo plazo que se compone. Un modelo híbrido suele capturar lo mejor de ambos.
ProvenROI colabora con empresas en las fases de diseño, construcción y operación de programas de agentes de Gemini, con la misma disciplina de medición, integración e informes honestos que definen sus otros compromisos. Si el lanzamiento de agentes gestionados en la API de Gemini ha puesto un programa de agentes en su hoja de ruta y desea un socio que ya haya ejecutado el manual de trabajo, esa es la conversación que debe tener. Si el camino a seguir es interno, los mismos principios siguen aplicando, y la disciplina es la parte que demuestra que el trabajo fue real.