Cuando pensamos en Codex, es fácil imaginar una terminal, una extensión del IDE o una aplicación donde un agente escribe y modifica código.

Pero OpenAI está empujando Codex en una dirección bastante más ambiciosa: convertirlo en una plataforma reutilizable para construir agentes dentro de otros productos.

Ese es el mensaje central de “Codex as a platform: build on the open agent harness”, publicado por OpenAI el 19 de agosto de 2026.

La idea importante no es construir otro chat con un modelo detrás.

La idea es reutilizar la infraestructura que permite que un agente entienda una tarea, mantenga contexto, use herramientas, pida aprobación humana, sobreviva a errores y continúe trabajando durante varios turnos.

OpenAI llama a esa capa Codex harness.

Y si este enfoque se consolida, puede convertirse en una pieza fundamental de la próxima generación de software agéntico.

Un agente es mucho más que un prompt

Durante los primeros años de la IA generativa, muchas aplicaciones podían describirse con una arquitectura extremadamente sencilla:

usuario
→ prompt
→ modelo
→ respuesta

El problema es que un agente real necesita bastante más.

Para completar tareas complejas debe poder:

  • comprender el objetivo;
  • conservar estado entre turnos;
  • reunir contexto adicional;
  • llamar herramientas;
  • ejecutar código o comandos;
  • observar el resultado de esas acciones;
  • recuperarse de fallos;
  • mostrar progreso;
  • respetar límites de seguridad;
  • solicitar aprobación antes de operaciones sensibles;
  • continuar trabajando hasta producir un resultado útil.

Todo eso ocurre alrededor del modelo.

Ese sistema de ejecución es lo que normalmente se denomina agent harness.

Podemos visualizarlo así:

Aplicación
   ↓
Agent harness
   ├── contexto
   ├── estado
   ├── tool calling
   ├── ejecución
   ├── sandbox
   ├── approvals
   ├── streaming
   └── recuperación ante errores
          ↓
        Modelo

El modelo aporta razonamiento y generación.

El harness convierte esas capacidades en un proceso operativo.

Codex quiere reutilizar precisamente esa capa

Codex ya necesita resolver todos esos problemas para funcionar como agente de programación.

La aplicación, la CLI y la extensión del IDE utilizan el mismo sistema subyacente para mantener conversaciones, inspeccionar archivos, ejecutar herramientas y aplicar políticas de seguridad.

OpenAI está exponiendo ahora esa infraestructura para que otros desarrolladores puedan utilizarla.

La consecuencia es importante:

si estás construyendo un producto con agentes, no necesariamente tienes que construir desde cero el runtime del agente.

Puedes utilizar Codex como motor agéntico y concentrarte en la parte específica de tu producto.

Por ejemplo:

Tu producto
│
├── interfaz especializada
├── reglas de negocio
├── permisos
├── contexto del dominio
├── datos
│
└── Codex
     ├── agent loop
     ├── estado
     ├── herramientas
     ├── sandbox
     ├── approvals
     └── ejecución

Ese cambio parece pequeño, pero reduce una cantidad considerable de infraestructura que de otro modo cada equipo tendría que implementar y mantener.

El harness puede cambiar incluso el rendimiento del modelo

Uno de los datos más interesantes del artículo de OpenAI es que la calidad de un agente no depende únicamente del modelo utilizado.

La forma en que el harness conserva y administra el contexto también puede alterar de manera significativa el resultado.

OpenAI menciona una evaluación sobre ARC-AGI-3 en la que conservar el razonamiento entre pasos y utilizar compaction del contexto elevó el rendimiento de GPT-5.6 Sol de 13,3 % a 38,3 %.

Al mismo tiempo, los tokens de salida se redujeron aproximadamente seis veces.

Esto refuerza una idea fundamental del diseño de agentes:

modelo y harness deben evaluarse como un sistema.

Cambiar la forma en que se conserva estado, se resume contexto o se encadenan herramientas puede producir mejoras comparables —o incluso superiores— a cambiar de modelo.

Tres niveles para integrar Codex

OpenAI presenta tres formas principales de utilizar Codex como plataforma.

1. codex exec

Es la opción más sencilla.

Sirve para ejecutar un agente dentro de:

  • scripts;
  • pipelines de CI;
  • automatizaciones;
  • trabajos puntuales;
  • tareas delimitadas sin una interfaz interactiva compleja.

La arquitectura puede ser tan simple como:

CI / script
   ↓
codex exec
   ↓
resultado estructurado

Es apropiado cuando quieres delegar una tarea sin convertir Codex en una parte persistente de la experiencia del usuario.

