Agente IA
Noticia8 min

Gemini Interactions API cambia a `steps`: la migración que afecta debugging, tools y agentes largos

Google documentó cambios de ruptura en Interactions API para mover respuestas desde `outputs` hacia una línea de tiempo `steps`. Para builders, el cambio importa porque vuelve observables tool calls, búsquedas, streaming y tareas en background.

Gemini
Flujo editorial de Gemini Interactions API con una línea de tiempo de steps, tools y estado de ejecución

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

Google tiene una migración silenciosa pero importante para quienes están construyendo agentes sobre Gemini: la Interactions API está moviendo la forma de leer respuestas desde outputs hacia una línea de tiempo estructurada llamada steps. La guía de cambios de ruptura indica que el esquema legacy se elimina el 8 de junio de 2026 y que la nueva forma está pensada para capacidades futuras como steering durante la corrida y tool calls asíncronas.

Para un builder, esto no es solo “cambia el JSON”. Es un cambio de modelo mental: una respuesta de agente deja de ser un bloque final y empieza a verse como una secuencia auditable de pasos.

Panel editorial con steps de usuario, salida del modelo, búsquedas y tool calls ordenados como timeline

Qué cambia exactamente

Antes, el cliente leía un arreglo outputs. Eso servía para casos simples, pero era pobre para agentes largos. Cuando hay herramientas, búsquedas, streaming, multimodalidad o estado de conversación, un arreglo plano termina escondiendo lo que pasó.

El nuevo contrato usa steps. Cada paso tiene tipo y estado. La guía menciona pasos como entrada de usuario, salida del modelo, function calls y resultados de herramientas del servidor. También cambia cómo se escucha streaming: aparecen eventos como interaction.created y step.delta.

La documentación de migración general refuerza la dirección: Interactions API es la interfaz estándar recomendada para desarrollo nuevo con Gemini, especialmente cuando necesitas estado server-side, workflows agentic, conversaciones multimodales o tareas largas en background.

Por qué importa para producción

Un agente falla de formas raras. Puede escoger mal una tool, recibir un resultado parcial, quedarse sin contexto, duplicar una acción o terminar con una respuesta final que parece correcta pero nació de una búsqueda equivocada.

Con steps, el equipo tiene una superficie mejor para responder preguntas operativas:

  • ¿qué tool llamó realmente el modelo?;
  • ¿qué resultado recibió antes de contestar?;
  • ¿el error ocurrió en el modelo, en la tool o en streaming?;
  • ¿qué parte de la conversación quedó almacenada en servidor?;
  • ¿qué evento se puede mostrar en UI sin inventar estados?

Ese tipo de trazabilidad es justo lo que falta cuando un prototipo de agente se vuelve producto. No basta con guardar el prompt y la respuesta final.

La parte que puede romperte

La migración pide cambios concretos:

  1. leer contenido desde steps en vez de outputs;
  2. manejar tipos como user_input y model_output;
  3. buscar function calls dentro del timeline;
  4. actualizar herramientas del servidor, por ejemplo eventos de Google Search;
  5. ajustar streaming a los nuevos eventos SSE;
  6. si usas historial stateless, pasar el arreglo steps en el input de la siguiente solicitud.

El error común será actualizar solo el happy path. Una llamada de texto simple puede seguir pareciendo bien si usas propiedades convenientes del SDK, pero los flujos intercalados con tools, imágenes, audio o búsqueda necesitan iterar manualmente el timeline.

Escena editorial con una tarea en background, eventos SSE, búsqueda y tool calls conectados a una consola de debugging

Cómo lo migraría sin romper agentes

Yo no haría un cambio masivo a ciegas. Haría una capa adaptadora que convierta steps a los eventos internos que tu app ya entiende: user_message, model_text, tool_call, tool_result, background_status y final_output.

Después correría tres pruebas:

  • conversación multi-turn con previous_interaction_id;
  • agente con function calling;
  • flujo con herramienta del servidor o tarea background.

Si tu UI muestra progreso, prueba streaming explícitamente. Un agente que “funciona” en modo final puede romperse cuando el usuario espera ver pasos intermedios.

Para SEO cualificado, el tema apunta a búsquedas como Gemini Interactions API steps, outputs to steps Gemini, Interactions API breaking changes y Gemini agentic workflows. La intención es clara: equipos migrando código real, no lectores casuales.

Si todavía estás definiendo cómo deben verse tools, estado y validación humana en tus agentes, puedes empezar por el curso gratis. Pero si ya tienes código sobre Interactions API, la prioridad es más directa: no trates steps como una renombrada cosmética; úsalo para observabilidad y pruebas de agentes largos.