La Agents API de OpenAI ya puede revisar las acciones de tu agente. Viene apagada por defecto, y el presupuesto viene sin límite
By Surya Pratap
1 de noviembre de 2026
7 min read
AI & Technology
1 de noviembre de 2026
7 min read
Ver los cuatro valores por defectoHover to exploreDos días después de que OpenAI publicara un Model Spec que pide a los agentes mantenerse dentro de un alcance acordado, su SDK de Python incluyó un ajuste que traslada parte de ese trabajo a la plataforma. La versión 3.42.0, publicada el 31 de octubre de 2026, permite activar la revisión automática de las acciones de un agente en la Agents API. También te deja elegir cómo se compacta el contexto del agente y le da una noción experimental del tiempo. Nada de esto llegó a los titulares. Para los fundadores que ejecutan agentes sobre esa API, lo más útil no son las novedades, sino que la referencia dice con claridad qué hace cada una cuando la omites.
Este artículo se basa en la versión 3.42.0 de openai-python y en la referencia de la API que la acompaña, leída por completo en lo que toca a los ajustes de sesión y de agente de la Agents API; las citas proceden de esa referencia. La Agents API está en beta. La interpretación a partir de la sección 3 es mía.
La versión enumera diez novedades. Tres de ellas cambian cómo se comporta una sesión de agente:
review con dos valores, none y auto_review.compaction que elige entre compactación en segundo plano y bloqueante.experimental.time_awareness que da al modelo «recordatorios periódicos de la hora actual».La misma versión añade también la gestión de claves externas a nivel de organización y el aislamiento de las claves de API por petición, algo que importa a los equipos de seguridad pero que no cambia el comportamiento del agente. Hay un cuarto ajuste relevante que ya existía: spend_control, un límite de gasto por sesión en céntimos de dólar.
La referencia describe cada modo de revisión en una línea. none mantiene «el comportamiento de ejecución existente sin revisión automática de acciones». auto_review sirve para «revisar automáticamente las acciones elegibles» y «denegar el recurso a la aprobación manual».
Hay tres detalles que importan. Primero, si omites el campo, obtienes none. Segundo, puedes cambiar el modo de revisión de la sesión más adelante, pero el cambio es la revisión por defecto «para los nuevos turnos raíz»: los turnos existentes y sus subagentes conservan su modo. Un turno que ya está en marcha, y cada subagente que haya lanzado, siguen como estaban. Tercero, el objeto de sesión devuelve el modo, y lo omite cuando el modo es none.
La referencia no dice qué acciones son «elegibles», contra qué las comprueba el revisor, qué modelo hace la revisión ni si revisar tiene coste. Hoy, la única solicitud de aprobación que una sesión puede devolver a tu aplicación es una solicitud de uso del ordenador, como permitir que un navegador abra un nuevo origen o inicie sesión. Tal como leo «denegar el recurso a la aprobación manual», activar auto_review significa que una acción que habría esperado a que tu aplicación la aprobara se deniega. Es un valor sensato para un agente que trabaja sin supervisión. También es un cambio de comportamiento que tus usuarios notarán, así que pruébalo antes de depender de él.
El nuevo ajuste decide quién revisa las acciones de tu agente. Omitirlo también decide: nadie, salvo tu propio código.
Toda ejecución larga de un agente acaba superando su ventana de contexto, y el harness resume el contexto antiguo para continuar. En septiembre escribimos sobre modelos que escribían instrucciones en esos resúmenes. Ahora puedes elegir cuándo se hace el resumen.
La compactación en segundo plano es el valor por defecto, y la referencia le añade una advertencia: la compactación en segundo plano «puede aumentar el uso de tokens». Pon async en false y la compactación pasa a ser bloqueante. La referencia no cuantifica los tokens extra. Si cobras a tus clientes por tarea o trabajas con márgenes estrechos, mídelo con tus propias cargas antes de aceptar el valor por defecto.
La conciencia del tiempo viene apagada y marcada como experimental: estas funciones «pueden cambiar». Resuelve un problema real. Un agente que lleva horas trabajando, o que se retoma al día siguiente, no sabe cuánto tiempo ha pasado si nada se lo dice. Si tu agente trabaja con plazos, horario laboral o cualquier latest_time en su alcance, merece la pena probar este indicador. Mientras siga siendo experimental, sigue comprobando los plazos también en tu propio código.
El patrón es el mismo para los cuatro: fija cada valor de forma explícita al crear la sesión, luego lee los valores efectivos en el objeto de sesión y regístralos junto a la ejecución. Todos los nombres de campo de abajo vienen de la referencia de la 3.42.0; el nombre del modelo y las instrucciones son de ejemplo.
from openai import OpenAI
client = OpenAI()
session = client.beta.agents.sessions.create(
environment={"type": "none"},
agent={
"model": "YOUR_MODEL",
"instructions": "Chase overdue invoices. Never change payment details.",
"compaction": {"async_": False},
"experimental": {"time_awareness": True},
},
review="auto_review",
spend_control={"limit": 500}, # USD cents
metadata={"workflow": "invoice-chasing"},
input="Chase this week's overdue invoices.",
)
effective = {
"review": session.review or "none",
"spend_limit_cents": session.spend_control.limit if session.spend_control else None,
"compaction_async": session.agent.compaction.async_ if session.agent.compaction else None,
"time_awareness": session.agent.experimental.time_awareness if session.agent.experimental else None,
}
assert effective["review"] == "auto_review"
assert effective["spend_limit_cents"] == 500
No confíes nunca en un campo omitido. La referencia es explícita: si omites review obtienes none, y si omites spend_control la sesión no tiene límite. Escribe ambos en el código, aunque el valor que quieras sea el de por defecto.
Registra lo que devuelve la sesión. Los valores que importan son los que la API dice que están en vigor, no los que pretendías enviar. Guárdalos con la ejecución, para que la revisión de un incidente empiece por los hechos.
Decide quién gestiona una denegación. Con auto_review, algunas acciones se rechazarán en lugar de llegarte a ti. Tu producto necesita un mensaje claro para el usuario y una forma de repetir el paso con la aprobación de una persona.
Cambia los ajustes entre turnos. Un nuevo modo de revisión solo se aplica a los nuevos turnos raíz. Para endurecer un agente en marcha, detén el turno, actualiza la sesión y vuelve a empezar.
El límite de gasto es el primero que yo fijaría. El ejemplo de presupuesto del Model Spec muestra que OpenAI trata un presupuesto como un techo. La Agents API te da un campo para imponerlo, y una sesión sin límite si lo omites.
Artículos anteriores relacionados
El viernes analizamos el alcance de autonomía del Model Spec: herramientas permitidas, un plazo y un presupuesto, impuestos por tu harness. En septiembre explicamos qué ejecuta la Agents API por ti y qué no, incluido dónde está disponible. Los ajustes de esta versión son los primeros controles de plataforma que encajan con ese alcance.
Que auto_review haga seguro a un agente. La referencia no dice qué comprueba el revisor. Trátalo como una capa más, no como sustituto de tus propios límites sobre herramientas, destinatarios y dinero.
Que la compactación bloqueante sea siempre la mejor opción. La única contrapartida declarada es que la compactación en segundo plano «puede aumentar el uso de tokens». Mídelo antes de cambiar un valor por defecto.
Que la conciencia del tiempo esté lista para producción. Está marcada como experimental, y la referencia dice que estas funciones pueden cambiar.
Que estos ajustes existan fuera de la Agents API. Pertenecen a las sesiones de agente gestionadas de OpenAI, que siguen en beta. Si ejecutas tu propio harness sobre otra API u otro modelo, tienes que construir esos mismos controles tú.
La versión 3.42.0 del SDK de Python de OpenAI añadió tres ajustes a la Agents API: un modo de revisión automática de acciones que deniega el recurso a la aprobación manual, la elección entre compactación de contexto en segundo plano o bloqueante, y un indicador experimental de conciencia del tiempo. Si los omites, no tienes revisión automática, la compactación va en segundo plano y puede gastar más tokens, y no hay recordatorios de la hora. Junto a ellos, un campo más antiguo te da un presupuesto sin límite si no fijas uno.
Nada de esto está oculto; la referencia lo dice con claridad. El riesgo no es que OpenAI haya elegido malos valores por defecto. Es que un equipo que nunca fijó estos campos no puede decir qué tienen permitido hacer sus agentes.
Esta semana, abre el código que crea tus sesiones de agente y escribe los cuatro ajustes de forma explícita. Después registra los valores que devuelve la sesión y compáralos con lo que creías estar ejecutando.
Fuentes: OpenAI, notas de la versión 3.42.0 de openai-python (31 de octubre de 2026) — la lista de novedades, incluidos los ajustes de compactación del contexto del agente, la revisión de sesiones y los ajustes de herramientas, la conciencia experimental del tiempo, la gestión de claves externas de la organización y el aislamiento de las claves de API por petición; y la referencia de la API publicada con esa versión — los modos de review y sus descripciones, la regla de que un nuevo modo de revisión se aplica a los nuevos turnos raíz, el ajuste compaction y su advertencia sobre el uso de tokens, el indicador experimental.time_awareness y su valor por defecto, el valor por defecto de spend_control (una sesión sin límite) y las solicitudes de aprobación de uso del ordenador. El código de la sección 4 es una ilustración mía con nombres de campo de esa referencia, y la interpretación de las secciones 3 a 5 es mía.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
