Google anunció el 22 de junio de 2026 la disponibilidad general de Interactions API, su interfaz principal para trabajar con modelos Gemini y agentes. El detalle técnico es que unifica llamadas a modelos y agentes, añade estado en servidor, ejecución en segundo plano, combinación de herramientas y generación multimodal.
La lectura para una empresa de Donostia - San Sebastián o Gipuzkoa es menos de API y más de proceso. Los agentes están dejando de ser una ventana de chat que contesta rápido. Empiezan a parecerse a piezas de software que recuerdan contexto, esperan a que termine una tarea larga, llaman herramientas y siguen trabajando aunque la persona no tenga la pestaña abierta.
Eso abre casos útiles. También obliga a ordenar la casa antes de conectar nada. Si un agente puede tocar CRM, documentación interna, correo, tickets o datos de operaciones, el proyecto ya no va de "probar Gemini". Va de decidir qué flujo merece automatizarse, qué permisos necesita y dónde se queda la revisión humana.
Qué ha anunciado Google
Google describe Interactions API como un endpoint único para modelos Gemini y agentes. Según el anuncio, la API pasa a ser la opción por defecto en Google AI Studio, Gemini API y la documentación de Google. La antigua generateContent API sigue soportada, pero Google espera que las capacidades de agentes y tareas largas lleguen cada vez más por la nueva interfaz.
Hay cuatro piezas interesantes para empresa:
- Estado en servidor, para mantener contexto de una interacción sin reconstruirlo todo cada vez.
- Ejecución en segundo plano, útil cuando una tarea tarda más que una respuesta de chat.
- Managed Agents, para trabajar con agentes definidos y no solo con prompts sueltos.
- Combinación de herramientas y multimodalidad, para que el agente pueda usar APIs, documentos, imágenes o salidas estructuradas según el caso.
Dicho simple: Google está empujando a los desarrolladores hacia agentes más operativos. No solo respuestas bonitas.
El gancho de negocio: tareas largas y contexto real
En muchas empresas, las tareas que más tiempo consumen no se resuelven en una única pregunta. Preparar una propuesta comercial puede exigir leer una solicitud, buscar datos del cliente, revisar documentos anteriores, comprobar disponibilidad, redactar un borrador y pedir aprobación. Gestionar una incidencia puede exigir clasificarla, consultar manuales, mirar tickets parecidos y escalar si falta información.
Un agente con estado y ejecución en segundo plano encaja mejor con ese tipo de trabajo. No porque sea mágico, sino porque se parece más a cómo funcionan los procesos reales: varios pasos, esperas, herramientas y decisiones intermedias.
Para una pyme de Euskadi, el valor no está en tener "un agente" por tenerlo. El valor aparece cuando se escoge un flujo repetido y se le quita fricción sin perder control. Ventas, soporte, administración y operaciones suelen tener candidatos claros.
Dónde puede servir en una empresa de Gipuzkoa
Un primer caso razonable no debería empezar por lo más delicado. Algunos ejemplos más aterrizados:
- Un agente comercial que resume un lead entrante, busca contexto en el CRM y prepara una ficha para que ventas decida el siguiente paso.
- Un agente de soporte que revisa tickets antiguos y documentación aprobada antes de proponer una respuesta.
- Un agente interno que prepara borradores de ofertas o informes, pero no los envía sin revisión.
- Un flujo de compras que consulta información pública de proveedores y deja una nota estructurada para validación.
- Un asistente de operaciones que reúne datos de varias fuentes y avisa si falta algo antes de cerrar la tarea.
La parte importante está en el verbo "prepara". Al principio, casi siempre conviene que el agente prepare, ordene y sugiera. Que actúe solo puede venir después, si las pruebas lo justifican.
Qué revisar antes de construir
Antes de pedir una integración o montar una prueba, merece la pena responder cinco preguntas bastante incómodas.
- Qué tarea exacta hará el agente. Si la definición cabe en "ayudar a ventas", todavía es demasiado amplia.
- Qué sistemas podrá consultar. CRM, Drive, SharePoint, ERP, email, tickets o bases internas no tienen el mismo riesgo.
- Qué acciones quedan prohibidas. Enviar presupuestos, cambiar datos maestros o responder reclamaciones pueden requerir aprobación.
- Qué hará cuando no sepa. Un buen agente debe poder decir "no tengo información suficiente" y escalar.
- Cómo se medirá el resultado. Tiempo ahorrado, errores evitados, velocidad de respuesta, calidad del borrador o adopción por equipo.
Sin estas respuestas, una API más potente solo acelera la confusión.
La oportunidad para equipos locales
La noticia de Google confirma una dirección que ya se ve en el mercado: los agentes van a entrar en software de empresa, no solo en demos. Para compañías de Donostia - San Sebastián, Gipuzkoa y Euskadi, esto puede ser una buena noticia si se aborda con calma.
No hace falta rediseñar toda la organización. Hace falta elegir un proceso, marcar límites, conectar las fuentes mínimas y medir si el equipo lo usa de verdad. Si funciona, se amplía. Si no, se aprende rápido y barato.
En Umintia solemos empezar por ahí: un diagnóstico corto, una matriz de casos de uso y un piloto con revisión humana. Menos espectáculo, más proceso. Para empresas reales, suele salir bastante mejor.