2. Codex SDK

Cuando una aplicación necesita iniciar, reanudar o transmitir tareas de Codex desde código, el SDK ofrece una interfaz programática más directa.

El flujo pasa a parecerse a esto:

Aplicación
   ↓
Codex SDK
   ↓
Codex runtime

Esto permite integrar agentes dentro de servicios backend, herramientas internas o automatizaciones donde la aplicación controla el flujo principal.

3. Codex app-server

Aquí aparece la posibilidad más interesante.

Codex app-server está pensado para situaciones donde el agente forma parte del producto mismo.

La aplicación puede mantener conversaciones abiertas, recibir eventos, interrumpir trabajos, exponer herramientas y responder a solicitudes de aprobación.

La UI sigue siendo tuya.

El producto también sigue siendo dueño de sus datos, reglas de negocio y permisos.

Codex se ocupa del loop agéntico.

Una arquitectura típica sería:

Interfaz del producto
        ↓
Contexto + reglas + permisos
        ↓
Codex app-server
        ↓
Agent loop
        ↓
Tools / MCP / filesystem / APIs

Esto permite construir una experiencia agéntica sin obligar al usuario a abandonar la aplicación donde ya trabaja.

El agente ya no tiene que vivir dentro de un chat

Esta puede ser la implicación de producto más importante de todo el anuncio.

Durante años, la interfaz dominante de la IA generativa ha sido el chat.

Pero muchas tareas profesionales no ocurren naturalmente dentro de una conversación vacía.

Un analista de seguridad trabaja con alertas, incidentes y servicios afectados.

Un equipo de soporte trabaja con cuentas, tickets, logs y documentación interna.

Un operador de logística trabaja con envíos, mapas, rutas y excepciones.

Un equipo de ingeniería trabaja con issues, pull requests, CI y repositorios.

En esos entornos, el chat puede ser útil, pero no debería necesariamente ser la aplicación completa.

OpenAI propone que el agente viva dentro de la interfaz donde ya existe el trabajo.

Por ejemplo:

Dashboard de operaciones
│
├── pedidos
├── alertas
├── métricas
├── acciones
│
└── agente Codex

El usuario no tiene que explicar desde cero qué está mirando.

La propia aplicación puede proporcionar ese contexto automáticamente.

Relay: un ejemplo de esta arquitectura

OpenAI construyó un ejemplo llamado Relay para demostrar el patrón.

Relay simula un dashboard de operaciones logísticas.

El usuario selecciona un envío problemático y puede ejecutar una acción como comparar opciones de recuperación.

La aplicación proporciona al agente el contexto del envío.

Codex consulta datos utilizando herramientas MCP, analiza alternativas y explica las opciones disponibles.

Si la acción implica modificar una reserva, el sistema solicita aprobación humana antes de ejecutarla.

El flujo sería aproximadamente:

Usuario selecciona envío
        ↓
Aplicación entrega contexto
        ↓
Codex investiga
        ↓
MCP consulta datos actuales
        ↓
Codex propone acción
        ↓
Aprobación humana
        ↓
MCP modifica el registro
        ↓
Dashboard se actualiza

Aquí Codex no sustituye al producto.

Lo potencia.

MCP y Codex cumplen funciones distintas

También es importante distinguir dos piezas que aparecen juntas con frecuencia: MCP y el agent harness.

MCP permite conectar herramientas, sistemas y datos externos.

Puede ofrecer operaciones como:

get_customer()
create_ticket()
read_database()
update_shipment()
search_documents()

Pero MCP no decide por sí solo qué herramienta debe utilizarse ni cómo resolver una tarea compleja.

El harness aporta ese loop de razonamiento y ejecución.

Podemos pensar en la relación así:

Codex
  ↓
razona y decide
  ↓
MCP
  ↓
expone herramientas y datos

No son tecnologías competidoras.

Son capas complementarias.

La aplicación sigue siendo dueña del control

Otro punto importante del diseño de OpenAI es que integrar Codex no significa entregar todo el control al agente.

La aplicación anfitriona puede decidir:

  • qué información ve el agente;
  • qué herramientas están disponibles;
  • dónde puede ejecutarse;
  • qué archivos puede leer o modificar;
  • qué acciones necesitan aprobación;
  • cómo se observa el trabajo;
  • dónde se guardan los resultados;
  • cuál sistema conserva la verdad final.

Esto permite separar claramente responsabilidades.

Aplicación
├── identidad
├── permisos
├── reglas de negocio
├── source of truth
└── UX

