OpenAI equipa Responses API con entorno de computadora | Keryc
Estamos en una transición clara: ya no basta con modelos que hacen bien tareas puntuales; ahora buscamos agentes que ejecuten flujos de trabajo completos. ¿Qué cambia? En vez de solo pedirle razonamiento a un modelo, le damos un entorno de computadora para que pueda ejecutar comandos, leer archivos, llamar APIs y generar artefactos útiles como hojas de cálculo o reportes.
Qué problema resuelve esto
¿Te ha pasado que terminas pegando tablas gigantes en un prompt o reescribiendo lógica de manejo de archivos cada vez? Eso pasa porque los modelos, por sí solos, solo proponen acciones; no las ejecutan. Los problemas prácticos son claros: ¿dónde guardo archivos intermedios?, ¿cómo evito sobrecargar el prompt?, ¿cómo doy acceso a la red sin abrir un agujero de seguridad?, ¿y qué pasa con timeouts y reintentos?
OpenAI no dejó todo eso en manos del desarrollador. Equiparon la Responses API con un entorno de computadora compuesto por: una herramienta de shell, un contenedor hospedado con sistema de archivos, almacenamiento estructurado opcional (por ejemplo SQLite) y controles de red. La idea: el modelo propone pasos y comandos; la plataforma los ejecuta de forma aislada y devuelve resultados al modelo en un bucle.
Cómo funciona el bucle de ejecución
El patrón básico es un bucle de ejecución cerrado: el modelo decide una acción (leer un archivo, hacer una petición), la plataforma la ejecuta y el resultado vuelve al modelo para el siguiente paso. La pieza más simple para verlo en acción es la herramienta de shell.
La herramienta de shell permite al modelo proponer comandos como grep, curl, awk, o iniciar servidores en NodeJS, Go o Java. Pero recuerda: el modelo propone comandos; quien los ejecuta es la plataforma.
La Responses API actúa como orquestador: cuando el modelo sugiere un comando, la API lo envía al contenedor, transmite la salida en streaming de vuelta al modelo y repite hasta que el modelo emite una respuesta final sin más comandos. Esto permite inspeccionar resultados casi en tiempo real y emitir comandos de seguimiento.
También puedes paralelizar trabajo: el modelo puede proponer varios comandos y la API ejecutarlos en sesiones de contenedor separadas. Cada sesión transmite su salida y la API mezcla esos flujos de forma estructurada para que el modelo razone sobre ellos.
Control de salidas y eficiencia de contexto
Los logs de consola pueden ser enormes y consumir el presupuesto de contexto. Para evitarlo, el modelo puede pedir un límite por comando. La Responses API devuelve un resultado acotado que preserva el principio y el final del output, por ejemplo:
text at the beginning ... 1000 chars truncated ... text at the end
Con ejecución concurrente y resultados acotados, el agente mantiene rapidez y foco: no se pierde entre montones de logs.
Mantener coherencia en sesiones largas: compaction
Los flujos largos llenan la ventana de contexto. ¿Cómo mantener lo importante sin cargar todo? La solución es la compaction nativa: los modelos analizan el estado previo y generan un ítem compactado que codifica lo esencial de forma eficiente y cifrada.
La Responses API puede compactar automáticamente en el servidor o mediante el endpoint /compact. Esto evita que tengas que construir resúmenes manuales y permite que los flujos multi-etapa sigan coherentes aun si exceden la ventana de entrada.
Archivos, bases de datos y acceso de red
El contenedor es el espacio de trabajo: tiene un sistema de archivos para subir y organizar recursos. En lugar de empacar todo en el prompt, subes datos al contenedor y el modelo decide qué abrir con ls, cat u otros comandos. Así trabajas con información organizada y eficiente.
Para datos estructurados, recomiendan usar bases como SQLite: describir las tablas al modelo y que él haga consultas precisas en vez de pegar una hoja completa. Es más rápido, más barato y escala mejor.
El acceso a la red se gestiona con un proxy de salida (sidecar). Todas las solicitudes salen por una capa de políticas centralizada con allowlists y controles. Las credenciales se inyectan con alcance por dominio: el modelo y el contenedor ven placeholders, mientras que los secretos reales permanecen fuera del contexto visible hasta que se apruebe la llamada. Esto reduce el riesgo de fugas y permite llamadas autenticadas seguras.
Skills: repetir sin replanear cada vez
Muchos flujos repiten los mismos pasos. Los agentes tendrían que redescubrirlos cada ejecución. Para eso existen las skills: carpetas empaquetadas con un SKILL.md (metadatos e instrucciones) y recursos de apoyo (especificaciones de API, scripts, assets).
El runtime sigue una secuencia determinista al cargar una skill:
Recuperar metadatos (nombre, descripción).
Descargar y desempaquetar el bundle en el contenedor.
Actualizar el contexto del modelo con la ruta y la metadata.
El modelo puede explorar la skill con ls y cat y ejecutar scripts dentro del mismo bucle de agente. Además, la plataforma ofrece APIs para versionar y gestionar skills.
Un ejemplo rápido en una frase
Con estas piezas, un solo prompt puede: descubrir la skill correcta, traer datos en vivo, transformarlos en estado local estructurado, consultar solo lo necesario y generar un archivo durable como una hoja de cálculo.
¿Y ahora qué? Para desarrolladores esto abre la puerta a agentes que no solo sugieren pasos sino que los ejecutan de forma repetible y segura. Para equipos, significa menos infraestructura casera para orquestar, resumir y asegurar workflows.
La apuesta es clara: movernos de un mundo donde los modelos devuelven texto a uno donde los agentes, apoyados en un entorno computacional controlado, resuelven tareas del mundo real.
