OpenAI depreca Agent Builder y Evals: si tu agente vive en la UI, ya necesitas plan de salida

OpenAI notificó el 3 de junio de 2026 dos deprecaciones que deberían encender alertas en equipos que construyeron agentes dentro de herramientas visuales: Agent Builder y la plataforma Evals. Según la página oficial de deprecations, Agent Builder está programado para apagarse el 30 de noviembre de 2026. Evals pasa a solo lectura el 31 de octubre de 2026 y su dashboard/API se apagarán el 30 de noviembre de 2026.

La noticia no significa que OpenAI abandone los agentes. Significa algo más práctico: los flujos de producción se están moviendo hacia Agents SDK, ChatGPT Workspace Agents y herramientas de evaluación fuera del dashboard anterior. Si tu agente depende de una UI que no vive en tu repo, el reloj ya empezó.

El detalle incómodo: exportar no equivale a migrar

La guía de migración de OpenAI permite exportar un workflow de Agent Builder como código para Agents SDK o recrearlo como Workspace Agent. Pero la misma guía advierte que el proceso no convierte el grafo completo ni garantiza que cada comportamiento se transfiera igual.

Ese matiz es el punto central. Un agente no es solo nodos y flechas. También incluye suposiciones de estado, permisos, prompts, tools, archivos, aprobaciones humanas, manejo de errores y observabilidad. Si la exportación solo te da un punto de partida, la migración real exige pruebas de comportamiento.

Qué revisar si usabas Agent Builder

Yo separaría el trabajo en tres capas:

• Inventario: lista cada agente, owner, caso de uso, tools conectadas, datos que toca y frecuencia de uso.
• Exportación: genera código o especificación desde la UI, pero trátalo como borrador.
• Validación: corre casos reales, compara salidas, revisa permisos y decide si el destino será Agents SDK o Workspace Agents.

Agents SDK tiene más sentido cuando el agente forma parte de una app, backend o flujo que tú despliegas. Workspace Agents encaja mejor cuando el trabajo vive dentro de ChatGPT, Slack o procesos internos compartidos por equipos. Ninguna ruta debería elegirse solo por comodidad de migración.

Evals también necesita plan propio

La deprecación de Evals puede doler más de lo que parece. Muchos equipos tienen dashboards que nadie mira a diario, pero que sostienen decisiones de modelo, prompts o regresiones. OpenAI apunta a Promptfoo como ruta de migración para eval workflows.

Antes de mover evals, conviene clasificar:

1. cuáles son smoke tests mínimos;
2. cuáles miden calidad subjetiva;
3. cuáles dependen de graders;
4. cuáles bloquean deploy;
5. cuáles solo eran exploratorios.

No todo merece migrarse. Pero lo que bloquea releases o protege datos sensibles sí debería vivir en un lugar versionado, reproducible y visible para el equipo.

Demanda e intención de búsqueda

Sin tooling SEO, la demanda se infiere por señales actuales: deprecación oficial, fechas de apagado, guía de migración y discusión comunitaria de usuarios afectados. Las queries probables son OpenAI Agent Builder deprecated, migrate from Agent Builder, OpenAI Evals deprecated, Agents SDK migration y Workspace Agents.

Agente IA puede competir porque la mayoría de resúmenes se quedarán en "OpenAI apaga una herramienta". El valor para builders está en traducirlo a una decisión operativa: qué flujos deben salir de una UI antes de noviembre y cómo probar que no cambió el comportamiento del agente.

Plan de salida de dos semanas

Para un equipo pequeño, haría esto:

1. día 1: inventario y priorización por riesgo;
2. días 2 a 4: exportar workflows críticos;
3. días 5 a 7: recrear tools, secretos y aprobaciones;
4. días 8 a 10: correr casos reales contra versión vieja y nueva;
5. días 11 a 12: migrar evals bloqueantes;
6. días 13 a 14: congelar cambios en Agent Builder y documentar rollback.

Si todavía estás definiendo cómo probar agentes antes de producción, empieza por el curso gratis. La conclusión práctica es simple: los agentes importantes no deberían depender de una UI que no puedes versionar, testear ni operar cuando llega una deprecación.