El 10 de septiembre, OpenAI lanzó la beta pública de la Agents API, «poniendo al alcance de los desarrolladores el mismo harness y la misma infraestructura que impulsan a Codex a través de una API sencilla y flexible». En el DevDay del 29 de septiembre sumó computer use, un equivalente nativo en AWS y un nuevo integrante: los dots siempre activos de ChatGPT, que funcionan sobre ese mismo harness de Codex.
Si eres un desarrollador creando un producto basado en agentes, son excelentes noticias: el harness que ibas a implementar a medias ahora es problema de alguien más. Pero si lo miras como un ingeniero cuyo equipo ya utiliza Claude Code y Codex en una base de código real, la perspectiva cambia por completo. La API responde a «¿cómo mantengo un agente en ejecución durante horas?», pero no responde a «¿cómo sabe mi equipo qué hicieron seis de ellos y quién aprobó el sitio web en el que uno acaba de iniciar sesión?». Sharkly se sitúa justo en esa segunda pregunta.
TL;DR
La Agents API aloja el harness de Codex: sesiones persistentes, compactación de contexto, búsqueda de herramientas, subagentes y un sandbox alojado en OpenAI, en tu propia infraestructura o en cualquiera de sus nueve partners, sin costos adicionales más allá de los tokens, el uso de herramientas y el tiempo de computación del contenedor. DevDay añadió computer use, donde tu aplicación aprueba cada nuevo origen de sitio web y cada inicio de sesión (la aprobación del origen no implica la confirmación de acciones individuales), así como Bedrock Managed Agents, que ejecuta sus capacidades principales dentro de AWS. Sin embargo, nada de esto gestiona la capa de equipo: quién asignó la tarea, qué agente la tiene a cargo, qué finalizó, qué falló y quién valida el resultado.
Qué es la Agents API y qué ejecuta OpenAI
La guía general de OpenAI resume la API en cuatro componentes esenciales. Un Agent es «el modelo, las instrucciones, las herramientas y los servidores MCP disponibles para el agente». Un Environment es «un sandbox u ordenador opcional donde el agente accede a archivos, carga habilidades y ejecuta comandos». Una Session es «una instancia duradera de un agente que trabaja en tareas y responde a entradas». Los Events and items representan las entradas que envías y las respuestas devueltas.
Creas una sesión con la configuración de un agente, le asignas una tarea una vez que el entorno está listo, monitoreas el proceso mediante streaming o webhooks y luego envías más tareas o indicaciones dentro de la misma sesión. Este es el ejemplo resumido de la documentación:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
Dos líneas concentran la mayor parte de las novedades: multi_agent habilita la distribución en abanico (fan-out) a subagentes con un límite de concurrencia, y environment.type define dónde se ejecuta el código: openai_hosted, self_hosted o en alguno de los sandboxes de sus partners (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
La documentación resume la división del trabajo en una sola frase: «OpenAI gestiona las sesiones, la orquestación, la compactación de contexto y la recuperación, mientras que tu aplicación proporciona las herramientas y define su entorno de ejecución».
| De qué se encarga OpenAI | Qué debes aportar tú |
|---|---|
| El bucle del agente: llamadas a modelos, uso de herramientas y reintentos | La tarea y la definición de terminado (definition of done) |
| Compactación de contexto cuando la sesión se acerca a su límite | Herramientas: servidores MCP, funciones y utilidades integradas |
| Búsqueda y carga de herramientas | Credenciales, mediante identificadores de bóveda (vault IDs) |
| Descomposición y coordinación de subagentes | Elección y configuración del entorno |
| Reanudación y redireccionamiento de la sesión | Todo lo que sucede después de que finaliza la sesión |
El uso del modelo se factura a las tarifas habituales de su API, las herramientas a tarifas estándar y los sandboxes alojados en OpenAI según el costo de los contenedores; el artículo de lanzamiento señala que «no hay cargos adicionales por utilizar la Agents API». La documentación establece con claridad dos limitaciones: la API «actualmente solo admite residencia de datos en Estados Unidos y no es compatible con Zero Data Retention (ZDR)», y optar por un sandbox autoalojado no la hace apta para ZDR. Si alguno de estos aspectos es crucial para el cumplimiento normativo de tu organización, migrar el sandbox internamente no cambia las cosas.
Novedades incorporadas en el DevDay
Computer use. Si añades la herramienta computer_use y habilitas un escritorio en un entorno alojado por OpenAI, el agente pasará a controlar un navegador en la nube. La guía de computer use estructura este flujo en torno a eventos de aprobación. El navegador solicita la aprobación del usuario antes de interactuar con cada nuevo origen web, incluidos sitios públicos. Los inicios de sesión llegan como solicitudes independientes que tu aplicación procesa para mostrar campos de correo, contraseña y código de verificación; las llaves de paso (passkeys) y el acceso mediante código QR no son compatibles, y solo el agente principal (no un subagente) puede solicitar credenciales. Hay una línea que conviene leer dos veces: «La aprobación de origen no exige confirmación previa para acciones individuales». Si se trata de compras o cambios potencialmente destructivos, la documentación recomienda restringir el navegador alojado a recursos que no puedan ejecutarlos, o emplear un entorno de ejecución de navegador bajo tu propio control. El resumen del DevDay incluye computer use «a través de la API y en Codex y ChatGPT Work en los planes Pro 500 y Enterprise».
Bedrock Managed Agents, con tecnología de OpenAI. OpenAI y Amazon tomaron «las capacidades principales de la Agents API» y añadieron personalizaciones para funcionar de manera nativa en AWS. La página de producto de AWS lo presenta en versión preliminar (preview) y aclara que tanto el entorno de ejecución del agente como la inferencia del modelo permanecen dentro de AWS, manteniendo cada agente su propia identidad y permisos en AWS.
Dots sobre el mismo harness. Decrypt informa que el harness de Codex «ahora impulsa los dots y es de código abierto». Los dots son los agentes siempre activos de ChatGPT, cada uno con su propio ordenador en la nube, y nuestro artículo explicativo sobre los dots analiza en detalle sus puntos fuertes.
De este modo, un único bucle ejecuta ahora un agente de programación, una sesión de API, un agente en AWS y un asistente siempre disponible. El harness está convergiendo. Los eventos de aprobación son la parte que impacta de lleno en el equipo: cada uno es una consulta dentro de una sesión concreta, respondida por quienquiera que mantenga su stream abierto. Cuando hay cinco sesiones haciendo preguntas al mismo tiempo, alguien tiene que decidir quién está autorizado a aprobar cada origen y dónde se registra esa decisión. Ese es un problema de puertas de aprobación (approval gates), y ya analizamos su variante en el entorno de Computer en las medidas de protección para computer use en GPT-6 Astra.
Lo que no resuelve: la capa de equipo
Una sesión solo es consciente de sí misma. No sabe que otras tres sesiones están modificando el mismo repositorio, ni que el resultado de una cuarta lleva sin revisarse desde el martes. Esos son problemas de gestión, y surgen en el instante en que más de una persona pone en marcha más de un agente.
Cinco interrogantes que la API deja abiertos, por diseño:
- ¿Quién asignó esta tarea y vinculada a qué ticket? Una sesión tiene un identificador y los metadatos que tu código decida incluir. Un responsable, un sprint o un enlace a la incidencia de origen solo existirán si tú los defines explícitamente.
- ¿Qué repositorio y qué rama modificó? El diff debe trasladarse a un espacio donde un revisor pueda examinarlo.
- ¿Qué terminó, qué falló y qué está en espera? Los eventos se transmiten en streaming mientras estás conectado o llegan mediante webhooks. Nada se acumula en una cola de resultados a la espera de intervención humana.
- ¿Quién aprueba el resultado? Un evento de aprobación cubre el acceso a un sitio web o un inicio de sesión, no la calidad del trabajo. «La sesión terminó» y «una persona evaluó la evidencia y dio su visto bueno» son el mismo evento a menos que construyas este último.
- ¿Qué ocurre con los agentes ajenos a OpenAI? Utilizar Claude Code para ciertas tareas y Codex para otras implica lidiar con dos modelos de sesión y dos lugares distintos donde buscar.
Es posible construir los cinco elementos sobre los eventos: un tablero, un webhook, un campo de estado, una columna de revisión. Pero luego alguien pregunta «¿llegamos a desplegar la corrección de la exportación?» y la respuesta se pierde en un historial de terminal que nadie guardó. Nuestro artículo sobre gestión de tareas para agentes de IA analiza las implicaciones de implementar esta solución por tu cuenta.
¿Subagentes dentro de una sesión o tareas en un tablero?
El parámetro max_concurrent_subagents es la respuesta de la API al paralelismo, y resulta excelente para el tipo de trabajo adecuado. Es el dilema del que hablamos cuando Codex aumentó su límite de subagentes a 64: los subagentes comparten un proceso padre, reportan sus hallazgos en una única respuesta consolidada y se evalúan como un solo resultado.
Utiliza subagentes dentro de una sesión cuando las tareas sean principalmente de lectura, independientes entre sí y solo importe la respuesta final combinada: investigar cuatro APIs, escanear una base de código en busca de un patrón determinado o recopilar información para el análisis de un incidente.
Utiliza tareas independientes cuando cada bloque escriba código que deba revisarse de forma individual: una migración, una nueva funcionalidad en un módulo o una corrección que toque un archivo compartido. En Sharkly, cada ejecución cuenta con su propio worktree de git aislado en un Computer bajo tu control, y cada resultado regresa a su propia tarea con su diff, su registro de ejecución y su revisor asignado. Agrupar cuatro cambios de escritura intensiva en el resumen de un único subagente equivale a esconder cuatro decisiones dentro de una sola.
Preguntas frecuentes
¿Con qué modelo funciona computer use? Los ejemplos de la documentación utilizan gpt-6-astra. Consulta la guía antes de asumir que otro modelo es compatible con la herramienta computer_use.
¿Ejecuta Sharkly sesiones de la Agents API? Sharkly ejecuta agentes de programación por CLI instalados en tus propios Computers, como Codex y Claude Code, a modo de runtimes. Las sesiones de la Agents API son un servicio gestionado en la nube, no un runtime instalado localmente, por lo que deben tratarse como una vía de ejecución independiente.
¿Dónde se lleva a cabo la revisión humana? En la Agents API, en el lugar donde decidas implementarla: los eventos de aprobación contemplan el acceso a sitios web y los inicios de sesión, no la aceptación del resultado final. En Sharkly, un agente puede dejar su tarea en espera de revisión humana, la solicitud llega a la bandeja de entrada de la persona responsable y un miembro del equipo actualiza el estado tras analizar la respuesta, el registro de ejecución y el diff.
El lugar que corresponde a cada capa
Una sesión persistente en la infraestructura de OpenAI es el elemento más práctico de este lanzamiento y, al mismo tiempo, el que mayor dependencia genera. Esto es crucial para un equipo de ingeniería, ya que el agente de programación más competente es un objetivo en constante evolución; un equipo cuyos estados de revisión y reglas de asignación residen en el almacenamiento de sesiones de un único proveedor se verá obligado a reconstruir su flujo de trabajo cada vez que cambie el modelo líder del mercado.
Si estás desarrollando un producto o servicio de backend impulsado por agentes, la Agents API es la capa adecuada, y Bedrock Managed Agents representa la misma alternativa para equipos que operan dentro del ecosistema de AWS. Obtienes el harness sin tener que mantenerlo y sandboxes sin necesidad de aprovisionarlos. Es muy probable que ni siquiera necesites un tablero de tareas: tu propia aplicación actúa como tal.
En cambio, si tus agentes funcionan como compañeros de equipo en tu propia base de código —lanzados por personas, revisados por personas e integrados a través de tus repositorios y sistemas de seguimiento habituales—, la ecuación cambia. Codex y Claude Code se encargan de la ejecución. Sharkly gestiona a nivel de equipo la asignación, los Computers conectados, el contexto de las tareas, el progreso, los bloqueos, los resultados y la revisión humana en todas esas herramientas. No sustituye a ninguno de estos runtimes ni a la Agents API. Esta misma cuestión sobre dónde ubicar cada componente se aplica también al propio Codex, tema que abordamos en Codex en la nube frente a tus propios Computers.
Alquila el harness si estás creando un agente. Mantén la capa de gestión bajo tu control y neutral respecto al proveedor si lo que estás haciendo es coordinarlos.
Si ya utilizas varios agentes en paralelo, Sharkly te ofrece un único espacio para coordinar sus tareas y resultados. Sharkly no vende tokens: el consumo de modelos se sigue facturando a través de las suscripciones o claves de API configuradas en las herramientas que conectes.
