Google ha ampliado los Managed Agents de la API de Gemini con tres cosas que cambian cómo se controla un agente en producción: hooks de entorno, un tope duro de tokens por ejecución y disparadores programados. Además, Gemini 3.6 Flash pasa a ser el modelo por defecto.
Puntos clave
- Los environment hooks permiten ejecutar scripts propios justo antes o justo después de cada llamada a herramienta, dentro del sandbox del agente.
- El campo `matcher` del hook acepta expresiones regulares, así que un mismo hook puede cubrir varias herramientas a la vez.
- El nuevo parámetro `max_total_tokens` pone un techo al consumo total de una ejecución.
- Hay triggers programados para tareas recurrentes y una API de Entornos para gestionar las sesiones de sandbox.
- El modelo por defecto es ahora Gemini 3.6 Flash, con 3.5 Flash y 3.5 Flash-Lite seleccionables según coste y latencia.
Qué es un hook y por qué importa aquí
Un hook es un enganche: un trozo de código tuyo que el sistema ejecuta en un punto concreto del flujo, sin que tengas que reescribir el flujo. Si el agente va a llamar a una herramienta que escribe en tu base de datos, el hook previo puede comprobar que los datos son válidos y abortar si no lo son. Si acaba de generar un archivo, el hook posterior puede revisarlo antes de que siga.
Es el mismo concepto que ya usan otros entornos de agentes, incluido el sistema de hooks de Claude Code. La novedad es que Google los mete dentro de un servicio gestionado, es decir, dentro de su sandbox y sin que tengas que montar la infraestructura.
El ejemplo que da Google es de OffDeal, un banco de inversión nativo de IA que usa hooks para validar logotipos de empresas con comprobaciones de calidad a nivel de píxel dentro del sandbox remoto. Si el logo no pasa la comprobación, no sale.
El tope de tokens es la parte aburrida y la más útil
`max_total_tokens` no suena a titular, pero resuelve el miedo número uno de cualquiera que ponga un agente a correr solo: que entre en bucle y se coma el presupuesto de un mes en una tarde. Con un techo por ejecución, el gasto máximo deja de ser una incógnita y pasa a ser un número que tú fijas.
Va en la misma dirección que el resto del sector. METR puso número al problema hace días al calcular a partir de qué presupuesto sale más barato el humano que el agente, y Cursor lo atacó por el lado de la arquitectura. Google lo ataca por el lado del contrato: tú dices cuánto, y el sistema para ahí.
Los triggers programados cierran el círculo
Hasta ahora, para que un agente gestionado hiciera algo cada lunes hacía falta un orquestador externo que lo llamara. Con triggers programados dentro de la propia API, la tarea recurrente vive donde vive el agente. Menos piezas que mantener y menos sitios donde puede romperse la cadena.
La API de Entornos completa el paquete: permite gestionar las sesiones de sandbox como recursos, en vez de tratarlas como algo efímero que aparece y desaparece con cada llamada.
Por qué importa
Si en tu empresa alguien ha montado un agente que toca sistemas reales (facturación, pedidos, CRM), esto te da dos controles que antes tenías que improvisar: validación en el punto exacto donde el agente actúa y un límite de gasto por tarea.
El orden práctico es este. Primero pon `max_total_tokens` en todo lo que ya esté corriendo, porque es un cambio de una línea y te quita el riesgo de la factura descontrolada. Después identifica las dos o tres herramientas donde un error del agente haría daño de verdad, y mételes un hook de validación previa. El resto puede esperar. Y si estabas usando 3.5 Flash por coste, revisa el cambio de modelo por defecto antes de que te llegue la sorpresa en la siguiente factura.
Relacionado
