Así opera el nuevo sistema de agentes de OpenAI

La novedad no llegó en forma de demo vistosa ni de benchmark con cifras deslumbrantes. Llegó, más bien, envuelta en un texto de ingeniería. OpenAI publicó el 11 de marzo un informe para explicar cómo está equipando su Responses API con un entorno informático gestionado y seguro, capaz de alojar agentes que ejecutan tareas de software de principio a fin. La pieza describe una arquitectura menos glamorosa que un nuevo modelo, pero probablemente más decisiva. Durante años, la industria vendió la idea de asistentes capaces de razonar. El problema real aparecía un minuto después, cuando había que darles un lugar donde operar, un historial que no se desbordara, acceso a archivos, herramientas para consultar datos y una forma de tocar internet sin convertir el sistema en una invitación al desastre.

Ese cuello de botella explica por qué tantos prototipos brillaban en una demo y se desarmaban al entrar en producción. Un modelo puede sugerir un comando o redactar una consulta, pero no ejecuta nada por sí mismo. Alguien tiene que correr ese comando, almacenar archivos intermedios, decidir qué hacer con la salida del terminal y reinyectar los resultados en el contexto hasta que la tarea termine. OpenAI sostiene que ese “alguien” ya no tiene por qué ser una maraña de código artesanal del lado del desarrollador. La Responses API, que la propia documentación recomienda para proyectos nuevos por encima de Chat Completions, empieza a presentarse como una capa unificada donde el modelo, las herramientas alojadas y el estado de la tarea conviven bajo el mismo techo.

El chat ya no alcanza

El informe lo expone sin maquillaje: el corazón del sistema es un bucle de agente. El modelo propone una acción, la plataforma la ejecuta y el resultado vuelve al modelo como insumo para decidir el siguiente paso. En el caso del shell tool, esa acción puede ser leer archivos, lanzar utilidades de Unix, hacer una petición a una API o transformar datos con herramientas estándar como grep, curl y awk. OpenAI remarca que, a diferencia de su code interpreter tradicional, limitado a Python, el shell alojado abre la puerta a flujos mucho más amplios, desde levantar un servidor NodeJS hasta correr programas escritos en Go o Java.

La diferencia parece técnica, pero es profundamente práctica. En un entorno real, la gracia no consiste en que el modelo escriba un bloque de código elegante, sino en que pueda moverse entre archivos, dependencias, salidas parciales y artefactos finales sin pedir auxilio a cada paso. Según el informe, los modelos GPT-5.2 en adelante ya fueron entrenados para proponer comandos de shell dentro de ese marco. La Responses API arma el contexto con la instrucción del usuario, el estado previo de la conversación y las reglas de la herramienta; luego reenvía los comandos al contenedor, transmite la salida en tiempo casi real y repite el ciclo hasta que el modelo deja de pedir más ejecución.

Ese detalle cambia el partido. El modelo no responde una sola vez y desaparece. Puede lanzar varias órdenes en paralelo, recibir flujos independientes y volver a decidir con nueva evidencia en la mano. También impone un límite de salida por comando, una poda deliberada que conserva el comienzo y el final del texto cuando el terminal produce demasiado ruido. Parece una minucia, pero ahí está una de las claves del diseño. El enemigo de los agentes no siempre es la falta de capacidad, sino el exceso de verborragia técnica. La guía de computer use muestra la misma filosofía en otro terreno: el modelo pide una captura, devuelve acciones sobre la interfaz y el sistema las ejecuta. La ambición, en ambos casos, es idéntica: pasar del chat a la operación.

La memoria, el cable y el archivo

Si la ejecución era el primer problema, la memoria era el segundo. Cualquier agente que trabaje durante varios pasos empieza a llenar la ventana de contexto con mensajes, salidas de herramientas, resúmenes de razonamiento y rastros de decisiones previas. Ese crecimiento encarece la tarea y la vuelve más frágil. OpenAI dice haber resuelto parte de ese atasco con compaction, un mecanismo nativo que comprime el historial antiguo en una representación más pequeña, preservando el estado relevante para los turnos siguientes. La plataforma ofrece dos modos: compactación del lado del servidor, activada con un umbral, y un endpoint específico para quien prefiera control explícito.

