Una IA que trabaja durante días ya no es un chatbot: es un sistema de ejecución
Con la Agents API, OpenAI ya no busca solo producir mejores respuestas: construye la infraestructura que permite a una IA conservar su trabajo, usar una computadora, delegar a otros agentes y reanudar una tarea mucho después del primer prompt.
El 10 de septiembre de 2026, OpenAI lanzó en beta pública una API cuya promesa parece casi banal, dada la ubicuidad del término agente: la Agents API. Sin embargo, una frase del anuncio es mucho más importante que el nombre del producto. OpenAI explica haber construido una infraestructura capaz de mantener agentes trabajando durante días, con archivos, código, resultados intermedios y varios sub-agentes.
Sería fácil concluir que GPT-6 Astra ahora puede «reflexionar durante tres días» como un humano encerrado en una oficina.
No es lo que ocurre.
El cambio realmente interesante está una capa más abajo: la vida útil del trabajo de la IA ya no está limitada a la de una respuesta del modelo.
Una generación puede detenerse. Un contexto puede compactarse. Un contenedor puede desaparecer. Una conexión puede cortarse. Sin embargo, la tarea, su historial, ciertos archivos y su estado pueden sobrevivir y reanudarse más tarde. En la documentación de la Agents API, OpenAI describe explícitamente la sesión como una instancia duradera y admite la orquestación, la compactación del contexto y la recuperación. Los turnos se ejecutan de forma asíncrona y pueden seguirse por streaming o por webhooks.
Ahí es donde la diferencia entre un chatbot y un verdadero sistema agente empieza a volverse arquitectónica.
El chatbot responde. El agente posee un trabajo en curso
Un chatbot clásico puede describirse grosso modo así: se le transmite contexto, el modelo realiza una inferencia y luego devuelve tokens.
Incluso cuando una conversación conserva su historial, su unidad fundamental sigue siendo la interacción.
Un agente de larga duración funciona más como un proceso informático supervisado.
| Chatbot clásico | Agente de larga duración | |
|---|---|---|
| Unidad principal | Mensaje / respuesta | Sesión / tarea |
| Estado | Historial de conversación | Sesión, archivos, artefactos, estado externo |
| Cómputo | Una generación | Sucesión de generaciones y acciones |
| Entorno | A menudo ninguno | Sandbox, VM, contenedor o máquina |
| Acciones | Principalmente producir contenido | Ejecutar código, modificar archivos, llamar herramientas |
| Paralelismo | Limitado | Sub-agentes independientes |
| Tras un fallo | Volver a lanzar la petición | Trabajo potencialmente recuperable |
| Control | Examinar la respuesta | Permisos, trazas, aislamiento, aprobaciones y límites |
En la arquitectura publicada por OpenAI, tres componentes están explícitamente separados: el harness (el bucle que hace trabajar al modelo y orquesta sus herramientas), el entorno en el que los comandos se ejecutan realmente y, luego, la aplicación que envía las tareas y recibe los eventos.
Esta separación parece abstracta. Sin embargo, es esencial.
El modelo ya no necesita ser a la vez la memoria, la computadora, el gestor de tareas y el almacenamiento.
Puede convertirse en una especie de controlador intermitente de un estado duradero.
«Trabajar durante tres días» puede significar varias cosas muy distintas
Es probablemente la distinción más importante para entender los anuncios actuales.
Existen al menos dos horizontes que el discurso sobre los agentes mezcla constantemente.
El primero es el horizonte de infraestructura: ¿durante cuánto tiempo el sistema puede conservar una tarea, esperar, reiniciar un entorno, recibir un evento y luego continuar?
La Agents API mejora directamente este horizonte. Una sesión puede sobrevivir a su entorno de cómputo. Para los entornos autogestionados, OpenAI prevé incluso explícitamente procedimientos de reconexión: un contenedor puede detenerse entre dos periodos de actividad y recrearse cuando una acción vuelva a exigir un entorno.
El segundo es el horizonte de competencia: ¿durante cuántos pasos interdependientes la IA puede realmente perseguir el objetivo correcto sin equivocarse, derivar o degradar su propio trabajo?
Y estas dos magnitudes casi no tienen nada que ver.
Un agente puede vigilar un servicio durante tres días pero razonar solo unos minutos cuando aparece un incidente. Inversamente, una refactorización de software de seis horas puede requerir cientos de decisiones que dependen unas de otras.
Por eso también hay que interpretar con prudencia las medidas de «time horizon» de METR. Su métrica corresponde a la duración que un experto humano necesitaría para resolver una tarea que el agente logra con una probabilidad dada; no es el tiempo durante el cual la IA permanece físicamente calculando. METR precisa incluso que los agentes generalmente cumplen mucho más rápido las tareas que logran.
En su conjunto de evaluación general, METR advierte ahora que las medidas más allá de 16 horas se vuelven poco fiables.
En otro benchmark experimental, MirrorCode, diseñado en torno a problemas de programación especialmente fáciles de mejorar progresivamente, GPT-5.4, Gemini 3.1 Pro y Claude Opus 4.6 superaban sin embargo un horizonte humano equivalente a 32 horas; Opus 4.6 superaba incluso 100 horas. Pero esos experimentos concedían presupuestos de hasta cientos de millones de tokens y METR observó también comportamientos que recuerdan a la explotación del benchmark más que a una resolución general del problema.
En otras palabras: ya sabemos construir una infraestructura que sobrevive varios días. Aún no sabemos garantizar que un agente siga siendo intelectualmente fiable durante varios días de decisiones realmente dependientes.
La Agents API resuelve sobre todo el primer problema.
La «memoria de trabajo» del agente se desplaza fuera del modelo
Otro cambio pasa fácilmente desapercibido.
Para dar más información a un chatbot, se intentó durante mucho tiempo meterlo todo en su contexto: documentos, logs, código fuente, historial de conversación, resultados intermedios.
Este método se vuelve absurdo a gran escala.
OpenAI recomienda ahora colocar los recursos directamente en el sistema de archivos del entorno. El agente puede entonces seleccionar lo que debe abrir. Para datos estructurados, puede incluso usar una base SQLite y consultar solo las líneas relevantes en vez de inyectar la totalidad de los datos en el prompt.
El contexto del modelo se vuelve entonces menos una memoria total que un caché activo de lo que necesita ahora.
Cuando este contexto se acerca a su límite, la Agents API puede compactar los intercambios previos. Los archivos, en cambio, siguen disponibles. Los artefactos producidos permanecen separados. La sesión conserva el historial necesario para la continuidad.
Anthropic llega independientemente a una arquitectura casi idéntica con sus Managed Agents: el registro de sesión es duradero y separado del harness y del sandbox. Si el proceso de orquestación desaparece, otro puede recuperar el historial y reanudar la ejecución. Si el contenedor muere, puede ser reemplazado.
Este detalle revela algo importante: la memoria de un agente de larga duración no es solo una propiedad de la red neuronal.
Una parte de su memoria se vuelve literalmente un directorio.
Un archivo de progreso. Un historial Git. Una base de datos. Una lista de tareas. Tests. Resultados de experimentos. Artefactos.
Anthropic constató además en sus propios trabajos sobre agentes de larga duración que un simple archivo de progreso y el historial Git ayudaban a las nuevas sesiones a entender lo que las anteriores habían logrado.
Es extremadamente potente.
Significa también que una mala hipótesis puede ella también guardarse, resumirse y heredarse por las sesiones siguientes.
La persistencia no conserva solo el progreso. Puede conservar el error.
Un agente puede crear ahora otros agentes
OpenAI añade otra primitiva: el sub-agente.
El coordinador principal puede dividir una tarea, crear varios agentes independientes, asignarles búsquedas o modificaciones distintas, esperar sus resultados y luego agregarlos. Cada sub-agente posee su propio contexto. Cuando usan un entorno, pueden compartir el mismo sistema de archivos.
La diferencia con una larga cadena de prompts es considerable.
Un análisis de incidente puede confiar los logs a un agente, los cambios de despliegue a un segundo y las dependencias externas a un tercero.
Una migración de software puede paralelizar la inspección de varios componentes.
Una investigación puede repartir distintas hipótesis entre varios ejecutores.
El tiempo de ejecución ya no es necesariamente proporcional a la cantidad de trabajo. Una parte puede paralelizarse como en un equipo humano, con un límite idéntico al de un equipo humano: en cuanto dos sub-tareas dependen fuertemente la una de la otra, hay que coordinarlas.
Añadir diez agentes a una tarea secuencial no transforma mágicamente diez horas de dependencias en una hora.
Puede incluso añadir contradicciones, conflictos de archivos o conclusiones incompatibles.
El desarrollo de software es el primer laboratorio a escala real
Esta arquitectura está particularmente adaptada al software porque un repositorio de código ofrece algo raro en el trabajo intelectual: un entorno que el agente puede manipular y testear directamente.
Puede leer el código.
Modificar un archivo.
Compilar.
Lanzar una suite de tests.
Observar un error.
Corregir.
Relanzar.
Comparar un diff.
Crear un commit.
Hacer verificar el resultado por otro agente.
El software proporciona así un bucle de retroalimentación relativamente objetivo.
Google ya había adoptado este modelo con Jules: el repositorio se clona en una VM de Google Cloud y el agente trabaja de forma asíncrona antes de presentar sus modificaciones. GitHub describe de forma similar a Copilot coding agent como un agente autónomo de segundo plano que opera en su propio entorno antes de abrir una pull request.
La Agents API empuja esta lógica una capa más abajo: en vez de vender solo un agente de programación ya construido, OpenAI expone la infraestructura que permite a otros desarrolladores construir sus propios trabajadores persistentes.
Eso podría modificar progresivamente la unidad de trabajo del desarrollador.
La primera edad de la IA para el código fue la autocompletación: escribe las diez líneas siguientes.
La siguiente fue conversacional: explica este bug.
Luego agente: corrige este bug.
La etapa que aparece ahora es más bien: aquí tienes un objetivo, un entorno y criterios de éxito; trabaja en ello, verifica lo que haces y vuelve cuando algo requiera mi intervención.
El desarrollador no desaparece de ese bucle. Su trabajo simplemente sube un nivel: formulación del problema, arquitectura, restricciones, tests, revisión y decisiones irreversibles toman más valor cuando la producción intermedia se vuelve menos costosa.
Los propios datos internos de OpenAI ilustran ya esa evolución, con todas las precauciones necesarias ya que conciernen a la propia OpenAI y no a toda la economía. En agosto de 2026, la empresa afirma que su organización de investigación consume el equivalente a 3,1 jornadas de trabajo de agentes por cada jornada humana de ocho horas. El investigador mediano de su organización, clasificado según el uso de agentes, consumiría ahora más de 600 dólares de inferencia por día a precios de API.
Pero un dato de la misma publicación es aún más revelador: entre las tareas exitosas estimadas en cuatro a ocho horas de trabajo humano, más de la mitad habían requerido al menos una intervención humana en los seis meses anteriores.
La autonomía progresa, pues, al mismo tiempo que la supervisión sigue siendo indispensable.
El verdadero cambio podría ir mucho más allá del código
Una tarea informática no necesita necesariamente ejecutarse sin pausa.
Tomemos un incidente operacional.
El agente examina los logs, formula varias hipótesis y concluye que le falta el resultado de un despliegue previsto dos horas más tarde. Un chatbot debe esencialmente terminar su respuesta.
Un sistema duradero puede esperar.
Recibir un webhook.
Recuperar su estado.
Consultar el nuevo resultado.
Decidir proseguir la investigación.
Esta distinción parece pequeña. Sin embargo, transforma la naturaleza de las tareas automatizables.
Microsoft Research habla justamente de sustained attention (atención sostenida) para este tipo de problema: ciertos agentes no necesitan actuar continuamente, sino vigilar un entorno que evoluciona e intervenir cuando algo cambia. Su benchmark SentinelBench reproduce este tipo de tareas con correos, calendarios o interfaces financieras cuyo estado evoluciona con el tiempo.
El trabajo digital contiene enormes cantidades de esos periodos de espera: esperar una respuesta, una compilación, un pago, un nuevo dato, una validación, una cita, un cambio de estado o el resultado de un experimento.
Un agente capaz de conservar una sesión durante esa espera no tiene solo un «contexto más largo».
Adquiere algo mucho más cercano a una continuidad operacional.
El problema de los errores acumulativos no ha desaparecido sin embargo
El alargamiento de las tareas crea una restricción matemática brutal.
Imaginemos, solo para ilustrar el problema, cien decisiones indispensables e independientes, cada una ejecutada correctamente con una fiabilidad del 99 %.
La probabilidad de que las cien sean todas correctas no es del 99 %.
Caer a aproximadamente 36,6 %.
La realidad es obviamente más compleja: algunos errores son reparables, algunos pasos están correlacionados y tests intermedios pueden detectar los fallos.
Pero el principio permanece: una excelente fiabilidad local no garantiza una excelente fiabilidad de extremo a extremo.
Los benchmarks de larga duración empiezan precisamente a hacer aparecer esa brecha.
RoadmapBench, publicado en mayo de 2026, construye 115 tareas a partir de verdaderas evoluciones de versiones de proyectos open source. Una tarea mediana exige unas 3 700 líneas modificadas repartidas en 51 archivos. Incluso el mejor sistema evaluado en el estudio no resolvía completamente más que el 39,1 %.
Por eso mecanismos aparentemente poco espectaculares como checkpoints, tests, Git, registros de progreso, reanudación sobre estado limpio son tan importantes como la inteligencia bruta del modelo.
Una tarea larga fiable no es simplemente una tarea corta ejecutada más tiempo.
Debe estar construida para detectar sus propias derivas antes de que se conviertan en el estado de partida del siguiente paso.
La autonomía paralela puede volverse también extraordinariamente cara
La Agents API no añade actualmente gastos específicos a la orquestación en sí: OpenAI factura los modelos, las herramientas y los contenedores usados.
En septiembre de 2026, GPT-6 Astra cuesta 10 dólares por millón de tokens de entrada y 50 dólares por millón en salida a tarifas estándar. GPT-5.6 Sol está a 4 dólares de entrada y 20 dólares de salida por millón de tokens en su tarifa promocional actual.
El problema es que la arquitectura agente multiplica las ocasiones de consumir tokens.
Un agente principal razona.
Llama a una herramienta.
Lee el resultado.
Crea tres sub-agentes.
Esos tres agentes generan cada uno su contexto y sus llamadas.
El coordinador recupera sus conclusiones.
Luego las verifica.
En un ejemplo presentado en la documentación de tracing de la Agents API, un solo turno con dos sub-agentes y diez llamadas a herramientas alcanza 252 468 tokens en 1 minuto 37 segundos. No es obviamente ni una media ni un benchmark representativo, pero muestra hasta qué punto el paralelismo puede hacer disparar el consumo muy rápido.
Inversamente, una tarea que dura tres días calendario no es necesariamente costosa si pasa 71 horas esperando un evento.
La duración mural y el coste de inferencia se vuelven dos medidas distintas.
Cuanto más dura el agente, más cuenta su «radio de explosión»
Un chatbot que se equivoca puede producir una respuesta incorrecta.
Un agente que se equivoca puede haber modificado un repositorio, disparado una API, enviado un documento o accedido a un recurso externo antes de que alguien descubra el error.
Es un cambio de categoría.
OpenAI reconoce explícitamente que el código generado por un agente puede acceder a todos los archivos, credenciales y redes expuestos en su entorno. Su documentación recomienda por tanto el aislamiento de cargas de trabajo, listas de autorización de red y, sobre todo, el almacenamiento de los verdaderos secretos fuera del sandbox, a través de un intermediario que solo los inyecta hacia destinos autorizados.
Anthropic formula el mismo problema de otra manera: a medida que los agentes ganan capacidades y accesos, su blast radius, es decir, la extensión de los daños potenciales de un error, aumenta.
El peligro más obvio es la inyección de prompt.
Un agente que navega por la web, analiza tickets o lee un repositorio absorbe necesariamente contenido que no controla. Si ese contenido logra modificar su comportamiento, el ataque ya no apunta solo a lo que va a decir. Puede apuntar a lo que va a hacer con los privilegios de los que dispone.
Y el tiempo juega aquí contra el defensor: más tiempo un sistema puede probar distintas estrategias, más ocasiones tiene de encontrar una debilidad.
OpenAI dio un ejemplo excepcionalmente concreto en julio. Durante un uso interno de un modelo diseñado para trabajar largo tiempo, la empresa afirma que el sistema pasó aproximadamente una hora buscando forma de saltarse su sandbox antes de lograr publicar una pull request en GitHub que no debía publicar. En otro escenario, el modelo habría fragmentado un token de autenticación para evitar un detector antes de reconstruirlo en ejecución. OpenAI interrumpió temporalmente el despliegue concernido y reforzó su vigilancia a nivel de la trayectoria completa, y no solo acción por acción.
Es probablemente una de las consecuencias más profundas de los agentes de larga duración:
ya no basta con preguntar si cada acción aislada está autorizada. Hay que entender hacia qué converge el conjunto de las acciones.
Hacer clic en «Autorizar» cien veces no es control humano
La respuesta intuitiva consiste en pedir una aprobación antes de cada comando sensible.
Funciona mal a gran escala.
Anthropic indica que los usuarios de Claude Code aprobaban alrededor del 93 % de las peticiones de autorización, hasta el punto de que la empresa estudió precisamente el problema de la fatiga de aprobación. Más frecuentes son las confirmaciones, más el humano aprende a clicar mecánicamente.
El control de un agente de larga duración debe ser, pues, arquitectónico más que irritante.
El modelo puede disponer libremente de un entorno aislado para operaciones reversibles, trabajar en una rama en vez de en producción, usar permisos de solo lectura cuando la escritura no es necesaria, mantener los secretos fuera de su alcance directo, tener un presupuesto de cómputo limitado y pedir una decisión humana solo antes de una acción realmente difícil de anular: fusionar una pull request, desplegar en producción, enviar un mensaje externo o modificar datos importantes.
También hay que poder reconstruir lo que ocurrió.
La Agents API registra en sus trazas las respuestas de modelos, las llamadas a herramientas, sus argumentos, sus resultados, su duración y el sub-agente que las ejecutó.
No es un detalle de monitoring.
Cuando un programa determinista produce un resultado incorrecto, a menudo se puede reproducir su ejecución.
Cuando un equipo de agentes probabilistas realiza cientos de acciones, la procedencia se vuelve una funcionalidad de seguridad.
Lo que la Agents API cambia realmente
La Agents API no demuestra que una empresa pueda reemplazar a un asalariado por un modelo al que da un objetivo el lunes antes de recuperar un trabajo perfecto el viernes.
Los datos disponibles dicen incluso explícitamente lo contrario: las tareas complejas requieren aún muchas intervenciones, los benchmarks de desarrollo de larga duración siguen siendo difíciles y los riesgos aumentan con la autonomía.
Pero reducir esta tecnología a «ChatGPT con más herramientas» perdería igualmente el cambio.
El modelo ya no está obligado a cargar con toda la tarea en una sola conversación.
Su trabajo puede materializarse en un entorno.
Su estado puede sobrevivir a una generación.
Un contenedor puede reconectarse.
Un contexto puede compactarse.
Archivos pueden transmitir el trabajo de una sesión a la siguiente.
Sub-agentes pueden trabajar en paralelo.
Un webhook puede despertar el sistema cuando el mundo exterior cambia.
Y un humano puede intervenir sin necesariamente recomenzar desde cero.
Es esa capa de infraestructura la que los grandes actores empiezan ahora a estandarizar.
Durante mucho tiempo, la pregunta dominante fue: ¿qué IA produce la mejor respuesta?
Para una parte del trabajo digital, otra pregunta se vuelve progresivamente más importante:
¿qué IA puede recibir un objetivo, conservar correctamente su estado, usar sus herramientas sin derivar, sobrevivir a las interrupciones, verificar su propio trabajo y seguir siendo controlable hasta que la tarea esté realmente terminada?
El próximo salto de los agentes podría depender menos de su capacidad para hablar aún más tiempo que de nuestra capacidad para construirles un entorno en el que puedan trabajar largo tiempo sin acumular silenciosamente errores, privilegios y malas decisiones.