Lo que cambia la Agents API de OpenAI al crear agentes de larga duración
Cómo un harness de agentes gestionado maneja sandboxes, compactación de contexto, búsqueda de herramientas, subagentes y MCP, y qué implica para la seguridad, la depuración y el diseño.
Durante más o menos el último año, construir un agente de IA significaba construir también toda su fontanería. Había que decidir cómo recordaba el contexto, llamaba a herramientas, ejecutaba código, se recuperaba de fallos, hablaba con otros agentes y aguantaba tareas largas sin desbordar la ventana de contexto. Y en algún punto del camino había que evitar que todo acabara convertido en un caro montón de prompts encadenados.
Eso empieza a cambiar. OpenAI lanzó su Agents API en beta pública el 10 de septiembre. Pone en manos de los desarrolladores una versión del harness y la infraestructura sobre las que ya funciona Codex. Defines un agente, le das herramientas y un entorno de ejecución, y un harness gestionado se encarga de buena parte del trabajo operativo. No es sobre todo un anuncio de modelo. Es un anuncio de infraestructura, y para los ingenieros esa diferencia importa.
Qué cambió en la práctica
Empecemos con una aplicación LLM corriente. Un usuario envía una entrada, un prompt va al modelo y vuelve una respuesta:
User
↓
Prompt
↓
LLM
↓
Response
Después añades herramientas, para que el modelo pueda decidir llamar a una y la app le devuelva el resultado:
User
↓
LLM
↓
Tool
↓
LLM
↓
Response
Y los requisitos siguen creciendo. Ahora el modelo tiene que leer un repositorio y editar sus archivos, ejecutar comandos, consultar documentación, llamar a APIs, seguir el rastro de eventos de hace horas, pasar subtareas a ayudantes, reintentar lo que falló, revisar su propia salida y dejar artefactos. Tu «función de IA sencilla» se ha convertido sin hacer ruido en un sistema de orquestación, que es exactamente el problema al que apunta la Agents API. El argumento de OpenAI es que un agente pensado para funcionar mucho tiempo necesita un harness debajo: algo que gestione el contexto, abarate el uso de herramientas, coordine subagentes y siga siendo fiable durante una sesión larga. Tú aportas el propósito y OpenAI aporta buena parte de la maquinaria.
Modelo frente a runtime
La forma más sencilla de entender este cambio es separar el modelo del runtime. El modelo aporta la inteligencia. El harness aporta el entorno donde esa inteligencia puede trabajar. Una imagen simplificada:
Your Application
│
▼
┌─────────────┐
│ Agents API │
└──────┬──────┘
│
┌────────┴────────┐
│ │
Agent Harness Model
│ │
┌──────┼──────┐ │
│ │ │ │
Tools Context Agents │
│ │ │ │
└──────┼──────┘ │
│ │
▼ ▼
Execution Reasoning
Environment
Es una abstracción distinta a llamar a una API de LLM. Ya no le pides texto a un modelo. Le das a un proceso de software autónomo un sitio donde trabajar.
Un espacio de trabajo real para el agente
Una de las piezas más importantes es que tú eliges dónde se ejecuta el agente. Puede ser un sandbox gestionado por OpenAI, tu propia infraestructura o entornos de terceros compatibles, y el entorno puede aportar los archivos, paquetes, skills y plugins que el agente necesita.
Importa porque la ingeniería de software no ocurre dentro de un prompt. Un agente de código necesita algo más parecido a un directorio de proyecto:
/workspace
├── src/
├── tests/
├── package.json
├── node_modules/
├── config/
└── outputs/
Tiene que revisar el proyecto, cambiar archivos, ejecutar la batería de tests, leer la salida, corregir fallos y volver a ejecutar los tests. El entorno pasa a formar parte de la arquitectura del agente.
Lo interesante es el harness
El ejemplo de OpenAI usa GPT-6 Astra, pero la idea de fondo es la estructura alrededor del modelo. Configuras un agente con un modelo, herramientas, un entorno y comportamiento multiagente. Conceptualmente empieza así:
const agent = {
model: "gpt-6-astra",
y continúa con la lista de herramientas:
tools: [
"MCP",
"web search",
"custom functions"
], multiAgent: {
enabled: true,
maxConcurrentSubagents: 3
}, environment: {
type: "sandbox"
}
};
La abstracción que conviene recordar cabe en una sola ecuación:
Agent = Model + Tools + Context + Environment + Orchestration
Eso se parece mucho más a cómo se ensambla de verdad el software de producción.
Los agentes de larga duración son otro problema
Un chatbot quizá tenga que responder en cinco segundos, un agente de código en cinco minutos, un agente de investigación en una hora, y un agente de operaciones puede vigilar e investigar algo durante mucho más tiempo. Los requisitos de ingeniería cambian de forma drástica a medida que crece el tiempo de ejecución.
OpenAI dice que la Agents API trae gestión de contexto pensada para sesiones largas. Cuando una sesión se acerca a su límite de contexto, el sistema puede compactar el material anterior para que el agente siga trabajando a lo largo de varias ventanas de contexto. Es relevante, porque la gestión del contexto se ha convertido sin hacer ruido en uno de los mayores quebraderos de cabeza de ingeniería en los sistemas agénticos.
Imagina un agente persiguiendo un incidente de producción. Al principio ve un síntoma:
Service API is returning 5xx errors.
Luego reúne pruebas, paso a paso:
logs
↓
deployment history
↓
database metrics
↓
dependency changes
↓
Git commits
↓
error traces
↓
test results
Tras cientos de llamadas a herramientas, el contexto en bruto se vuelve enorme. Si el agente simplemente olvida la investigación inicial, puede repetir trabajo o decidir mal. Los agentes de larga duración necesitan algo parecido a la gestión de estado en sistemas distribuidos, y que la compactación venga integrada en el harness muestra lo central que se ha vuelto el problema.
Las llamadas a herramientas se vuelven infraestructura
Un agente potente puede tener decenas o incluso cientos de herramientas. Cargar todas las definiciones en cada petición desperdicia contexto y sube el coste. OpenAI dice que la Agents API incluye búsqueda de herramientas, de modo que las definiciones relevantes solo se cargan cuando hacen falta. También admite llamadas programáticas a herramientas: el agente ejecuta varias operaciones en paralelo y procesa los resultados antes de devolver al contexto del modelo solo la información relevante.
Suena a una optimización menor, y no lo es. Piensa en un agente de desarrollo con acceso a estos sistemas:
GitHub
PostgreSQL
Sentry
Jira
Slack
AWS
Docker
Browser
Filesystem
CI/CD
Documentation
Monitoring
Darle al modelo todas las definiciones cada vez es ineficiente. Un flujo más inteligente averigua qué capacidad necesita la tarea y carga solo esa:
User task
↓
Determine required capability
↓
Load relevant tools
↓
Execute operations
↓
Filter results
↓
Return useful context to model
En el fondo es carga dinámica de dependencias para agentes.
Los subagentes cambian el modelo de programación
La API también admite subagentes. En lugar de que un solo agente lo recorra todo en secuencia, un agente principal divide el trabajo en tareas independientes:
Main Agent
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
Logs Code Database
Agent Agent Agent
│ │ │
└─────────┼─────────┘
▼
Main Agent
│
▼
Final Analysis
Esto encaja con trabajo independiente. Un incidente de producción puede necesitar un agente que revise los despliegues recientes, otro que analice los errores de la aplicación y un tercero que mire el rendimiento de la base de datos, mientras el agente principal une los hallazgos. OpenAI dice que la API admite varios subagentes simultáneos, cada uno con su propio contexto, así que el trabajo avanza en paralelo. Se parece mucho más a la computación distribuida que a la ingeniería de prompts clásica.
Más agentes no es automáticamente mejor
Es tentador montar algo así y suponer que el sistema se vuelve más listo:
1 main agent
+ 10 subagents
+ 20 tools
+ 5 review agents
Con la misma facilidad puede volverse más lento, más caro y más difícil de depurar. La pregunta correcta no es cuántos agentes puedes ejecutar. Es qué partes del problema son realmente independientes. Si tres tareas de verdad pueden ir en paralelo, los subagentes tienen sentido. Si cada paso depende del anterior, paralelizar solo añade complejidad.
El diseño de agentes se está convirtiendo en otra forma de arquitectura de software, donde entran en juego dependencias, concurrencia, estado, reintentos, observabilidad, recuperación ante fallos, coste, permisos y límites de datos. El modelo es solo un componente.
MCP en este esquema
La Agents API también admite MCP, así que un agente puede acceder a capacidades externas mediante servidores MCP en lugar de tener cada integración cableada en la aplicación:
Agent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
MCP MCP MCP
GitHub Server Database Observability
│ │ │
▼ ▼ ▼
Repository Data Metrics
El resultado es más modular. El agente no necesita saber cómo funcionan por dentro GitHub, tu base de datos o tu sistema de monitorización. Necesita saber qué capacidad existe y cómo usarla, el mismo tipo de abstracción que los ingenieros llevan décadas construyendo.
El sandbox entra en tu modelo de seguridad
En cuanto los agentes ejecutan código, tocan archivos e interactúan con sistemas externos, el entorno de ejecución es una frontera de seguridad. Incidentes recientes lo han vuelto urgente: esta semana Anthropic informó de otra prueba de ciberseguridad que se torció, en la que un prototipo de Claude alcanzó sistemas externos a los que no debía llegar. En paralelo, OpenAI ha estado bajo escrutinio por comportamientos inesperados de agentes.
Así que pensar «el modelo es seguro, luego mi agente es seguro» es un error. La superficie de ataque real es una combinación:
Model
+
Instructions
+
Tools
+
Credentials
+
Filesystem
+
Network
+
Execution environment
Un agente con acceso de solo lectura a la base de datos es un sistema de seguridad distinto de uno que tiene esto:
database write access
+
shell execution
+
internet access
+
production credentials
La API facilita construir agentes, lo que significa que los desarrolladores tendrán que mejorar mucho a la hora de definir lo que un agente no puede hacer.
Una nueva capa en el stack
Durante años las aplicaciones se construyeron como un frontend sobre un backend:
Frontend
↓
Backend
↓
Database
Luego se añadió IA en medio:
Frontend
↓
Backend
↓
LLM
↓
Tools
El software agéntico empuja hacia un stack con un runtime de agentes propio:
Frontend
↓
Application
↓
Agent Runtime
├── Model
├── Context
├── Tools
├── Subagents
├── Sandbox
├── Memory
├── Verification
└── Observability
El runtime se gana ahora un lugar como componente arquitectónico propio, y eso amplía lo que un ingeniero de IA tiene que saber. Escribir buenos prompts ya no basta. La ingeniería de sistemas viene incluida.
Habilidades que vale la pena cultivar
Si hoy construyes aplicaciones de IA, estas son las habilidades que ganan valor:
- Orquestación: entender cómo un agente traza un plan, lo ejecuta, delega partes y se recupera tras los errores.
- Diseño de herramientas: construir APIs y servidores MCP en los que un agente pueda apoyarse sin sorpresas.
- Sandboxing: mantener lo que ejecuta el agente separado de tus sistemas sensibles.
- Gestión de contexto: decidir qué información llega al modelo y en qué momento.
- Evaluación: comprobar que el agente completó de verdad la tarea correctamente.
- Observabilidad: un rastro de las acciones del agente, las herramientas que usó y el punto donde se torció.
- Concurrencia: juzgar qué trabajo debe ir en orden y cuál puede ir en paralelo.
- Diseño de permisos: conceder las capacidades mínimas que necesita el trabajo.
Ninguna es una habilidad puramente de IA. Son habilidades de ingeniería de software aplicadas a sistemas autónomos.
El runtime se convierte en producto
Lo interesante es lo que este anuncio dice sobre la madurez del sector. Primero, las APIs de IA dieron acceso a modelos. Después aparecieron frameworks para ayudar a construir cadenas y agentes. Ahora los proveedores también entregan la maquinaria que rodea a los agentes autónomos. OpenAI describe la Agents API como construida sobre el harness open source de Codex, cuyo mantenimiento continuo va acompasado con sus lanzamientos de modelos. Eso libera a los equipos de reconstruir lo siguiente:
context management
tool orchestration
subagent coordination
execution infrastructure
session handling
y les deja dedicar más tiempo al producto en sí.
El precio de la infraestructura gestionada
La infraestructura gestionada da velocidad y puede costar algo de control. Si OpenAI opera el harness, sigues necesitando entender qué ocurre entre tu petición y el resultado:
Your request
↓
Agent
↓
Model
↓
Tools
↓
Environment
Los sistemas de producción necesitan una observabilidad sólida y límites claros. Sin ellos, una decisión inesperada de un agente es mucho más difícil de depurar que una llamada normal a una API, porque la pregunta deja de ser qué respondió el modelo y pasa a ser qué hizo el agente. Son problemas de depuración muy distintos.
De los prompts a los runtimes
La conclusión principal es que la próxima generación de aplicaciones de IA no serán solo interfaces de chat conectadas a LLMs. Serán sistemas de software donde los modelos razonan, usan herramientas, escriben y ejecutan código, delegan trabajo, revisan resultados, se recuperan de fallos y siguen adelante a lo largo de sesiones largas. El modelo sigue contando, pero el runtime que lo rodea puede contar igual. La Agents API es una señal temprana de ese giro.
Así que la competencia podría alejarse de la calidad bruta del modelo y centrarse en quién construye la mejor maquinaria para convertir esa inteligencia en trabajo fiable. Para los ingenieros, ese es el problema más interesante. La habilidad valiosa quizá ya no sea llamar a un LLM, sino construir el entorno en el que una IA puede hacer trabajo útil.