Codex
├── razonamiento
├── planificación
├── agent loop
├── ejecución
└── interacción con tools

Ese límite es especialmente importante en sistemas empresariales.

Open source en la capa correcta

El harness de Codex es open source.

Eso permite inspeccionar la capa que existe entre la aplicación y el modelo, comprender su comportamiento y adaptar la integración.

OpenAI publica componentes como:

  • Codex CLI;
  • Codex app-server;
  • Codex SDK.

Esto no significa que toda la infraestructura de OpenAI o el acceso a los modelos sea open source.

La capa abierta es principalmente el harness y la superficie de integración.

Pero incluso esa separación tiene mucho valor porque permite construir productos sobre una infraestructura agéntica visible y extensible.

Esto puede cambiar la arquitectura de los sistemas multiagente

La idea se vuelve todavía más interesante cuando pensamos en sistemas con varios agentes.

Supongamos un flujo de ingeniería donde diferentes agentes tienen responsabilidades separadas:

Control plane
     │
     ├── Specifier
     ├── Architect
     ├── Developer
     ├── Reviewer
     └── QA

Tradicionalmente, construir algo así implica implementar una gran cantidad de piezas:

  • lifecycle de cada agente;
  • estado de conversaciones;
  • manejo de errores;
  • tool calling;
  • streaming;
  • aislamiento;
  • approvals;
  • context compaction;
  • persistencia;
  • recuperación de trabajos interrumpidos.

Con un harness reutilizable, el control plane puede concentrarse en coordinar roles, dependencias y políticas mientras cada instancia utiliza un runtime ya preparado para operar como agente.

Una arquitectura conceptual podría ser:

Control plane
      │
      ├── Codex: Specifier
      ├── Codex: Developer
      ├── Codex: Reviewer
      └── Codex: QA
             │
             ↓
          MCP / tools
             │
             ↓
       GitHub / CI / APIs

GitHub, una base de datos o cualquier otro sistema puede conservar el estado durable del proceso.

Codex proporciona el loop operativo de cada agente.

Esta separación hace que construir un swarm deje de ser únicamente un problema de “cómo conectar varios prompts” y pase a ser un problema mucho más interesante de orquestación, ownership y control de estado.

De copilotos a infraestructura

Durante la primera etapa de los asistentes de programación, la IA se utilizaba principalmente para completar código.

Después llegaron agentes capaces de modificar repositorios completos.

Ahora estamos entrando en otra fase:

autocomplete
     ↓
copilot
     ↓
coding agent
     ↓
agent runtime
     ↓
agent platform

Codex como plataforma encaja precisamente en esos dos últimos niveles.

El producto ya no es únicamente el agente de programación visible para el usuario.

El producto también puede ser la infraestructura sobre la cual terceros construyen otros agentes.

No construyas otro chat si el trabajo necesita otra interfaz

Probablemente la frase más útil que podemos extraer de esta dirección de producto es esta:

el mejor producto agéntico no siempre es una ventana de chat.

Puede ser un dashboard donde un agente investiga una anomalía.

Puede ser un IDE donde revisa código.

Puede ser una consola de soporte donde prepara respuestas.

Puede ser un sistema de operaciones donde compara alternativas antes de ejecutar una acción.

Puede ser un control plane que coordina varios agentes especializados.

El chat seguirá siendo importante porque el lenguaje natural es una interfaz extraordinariamente flexible.

Pero dejará de ser necesariamente el contenedor principal de toda experiencia con IA.

La verdadera oportunidad

El anuncio de OpenAI no consiste simplemente en ofrecer otra API.

Lo que está intentando estandarizar es una capa que cada equipo que construye agentes termina necesitando de una forma u otra:

el runtime que convierte un modelo en un trabajador digital capaz de actuar dentro de un sistema real.

Si esa capa se vuelve reutilizable, los desarrolladores pueden dedicar menos tiempo a reconstruir loops de agentes y más tiempo a diseñar:

  • mejores interfaces;
  • mejores herramientas;
  • mejores políticas;
  • mejor contexto;
  • mejores sistemas de aprobación;
  • mejores mecanismos de coordinación entre agentes.

Ese probablemente será uno de los cambios arquitectónicos más importantes de la era del software agéntico.

El siguiente salto no será solamente tener modelos más inteligentes.

Será poder insertar agentes confiables dentro de cualquier producto sin tener que inventar desde cero toda la maquinaria que los mantiene funcionando.

Y Codex quiere convertirse precisamente en esa maquinaria.

Fuente principal: OpenAI Developers, “Codex as a platform: build on the open agent harness”, 19 de agosto de 2026.