01

Decidí si el trabajo se puede partir

Seis preguntas, antes de escribir nada. Están enteras en el kit, pero las dos que más deciden son estas: ¿hay dos ramas que pueden avanzar sin esperarse? y ¿cada agente puede ser dueño de su propio archivo?

Si el paso B necesita el resultado de A, no hay paralelo posible: hay una secuencia. Y una secuencia la hace mejor un solo agente que ya tiene el contexto encima, sin pagar el traspaso.

Con cinco o seis respuestas afirmativas, armá el equipo. Con tres o cuatro, delegá una sola rama —la más ruidosa— y hacé el resto vos en el hilo principal. Con menos de tres, un agente solo. Vas a llegar antes y más barato.

02

Escribí el brief maestro

El brief es el mensaje que abre el turno, antes de que se delegue nada. Tiene cinco partes y ninguna es decorativa: objetivo, contexto, entregables, restricciones y criterio de terminado.

La parte que más se saltea es la de restricciones, y es la que evita los tres accidentes caros: que dos agentes escriban el mismo archivo, que alguien afirme algo sin fuente y que un subagente se quede esperando un permiso que vos nunca viste.

Objetivo: [el resultado concreto, en una oración]

Contexto: [qué es este proyecto, en qué estado está, qué decidimos antes]

Entregables:
- [artefacto 1: nombre de archivo y qué tiene adentro]
- [artefacto 2]
- una síntesis con decisiones, evidencia, contradicciones e incertidumbres

Restricciones:
- Cada agente edita únicamente su archivo asignado.
- Toda afirmación factual lleva fuente, archivo y línea, o se marca como supuesto.
- Ninguna herramienta externa se considera autorizada por defecto.
- Escalá a mí si hace falta una credencial, un dato personal, un permiso nuevo
  o un cambio fuera de este directorio.

Criterio de terminado:
- Los artefactos están completos y sin contradicciones entre sí.
- Los riesgos están priorizados y cada uno tiene dueño.
- Cada afirmación importante es rastreable hasta su fuente.
- Existe una recomendación explícita: avanzar, iterar o parar.

03

Delegá con fronteras: un archivo por agente

Un buen pedido de delegación dice tres cosas: cómo se parte el trabajo, si hay que esperar a todos antes de seguir, y qué formato tiene el resumen que volvés a recibir. Si falta alguna, Codex la completa por su cuenta y no siempre como esperabas.

Usá subagentes para esto. Delegá en paralelo:

1) producto: usuarios, problema, alcance, exclusiones y métricas.
   Entregá producto.md.
2) seguridad_qa: amenazas, controles, casos de prueba y puerta de salida.
   Entregá riesgos.md.

Ninguno de los dos toca el archivo del otro. Esperá los dos resultados. Después
compará supuestos, resolvé las contradicciones que encuentres, marcá lo que
quede incierto y armá una síntesis. No conectes sistemas externos.

En el CLI también se puede pedir un agente por punto, que es el formato que mejor rinde para revisar una rama:

Revisá esta rama contra main con subagentes en paralelo. Un agente por punto:

1. Riesgos de seguridad
2. Huecos de test
3. Mantenibilidad
4. Condiciones de carrera

Esperá a los cuatro y resumí los hallazgos por categoría, con archivo y línea.

04

Armá el equipo fijo con archivos .toml

Todo lo que viste hasta acá se armó escribiéndolo en el pedido, que es como corrimos el caso: los subagentes se llamaron Producto y Seguridad qa porque así los nombró el encargo. Sirve para probar. Para no volver a explicarlo nunca más, el equipo se deja escrito: un archivo .toml por agente.

Van en .codex/agents/ dentro del proyecto, o en ~/.codex/agents/ si querés el mismo equipo en todos lados. Codex ya trae tres de fábrica —default, worker y explorer— y si tu agente se llama igual que uno de ellos, gana el tuyo.

tu-proyecto/
├── AGENTS.md
└── .codex/
    ├── config.toml
    └── agents/
        ├── explorador.toml
        ├── producto.toml
        ├── seguridad-qa.toml
        └── revisor.toml

AGENTS.md y config.toml tienen nombre fijo: Codex los busca ahí y si los renombrás no los lee. Los de agents/ no, porque cada agente se identifica por el campo name de adentro. Que el nombre del archivo coincida es una comodidad para vos cuando abras la carpeta dentro de seis meses.

Cada archivo necesita tres campos y admite varios más. Los obligatorios son name, description y developer_instructions. Los útiles son model, model_reasoning_effort y sandbox_mode.

