Construí un ejército de agentes en Codex. Lo difícil fue gestionarlo.
- Codex
- agentes de IA
- automatización
- gestión de ingeniería
- multiagente
En agosto de 2026, no intentaba inventar una organización de IA. Intentaba terminar una historia que comenzó con un sueño que anoté catorce años atrás. Después de que una partida de Dungeons & Dragons me lo hiciera recordar, abrí Codex y empecé a trabajar con las notas y los fragmentos antiguos.
Ese proyecto personal se convirtió en una novela corta ilustrada, un protocolo de revisión congelado y un flujo de publicación. Durante la semana siguiente, apliqué el método al software y empecé a trasladar a Codex mi flujo de trabajo profesional con SDK.
No puedo mostrar el funcionamiento interno del SDK, pero sí los proyectos personales que me enseñaron el método. No se trata de un único modelo brillante. Se trata de modelos imperfectos que producen trabajo que se puede inspeccionar, rechazar y continuar sin tener que retener todo el sistema en la cabeza. Lo llamo mi ejército de agentes; en la práctica, es un modelo operativo construido con roles acotados, aceptación independiente, evidencia duradera, presupuestos y responsabilidad humana.
Antes de la aplicación Codex: conectaba terminales a mano
Ya usaba Claude Code de forma intensiva en la terminal junto con Codex CLI. Podían ver el repositorio, ejecutar herramientas y hacer cambios reales. El problema era la coordinación: Claude tenía un contexto, Codex otro, y la planificación estaba en otro lugar. Si quería que un modelo cuestionara a otro, yo mismo trasladaba la información.
Incluso escribí una herramienta que restauraba los contextos de las terminales y reenviaba las respuestas entre sesiones. Funcionaba, pero yo seguía siendo el bus de mensajes, el programador de tareas, el sistema de permisos y el monitor de fallas.
En agosto de 2026 descubrí que la aplicación Codex podía mantener tareas de larga duración, archivos, herramientas, subagentes y traspasos visibles en un mismo espacio de trabajo. Yo aporté los roles, las capacidades reutilizables, la memoria del repositorio y las reglas. Diferentes modelos podían seguir dentro del flujo de trabajo; la fila de ventanas de terminal ya no tenía que hacerse pasar por una organización.
Contextos separados de Claude Code y Codex CLI, conectados con mis propios scripts y traspasos manuales.
Codex mantuvo conversación, archivos, herramientas, roles y colaboración entre agentes en un mismo lugar.
Contextos nuevos por tarea, roles especialistas, memoria en el repositorio, revisión separada y criterios explícitos de publicación.
Las herramientas cambiaron. El cambio más importante fue sacar la coordinación de mi cabeza y convertirla en límites explícitos que se pueden inspeccionar.
El cambio importante no fue la interfaz. Fue que la coordinación podía convertirse en parte del propio proyecto.
El libro fue mi primer laboratorio
No empecé diciéndole a un agente: «escribe un libro». Llevé a Codex las notas antiguas y una gran cantidad de incertidumbre. Trabajamos el mundo, las motivaciones de los personajes, las escenas faltantes y lo que la historia debía hacer sentir al lector. El repositorio se convirtió en memoria compartida: manuscrito, trasfondo narrativo, decisiones, canon visual, estado de producción y el historial de Git que vinculaba la evidencia con una versión.
Cuando existió el primer manuscrito completo, dejé de hacer la pregunta menos útil del trabajo creativo: ¿te gusta?
En su lugar, creé lectores aislados con distintos trabajos: lector objetivo, editor comercial, crítico de continuidad, defensor de la ambigüedad, escéptico hostil pero justo y especialistas en áreas más estrechas. Cada uno recibió un manuscrito limpio y un único rol, sin ver los demás informes ni el cambio que yo esperaba que elogiaran.
Ejecuté el protocolo congelado con GPT y Claude. Las auditorías anteriores de DeepSeek y Mistral se mantuvieron en una línea de evidencia separada, en vez de convertirse en votos adicionales dentro del mismo benchmark. Quería comprobar si familias de modelos aisladas encontraban el mismo mecanismo de falla.
Una crítica elocuente es una opinión; varias ejecuciones dentro de una misma familia de modelos son evidencia correlacionada. Cuando distintas familias ubican la misma brecha causal y puedo inspeccionarla, el caso se fortalece, pero no queda demostrado por mayoría de votos.
Congelamos los prompts y la estructura de puntuación para que una nueva versión no pudiera «mejorar» porque yo hubiera vuelto más amable la prueba. Antes de cambiar el manuscrito, registrábamos el mecanismo sospechado, la intervención, el efecto esperado, las cualidades que debían protegerse y la condición para revertir.
El proceso produjo una versión de revisión de 290 páginas que contenía la novela corta, las ilustraciones y el material de producción. Las verificaciones automatizadas pasaron, pero el control previo al lanzamiento falló porque varias imágenes no tenían bloqueos explícitos de canon. El PDF parecía terminado; el estado registrado decía lo contrario y no lo ignoré. Esas imágenes ya están bloqueadas, pero todavía hace falta una nueva ejecución completa del libro.
Esa falla me enseñó más de lo que habría hecho un resultado positivo y complaciente.
Después probé el mismo método con software
El segundo proyecto personal resulta ser un juego, pero el juego no es lo importante. Necesitaba un banco de pruebas en el que los agentes tuvieran que modificar una base de código real, ejecutar un motor costoso, inspeccionar el comportamiento y los elementos visuales, y sobrevivir a una infraestructura imperfecta.
Arte conceptual del banco de pruebas de software y de su futuro protagonista. Define un objetivo visual; no demuestra que la versión actual ya lo haya alcanzado.
En mi primer intento permití que un solo agente competente interpretara, diseñara, implementara, probara y evaluara la funcionalidad. Fue rápido y tuvo un diseño débil: «compila» derivó en «funciona», luego en «es mejor» y, finalmente, en «está terminado». Son cuatro afirmaciones diferentes.
Separé los roles: un responsable congelaba el resultado, un implementador modificaba el código, un ejecutor de pruebas producía evidencia, QA buscaba fallas de comportamiento y los revisores visuales y de lanzamiento evaluaban el resultado. Quien creaba algo ya no podía aceptar su propio trabajo.
Esa estructura detectó fallas que las verificaciones centradas en el código de esta iteración no habían encontrado. El código fuente compilaba, el comportamiento automatizado pasaba, los archivos de captura existían y QA aceptaba el paquete técnico. El revisor de arte abrió las imágenes y las rechazó: una era casi negra, la funcionalidad crítica estaba fuera de todos los encuadres y el personaje principal no se distinguía en la escala capturada.
La implementación había cumplido su objetivo técnico específico. El resultado del producto no era aceptable. Ambas afirmaciones eran verdaderas.
El experimento también destruyó mi primera fantasía sobre el paralelismo. En una Mac con 16 GB, varias sesiones de agentes y sus ejecuciones de herramientas coincidieron con Unity, su administrador de paquetes y su proceso de licencias. La presión sobre la memoria aumentó y la máquina se congeló.
La solución no fue un prompt más potente. Fue un programador de tareas: una sola tarea de escritura pesada a la vez, ningún agente nuevo mientras Unity estuviera activo, worktrees separados para tareas de escritura verdaderamente independientes, verificaciones baratas antes de ejecutar el motor y un límite estricto de intentos de implementación.
Agregar más agentes no crea automáticamente más autonomía. El progreso confiable se logra dentro de restricciones reales.
El patrón se trasladó a mi trabajo real
Mi SDK de producción ya tenía contexto específico por rol, capacidades reutilizables, convenciones y responsabilidades separadas. Durante la segunda semana empecé a trasladar ese flujo de trabajo a Codex. Es demasiado pronto para afirmar que los resultados privados son un éxito, pero la estructura de roles y evidencia se podía transferir entre el trabajo creativo, el trabajo basado en motores y el trabajo profesional; y con frecuencia dejaba al descubierto las fallas en vez de fabricar una aprobación.
La unidad reutilizable no era un «agente escritor» ni un «agente de Unity». Era el patrón organizativo que los rodeaba.
Sentido, alcance, criterio y decisiones irreversibles
Dirige un resultado acotado y protege el presupuesto
Investigación · Creación · Ingeniería
Recibe otra tarea e intenta refutar que esté terminado
Decisiones, entregables, manifiestos, pruebas y traspasos
Crear y validar son trabajos distintos. El repositorio conserva las evidencias; el propietario recibe decisiones, no ruido operativo sin filtrar.
El responsable define el significado y los límites. Un orquestador crea un encargo acotado. Los especialistas producen artefactos; un revisor independiente intenta refutar que el trabajo esté terminado; el repositorio conserva la evidencia. El responsable interviene de nuevo cuando hay disyuntivas, lanzamientos, cambios de rumbo o trabajo estancado y contradictorio.
Esa es la capa que ahora dedico la mayor parte del tiempo a diseñar.
Cómo se ve realmente la autonomía
No paso todo el día observando cómo trabajan los agentes. Por las mañanas de los días hábiles, antes de comenzar mi jornada laboral, congelo tareas acotadas para el libro y el banco de pruebas de software; luego dejo que esas colas personales se ejecuten sin supervisión durante cinco a siete horas. Cuando empieza el trabajo profesional, cambio de contexto y uso agentes de forma activa para mis responsabilidades normales de ingeniería. Los repositorios, las colas de tareas y los ciclos de revisión se mantienen separados.
Después del trabajo, inspecciono lo que produjo el turno de los proyectos personales: artefactos, pruebas, afirmaciones rechazadas y paquetes de decisión, en lugar de un flujo de chat. Por la noche uso tareas más pequeñas para obtener retroalimentación rápida, ajusto los roles o el proceso y, antes de dormir, asigno tareas más largas que pueden ejecutarse hasta la mañana.
Los productos importan, pero en este momento también son instrumentos. Mi experimento principal es el método para desarrollar casi cualquier cosa de esta forma: cuánto tiempo puede ejecutarse una tarea de manera segura, dónde se rompe la autonomía, qué evidencia sobrevive a la noche y qué intervención mejora el turno siguiente. Durante el mismo día calendario, las colas personales pueden seguir consumiendo capacidad de cómputo mientras uso activamente agentes separados para tareas profesionales. Eso es cómputo paralelo, no atención paralela; y explica por qué el consumo de tokens no se parece en nada al de un agente que responde una sola pregunta.
La descripción menos formal es que he estado viviendo de la dopamina. El progreso constante y visible hace que dormir sea sorprendentemente difícil, incluso cuando el propósito del sistema es que pueda seguir trabajando sin mí.
Lo que construiría primero
Si actualmente alternas entre varios chats de IA y trasladas conclusiones a mano, no empieces por crear doce agentes.
Empieza con un flujo de trabajo problemático y tres roles:
- Responsable: congela un resultado, lo que queda fuera del alcance, los criterios de aceptación y el presupuesto.
- Creador: produce el cambio o artefacto coherente más pequeño.
- Revisor: verifica el resultado en un contexto separado y no puede repararlo discretamente.
Guarda el objetivo, las decisiones y la evidencia en el repositorio. Exige un artefacto en lugar de una actualización de estado persuasiva, haz que el Revisor cite lo que inspeccionó y termina después de un solo resultado.
Solo agrega otro rol cuando puedas nombrar el conflicto, el cuello de botella o la experiencia faltante que resolverá.
Los roles necesitan contratos, no disfraces
Muchas demostraciones multiagente presentan un elenco de desarrolladores brillantes y especialistas en pruebas meticulosos. Las personalidades pueden hacer que un prompt resulte agradable. No generan responsabilidad.
Un rol operativo necesita cinco cosas:
- Una entrada definida. ¿Qué debe existir antes de que comience este rol?
- Un resultado acotado. ¿Qué artefacto o veredicto debe devolver?
- Autoridad explícita. ¿Qué herramientas y archivos puede usar o modificar, y qué decisiones puede tomar?
- Acciones prohibidas. ¿Qué debe derivar a otro lugar, aunque sepa cómo hacerlo?
- Una condición de cierre. ¿Cuándo está la tarea terminada, rechazada, bloqueada o lista para una persona?
«Eres un ingeniero de QA cuidadoso» es más débil que «tienes acceso de solo lectura, no puedes corregir lo que encuentres, debes vincular cada falla con los criterios congelados y solo puedes devolver ACCEPT, REJECT o NEEDS_OWNER_DECISION».
No todos los límites son igual de sólidos. Cuando es posible, uso permisos del sistema de archivos, worktrees, listas de herramientas permitidas y bloqueos de recursos: el bloqueo de Unity pertenece al programador de tareas, no a un prompt cortés. Las instrucciones escritas son más débiles y no pueden autorizar un lanzamiento sin un control de evidencia o una decisión humana.
El modelo solo importa después de definir bien el trabajo. Puedo dirigir la arquitectura y la revisión final a un modelo de frontera; la exploración, a uno más rápido; el trabajo determinista, a uno más barato; y la revisión adversarial, a otra familia de modelos. Los roles deberían sobrevivir a esas sustituciones. A menudo quiero que Claude cuestione un plan producido en Codex; no quiero que quien lo cuestiona edite la implementación que evalúa.
El contexto debe ensamblarse, no acumularse
Una conversación interminable acaba recordando demasiado: requisitos obsoletos, registros sin procesar, hipótesis abandonadas y resúmenes seguros de sí mismos sobre versiones que ya no existen.
Ahora prefiero contextos de ejecución nuevos, ensamblados a partir de capas duraderas.
Un buen prompt de rol no es una biografía. Es la última capa sobre el contexto duradero del proyecto y un contrato de tarea muy acotado.
El repositorio es la memoria institucional; la conversación es una interfaz para acceder a ella.
Para cada proyecto conservo un objetivo, un registro de decisiones, la iteración actual, los criterios de aceptación, lo que queda fuera del alcance, un directorio de evidencia y un traspaso final conciso.
Una tarea nueva lee lo que necesita para un solo resultado, escribe la evidencia de vuelta y termina. Las conversaciones estratégicas siguen siendo útiles porque los residuos operativos quedan fuera. Es menos cómodo que un único contexto enorme y mucho más fácil de auditar.
La factura me enseñó lo que realmente significa el paralelismo
En ese momento pagaba cerca de US$100 al mes por Claude y empecé a usar Codex mediante una suscripción de ChatGPT de aproximadamente US$20. Pasé a la opción de cerca de US$100 y luego alcancé su límite semanal en unos dos días después de agregar trabajo de software y SDK. La siguiente actualización que se me mostró costaba aproximadamente €200; mantengo las monedas que registré en lugar de fingir que se pueden comparar directamente.
Este es un diario de uso de agosto de 2026, no un benchmark de precios. Los planes y los límites cambian, y yo ejecutaba flujos de trabajo largos, con un alto nivel de razonamiento, en varios proyectos. Al final de la segunda semana, ambos servicios se quedaron brevemente sin presupuesto.
La lección útil es más sencilla:
«La concurrencia es una política de gasto».
Lanzar cinco revisores con un alto nivel de esfuerzo es una decisión presupuestaria. El modelo, el esfuerzo de razonamiento, la cantidad de agentes, los reintentos y la duración de la tarea deben formar parte del contrato del flujo de trabajo.
Mis reglas prácticas ahora son estas:
- Una tarea, un resultado. Una tarea que termina una iteración no empieza la siguiente en silencio.
- Separar la creación de la aceptación. Nadie califica su propio trabajo.
- Primero, evidencia barata. Usa verificaciones estáticas o un único revisor especializado antes de compilaciones costosas, paneles amplios o revisiones visuales.
- La evidencia tiene procedencia. Una aprobación corresponde a una versión específica del código fuente, un comando, el entorno y la configuración pertinentes, y un resultado inmutable.
- La autoridad y el presupuesto son acotados. Los revisores conservan acceso de solo lectura; el modelo, el entorno de ejecución, los reintentos y los intentos tienen límites; las decisiones irreversibles regresan al responsable.
- Una falla detiene el ciclo. «No demostrado» y los veredictos contradictorios vuelven al responsable en vez de iniciar silenciosamente otro intento.
- Cambiar una variable del proceso a la vez. Si cambian tanto la ruta como el modelo, no finjas que el resultado demuestra cuál de los dos ayudó.
El objetivo no es minimizar cada token. Es gastar el razonamiento costoso donde cambia una decisión.
Así que hice que este artículo se revisara a sí mismo
Publicar un artículo sobre flujos de trabajo confiables con agentes sin aplicar el método al propio artículo me parecía absurdo. Así que envié una versión congelada a cuatro roles —un lector sin contexto previo, un editor de encargos, un auditor factual y un profesional del área—, una vez con GPT y otra con Claude. Los ocho informes internos devolvieron revise.
Consenso, riesgos y preferencias quedan separados
Editar, conservar, verificar o rechazar
Ocho lecturas no son ocho fuentes independientes. La coincidencia entre familias de modelos eleva la prioridad de un hallazgo, pero no sustituye la verificación ni el criterio del autor.
Ambas familias cuestionaron las mismas afirmaciones exageradas y discreparon sobre el título y cuánto conservar de esta sección. Los informes privados no demuestran que el artículo sea bueno; expusieron afirmaciones que yo podía inspeccionar. El flujo de revisión no podía editar ni publicar, así que las decisiones —y la responsabilidad— siguieron siendo mías.
Lo que sigue siendo humano
No delegué el significado del libro, qué críticas importaban, qué ambigüedad conservar, la dirección del producto ni la responsabilidad por el SDK. Los agentes pueden inspeccionar, implementar, probar y cuestionar; no pueden asumir la responsabilidad. El rol humano sube de nivel, pero no desaparece.
Mi trabajo consiste cada vez más en diseñar la organización: decidir dónde vive el contexto, separar autoridades en conflicto, definir la evidencia y los presupuestos, e intervenir cuando el sistema llega a una decisión real.
La ingeniería de prompts puede mejorar una respuesta. El diseño organizativo puede hacer útiles meses de respuestas imperfectas.
Empecé con un sueño de hacía catorce años y un sistema casero de retransmisión entre ventanas de terminal. Dos semanas después, el mismo patrón organizativo impulsaba un libro, un experimento de software y parte de mi flujo de trabajo profesional, sin obligarme a observar cada paso.
Los modelos, las interfaces, los planes y los límites cambiarán. La capacidad duradera es convertir la inteligencia en una organización capaz de decirte cuándo se equivoca.
A continuación, planeo publicar las plantillas concretas que sustentan esta configuración: contratos de roles, encargos de tareas, paquetes de evidencia y las reglas que uso para decidir qué modelo recibe cada trabajo.