La idea es fácil de enunciar y difícil de ejecutar bien. Resumir una conversación larga sin amputar detalles importantes es una de las tareas donde más sistemas fallan. OpenAI sostiene que sus modelos recientes están entrenados para producir ese ítem de compactación en una forma cifrada y eficiente en tokens. En paralelo, la documentación de conversation state deja claro que la Responses API ya nació con obsesión por la continuidad: soporta previous_response_id, conversaciones persistentes y almacenamiento de contexto entre turnos. En otras palabras, no solo responde, también mantiene el hilo.

La otra mitad del taller es el espacio de trabajo. El informe describe el contenedor alojado como algo más que un sitio para correr comandos. Es el contexto operativo del modelo. Allí puede leer y ordenar archivos, consultar bases de datos y acceder a sistemas externos bajo políticas de red controladas. La empresa incluso recomienda una práctica sensata: dejar de incrustar planillas enteras en el prompt y mover la información estructurada a bases como SQLite, para que el agente consulte solo las filas que necesita. En vez de copiar montañas de datos al contexto, el sistema consulta, filtra y trabaja sobre material organizado.

Quedaba el punto más espinoso: la red. Darle a un agente acceso irrestricto a internet es una mala idea por razones muy concretas. Puede filtrar información, tocar servicios sensibles, exponer credenciales o disparar acciones donde no debería. La solución que describe OpenAI pasa por un proxy de salida lateral, una capa centralizada que fuerza listas de permitidos, controles de acceso y observabilidad del tráfico. Para las credenciales, la empresa habla de inyección de secretos por dominio en el momento de la salida: el modelo y el contenedor solo ven marcadores de posición, mientras que los valores reales quedan fuera del contexto visible y solo se aplican a destinos autorizados. Sin esa pieza, el agente es una demo. Con esa pieza, empieza a parecer un producto.

La carrera por el agente útil

Hay un último componente que completa la arquitectura y que quizá sea el más subestimado: las skills. OpenAI las define como paquetes reutilizables de archivos e instrucciones, organizados en torno a un SKILL.md y otros recursos de apoyo. La idea es evitar que el agente redescubra desde cero el mismo procedimiento cada vez que recibe una tarea parecida. En vez de improvisar un flujo nuevo para validar un dataset, preparar una entrega o navegar una interfaz interna, el sistema puede cargar una receta versionada, copiarla dentro del contenedor y usarla como guía de ejecución. No suena heroico. Suena industrial, que es exactamente el punto.

Esa insistencia en la reutilización revela algo más amplio sobre la dirección de OpenAI. La empresa ya no presenta sus modelos solo como motores de texto, imagen o voz, sino como núcleos de decisión incrustados en una infraestructura que absorbe orquestación, manejo de estado, acceso a herramientas, artefactos, archivos y seguridad operativa. En la guía oficial de migración, OpenAI afirma que Responses es la interfaz recomendada para nuevas integraciones y le atribuye ventajas concretas frente a Chat Completions, entre ellas mejor utilización de caché y costos potencialmente más bajos en pruebas internas. La consecuencia es evidente: la compañía quiere que la capa de producto se construya sobre su infraestructura agente, no sobre un mosaico externo que use sus modelos como una pieza intercambiable.

Por eso el informe importa más de lo que su tono sereno podría sugerir. El gran problema del sector no era demostrar que un modelo podía escribir un correo o resumir un PDF. Era conseguir que una máquina completara un flujo largo, con herramientas reales, sin perderse en sus propios rastros y sin obligar a cada empresa a inventar desde cero la infraestructura que lo hace posible. OpenAI cree haber encontrado una respuesta con forma de entorno administrado. Falta ver cuánto resiste fuera del laboratorio y dentro de sistemas corporativos llenos de permisos, procesos heredados y datos sucios. Pero la dirección del movimiento ya quedó a la vista: la próxima batalla no será solo por quién responde mejor, sino por quién ofrece el mejor lugar para trabajar.