name = "seguridad_qa"
description = "Seguridad y calidad. Amenazas, controles, casos de prueba y puerta de salida. Nunca publica ni amplía permisos."
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Escribís un solo archivo: el que te asigne el agente principal. No toques
ningún otro.

Cada amenaza va con probabilidad e impacto de 1 a 5, el control que la mitiga y
la evidencia concreta que haría falta para darla por aceptada.

Nunca publiques, despliegues, envíes ni amplíes un permiso. Si algo lo
necesita, pará y escalá al agente principal con la razón.
"""

Y una línea de configuración del proyecto, en .codex/config.toml, para poner un techo:

[agents]
max_concurrent_threads_per_session = 4
default_subagent_model = "gpt-5.6-terra"
default_subagent_reasoning_effort = "medium"

Nosotros lo dejamos en cuatro. Subirlo no acelera: multiplica el consumo y te devuelve más informes de los que vas a leer con atención. Si querés apagar el multiagente en un proyecto, enabled = false en la misma sección.

05

Elegí modelo y esfuerzo por rol

Acá se decide la mitad del costo y buena parte de la calidad. La regla corta: el agente que lee mucho y decide poco va en el modelo más chico; el que tiene que encontrar lo que nadie vio va en el más grande.

Los niveles de esfuerzo van de low a max, con ultra arriba de todo en los modelos que lo admiten. Usá el más bajo que te dé el resultado que necesitás y subí sólo cuando el trabajo pida planificar, contrastar o revisar supuestos.

Quién gana cuando hay tres configuraciones

Es la duda que aparece la primera vez que un agente se comporta distinto de lo esperado. El orden está documentado: si el archivo del agente define model o model_reasoning_effort, ese valor manda. Si no lo define, Codex resuelve cada ajuste por separado: primero el valor explícito de la delegación, después el de [agents], y por último el del agente padre. Lo demás —sandbox_mode, servidores MCP, skills— se hereda del padre cuando el archivo no lo dice.

06

Seguí el trabajo sin ahogarlo

Preguntar «¿cómo va?» cada dos minutos no acelera nada y le come contexto al principal, que es justamente lo que estabas tratando de cuidar. Pedí eventos.

Informá sólo cuando cambie el estado: iniciado, bloqueado, necesita decisión o
terminado. Si estás bloqueado, devolvé cuatro cosas: causa, evidencia, impacto
y la decisión mínima que necesitás de mí. No amplíes permisos por tu cuenta.

Mientras trabajan, el estado vive en un panel aparte:

Cada superficie muestra el trabajo de manera distinta, y conviene saber cuál te deja intervenir:

En flujos no interactivos pasa lo contrario y es sano: una acción que necesita una aprobación nueva falla, y el error sube al flujo padre en vez de quedarse esperando para siempre.

07

Consolidá sin concatenar

Este es el paso donde se pierde el trabajo que costó cuatro agentes. Pegar los informes uno abajo del otro produce un documento largo con dos afirmaciones incompatibles a doce páginas de distancia, y nadie las va a cruzar.

Consolidá los entregables. No los concatenes.

1. Listá las contradicciones entre los documentos, con la cita de cada lado.
2. Resolvé cada una y decí con qué criterio la resolviste.
3. Marcá lo que quedó incierto, sin taparlo con una redacción prolija.
4. Devolvé: decisiones tomadas, evidencia de cada una, riesgos abiertos con
   dueño, y una recomendación explícita: avanzar, iterar o parar.

Cuando dos agentes se contradicen, no promedies. Andá a la evidencia de cada uno y al criterio de aceptación. Si la diferencia es material y no se resuelve mirando fuentes, sube a vos: eso es una decisión, no un empate.

Esa última parte es la que separa una síntesis buena de una prolija. Una incertidumbre que sobrevive redactada como si fuera una conclusión es peor que una contradicción visible, porque ya nadie la va a revisar.

08

Cruzá la puerta de calidad

«Los agentes terminaron» y «el trabajo está bien» son dos afirmaciones distintas. La segunda necesita un revisor que no haya escrito nada de lo que revisa.

Revisá estos entregables sin reescribirlos. Buscá: contradicciones entre
requisitos y controles; afirmaciones sin evidencia; riesgos sin dueño; métricas
que incentiven el comportamiento equivocado; permisos asumidos; pruebas sin
resultado esperado; y decisiones irreversibles.

Priorizá P0 a P3, citá archivo y sección, y proponé la corrección mínima. Si no
hay hallazgos, explicá qué verificaste.

La última línea del prompt es la que más rinde. Un revisor que dice «está todo bien» no informó nada; uno que enumera qué verificó te muestra, sin querer, qué quedó sin revisar.