Google publicó el 28 de julio de 2026 nuevas capacidades para Managed Agents en Gemini API: Gemini 3.6 Flash como modelo por defecto, hooks de entorno para revisar llamadas a herramientas, límites de presupuesto por tokens, triggers programados y acceso desde proyectos en free tier.
El anuncio tiene pinta de nota para desarrolladores. Lo es. Pero la lectura interesante para una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi está en otra parte: los agentes empiezan a venir con piezas que se parecen menos a una demo y más a un sistema de trabajo.
Un agente que redacta una respuesta en una pestaña es una cosa. Un agente que entra en un entorno remoto, usa herramientas, ejecuta pasos, consume presupuesto y puede repetirse por calendario es otra. Ahí ya no basta con preguntar si el modelo responde bien. Hay que preguntar quién lo frena, cuánto puede gastar, qué herramientas puede tocar y dónde queda la prueba de lo que ha hecho.
Qué ha anunciado Google
La actualización de Google gira alrededor de Managed Agents en Gemini API. Según el artículo, estos agentes gestionados pueden coordinar una tarea con una sola llamada de API y trabajar dentro de entornos preparados para ello.
Las novedades más útiles para empresa son bastante concretas.
- Hooks de entorno, para ejecutar validaciones antes o después de que el agente use una herramienta. Google habla de bloquear, revisar o auditar llamadas dentro del sandbox.
- Control de coste, con un límite de tokens para que una tarea no siga consumiendo sin parar.
- Tareas programadas, para lanzar agentes con una frecuencia definida, no solo cuando una persona pulsa un botón.
- Gestión de entornos, para listar, inspeccionar o eliminar sesiones de sandbox.
No son fuegos artificiales. Mejor así. En proyectos reales, estas piezas son las que separan un experimento curioso de un flujo que alguien puede defender delante de dirección, IT y operaciones.
La señal para empresas de Gipuzkoa
Muchas pymes no necesitan empezar por un agente totalmente autónomo. De hecho, casi siempre es mala idea. Lo útil suele ser un agente con una tarea estrecha: revisar una entrada, buscar información permitida, preparar un borrador, validar campos y dejar el resultado listo para una persona.
Piensa en un caso comercial sencillo. Entra una solicitud por la web. El agente resume la necesidad, comprueba si la empresa encaja con los servicios, revisa si faltan datos y propone una siguiente acción. Hasta ahí, bien. Lo peligroso empieza si también puede mandar emails, tocar el CRM, cambiar estados o inventar condiciones comerciales sin control.
Los hooks encajan justo en ese punto. Antes de usar una herramienta, una validación puede preguntar: esta acción está permitida para este tipo de lead, con estos datos y este nivel de confianza? Si la respuesta es no, el agente se para o pide revisión. No es glamour. Es gobierno operativo.
El gancho de negocio: agentes que no se escapan de presupuesto ni de alcance
El coste de la IA en empresa rara vez falla en la demo. Falla cuando el uso se vuelve normal: más tickets, más documentos, más leads, más tareas programadas, más personas pidiendo pruebas.
Por eso el límite de tokens que menciona Google importa. No porque todas las empresas vayan a usar Gemini API mañana, sino porque muestra una regla sana: un agente debe tener presupuesto máximo por tarea. Si llega al límite, se pausa y deja estado. Eso cambia la conversación. Ya no se trata de confiar en que el agente sea prudente. El sistema lo obliga a serlo.
Para una empresa de servicios de Donostia, una industrial de Gipuzkoa o un equipo distribuido en Euskadi, esto puede evitar dos problemas muy comunes: automatizaciones que hacen demasiado y pilotos que parecen baratos hasta que alguien mira la factura del mes.
Un ejemplo práctico: revisión de solicitudes entrantes
Un primer piloto razonable podría ser la revisión de solicitudes comerciales o de soporte. No hace falta conectar media empresa.
El flujo podría quedar así:
- El agente recibe una solicitud desde la web, email o CRM.
- Resume necesidad, urgencia, empresa, datos disponibles y datos que faltan.
- Consulta solo fuentes aprobadas: servicios, criterios de encaje, FAQs internas y política comercial básica.
- Prepara un borrador de respuesta y una ficha para revisión.
- Un hook bloquea cualquier intento de enviar el mensaje directamente si no hay aprobación humana.
- Otro hook registra fuentes usadas, coste aproximado y motivo de la recomendación.
La parte importante no es Gemini, OpenAI, Claude o cualquier otro proveedor. La parte importante es el diseño. Si el agente puede sugerir, pero no prometer. Si puede preparar, pero no cerrar. Si puede trabajar, pero dejando rastro. Ahí empieza a tener sentido.
Qué conviene decidir antes de montarlo
Antes de construir un agente conectado a herramientas, conviene responder a preguntas muy de tierra.
- Qué tarea exacta hará el agente.
- Qué herramientas puede usar y cuáles quedan fuera.
- Qué datos no debe leer nunca.
- Qué acción requiere aprobación humana.
- Qué presupuesto máximo tiene cada ejecución.
- Qué pasa cuando no sabe, llega al límite o encuentra información contradictoria.
- Quién revisa los primeros resultados y con qué criterio.
Si estas respuestas no están escritas, la tecnología solo acelerará la confusión. Puede sonar duro, pero es lo que pasa: un proceso borroso automatizado con IA sigue siendo borroso, solo que más rápido.
Cómo puede ayudar Umintia
En Umintia ayudamos a empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi a bajar los agentes IA a procesos concretos: alcance cerrado, fuentes permitidas, límites de coste, revisión humana, trazabilidad e integración con las herramientas que ya usa el equipo.
La pregunta inicial no debería ser qué agente está de moda. Debería ser más aburrida y más útil: qué tarea consume tiempo cada semana, qué parte puede preparar la IA sin riesgo y qué control necesita el equipo para confiar en el resultado.