Ejecutar un solo agente de Codex es sencillo. Abres una terminal, describes una tarea y lo ves trabajar. El problema empieza con tres. Un agente está refactorizando el módulo de autenticación, otro está arreglando una prueba inestable, un tercero está redactando una migración, y cada uno vive en su propia pestaña de terminal con su propio historial de desplazamiento. Diez minutos después ya no recuerdas qué pestaña tiene qué tarea, si la migración terminó o en qué rama aterrizó la corrección de la prueba. Los agentes están bien. Lo que se rompió fue tu capacidad de hacerles seguimiento.
Este es el problema real detrás de «gestionar múltiples agentes de Codex». No es la concurrencia; Codex se ejecuta sin problema en paralelo a través de directorios de trabajo separados. El problema es que el estado de ese trabajo —qué está haciendo cada agente, qué terminó, qué falló y qué necesita tu revisión— termina disperso entre pestañas de terminal, carpetas de worktree y tu propia memoria. Pierde uno de esos elementos y pierdes el hilo.
Sharkly existe exactamente para cubrir esa brecha. Ya tienes agentes de programación; Sharkly los convierte en un equipo al darle a cada ejecución de agente un registro compartido. Este artículo recorre primero la configuración manual, porque conviene entender qué estás automatizando, y luego muestra dónde un tablero de tareas se gana su lugar. Terminarás con una lista de verificación que puedes aplicar hoy mismo.
Qué significa realmente «perder el hilo»
Perder el hilo no es algo vago. Es un fallo concreto: tu estado de trabajo no tiene un único hogar. Cuando ejecutas varias sesiones de Codex a mano, la verdad sobre cada tarea queda repartida en cuatro lugares a la vez. La instrucción vive en la terminal donde la escribiste, los cambios viven en un directorio de trabajo de Git, el estado vive en tu cabeza y el resultado vive en un pull request que aún no has abierto. Nada mantiene sincronizados esos cuatro elementos. Cierra la terminal y la instrucción desaparece. Cambia de pestaña y el estado es una suposición. Cuantos más agentes añadas, más copias de «qué está pasando» mantienes, y tú eres el único punto de integración que las sostiene todas juntas.
Así que el objetivo de gestionar múltiples agentes de Codex es acotado y vale la pena enunciarlo con claridad: mantener la tarea, el progreso, los cambios y el estado de revisión de cada agente en un solo lugar, en vez de repartirlos entre sesiones privadas de terminal. Todo lo que sigue se evalúa contra esa única prueba.
Paso 1: Aísla cada agente con un worktree
El primer modo de fallo es la colisión. Apunta dos agentes de Codex a la misma carpeta y sobrescribirán las ediciones del otro, prepararán los archivos del otro y producirán un diff que nadie podrá leer. Los worktrees de Git lo solucionan limpiamente al darle a cada agente su propia copia de trabajo del mismo repositorio, en su propia rama.
# Un directorio de trabajo aislado por tarea, cada uno en su propia rama
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
Ahora inicia una sesión de Codex dentro de cada directorio. Cada agente ve solo sus propios archivos, hace commit en su propia rama y no puede pisar a los demás.
cd ../repo-auth && codex # agente 1, refactor de autenticación
cd ../repo-flaky && codex # agente 2, prueba inestable
Modo de fallo que hay que nombrar aquí: los worktrees resuelven las colisiones de archivos, no el seguimiento. Ahora tienes tres carpetas con nombres casi idénticos y ningún registro de qué tarea contiene cada una. Adopta una convención de nombres que codifique la tarea (agent/<task>), porque en una semana repo-2 y repo-3 no significarán nada. Si quieres los mecanismos más a fondo, consulta Git worktrees para agentes de programación con IA y el patrón más amplio en ejecutar múltiples tareas de Codex a la vez.
Paso 2: Mantén las sesiones a la vista
Tres agentes en tres pestañas significa que estás a un Cmd+W accidental de matar una tarea en ejecución y perder su historial de desplazamiento. Un multiplexor de terminal como tmux mantiene cada sesión viva en ventanas con nombre de las que puedes desconectarte y reconectarte más tarde.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
Las ventanas con nombre (auth, flaky, migration) restauran la etiqueta que una pestaña normal desecha. Desconéctate con Ctrl-b d, cierra tu portátil, reconéctate por la mañana y las sesiones seguirán ahí.
Modo de fallo que hay que nombrar aquí: tmux mantiene las sesiones en ejecución; no te dice cuáles te necesitan. Un agente que terminó hace veinte minutos y un agente que encontró un error se ven idénticos desde fuera: un panel silencioso. Todavía tienes que visitar cada ventana y leer las últimas cien líneas para conocer su estado. Ese costo de sondeo crece con cada agente que añades, y es el impuesto que hace que la configuración manual se sienta más pesada con el tiempo.
Paso 3: Registra el estado y la revisión en algún lugar duradero
La última pieza manual es la que la gente se salta: anotar qué produjo cada agente y si lo aceptaste. El historial de desplazamiento no es un registro. Desaparece, no es buscable entre tareas y un compañero de equipo no puede leerlo. La versión ligera es una lista de verificación simple que actualizas a mano.
TAREA RAMA ESTADO REVISIÓN
refactor auth agent/auth-refactor hecho necesita revisión
prueba flaky agent/flaky-test en ejecución -
migración db agent/db-migration falló: permiso sin revisar
Este es todo el trabajo en miniatura: un lugar duradero donde el progreso, los bloqueos, los resultados y la revisión humana permanecen visibles desde la solicitud hasta el lanzamiento. Mantenlo con fidelidad y podrás gestionar varios agentes desde una terminal durante mucho tiempo. La trampa es que tú eres el motor de sincronización, actualizándolo a mano cada vez que algo cambia. Para saber más sobre cómo hacer auditable la producción de los agentes, consulta cómo hacer seguimiento del trabajo completado por agentes de programación con IA.
Dónde la configuración por tu cuenta deja de escalar
Sé honesto sobre cuándo basta el enfoque manual. Para uno o dos agentes de Codex en tareas bien delimitadas, los worktrees más una convención de nombres más un archivo de estado mantenido a mano es genuinamente suficiente. No añadas herramientas que no necesitas; las piezas móviles son casi cero y todo cabe en tu cabeza.
La ecuación cambia en un punto predecible. Lo sientes cuando:
- Ejecutas tres o más agentes y el costo de sondeo (visitar cada panel, leer el final, recordar el estado) consume más tiempo del que ahorran los agentes.
- El trabajo abarca más de un repositorio, así que los worktrees por sí solos dejan de ser una imagen limpia.
- Alguien más pregunta «¿qué están haciendo los agentes ahora mismo?» y la única respuesta honesta vive en tu terminal y tu memoria.
Cada uno de estos casos es la misma causa raíz del inicio del artículo: un estado de trabajo sin hogar compartido. La configuración manual lo mantiene en el único lugar que no escala, que eres tú. Los equipos chocan con este muro más rápido, y por eso las mejores herramientas para gestionar agentes de programación con IA en paralelo convergen todas en el mismo movimiento: darle al trabajo un hogar fuera de la terminal.
Qué aporta un tablero de tareas
Un tablero de tareas cambia la unidad de gestión de «una sesión de terminal» a «una Tarea». En Sharkly, conectas el Equipo en el que ya ejecutas Codex y luego asignas una Tarea a un Agente de Codex en lugar de escribir en un panel. El Agente se ejecuta en su propio worktree aislado, y la ejecución, el progreso, los bloqueos y los resultados vuelven a la Tarea. Dejas de sondear; el tablero ya sabe qué terminó y qué falló.
La división del trabajo es deliberada, y vale la pena enunciarla como un límite: Sharkly no es un reemplazo de Codex. Codex realiza la ejecución. Sharkly añade la tarea compartida, el Equipo, el contexto y la capa de revisión a su alrededor. Los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, otorgan autoridad y aceptan el resultado. La automatización se detiene donde se requiere tu criterio, que es la puerta de revisión, no el código.
Eso es lo que el archivo de estado manual pretendía lograr, hecho duradero y compartido. De ahí se derivan tres cosas que la terminal no puede darte:
- Estado sin sondeo. Cada Tarea muestra en ejecución, hecha, bloqueada o necesita revisión sin que visites un panel.
- Una sola imagen entre repositorios. Las Tareas de muchos repos y muchos Agentes se sientan en un solo Espacio, así que más agentes no significa más terminales que cuidar. Es la misma razón por la que los equipos ejecutan Claude Code y Codex juntos desde un solo lugar.
- Un paso de revisión que se mantiene. Los resultados esperan en una puerta de human-in-the-loop con el resumen del cambio y la evidencia adjuntos, así que nada se fusiona porque olvidaste que estaba pendiente.
Puedes construir todo esto a mano con worktrees y disciplina, o usar Sharkly para gestionar el flujo de trabajo cuando aumenta el número de agentes. Codex permanece exactamente igual; la gestión se libera de tus hombros. Si ya ejecutas varios agentes de Codex, ese es el problema en torno al cual Sharkly está diseñado.
La lista de verificación que puedes aplicar hoy
Ya sea que te quedes en modo manual o pases a un tablero, este es el mínimo que evita que pierdas el hilo:
- [ ] Un worktree aislado por agente, en una rama nombrada según la tarea, nunca dos agentes en una misma carpeta.
- [ ] Una convención de nombres que codifique la tarea, para que
agent/auth-refactorgane arepo-3. - [ ] Sesiones de larga duración (tmux o un tablero) de las que puedas desconectarte y reconectarte sin matar el trabajo.
- [ ] Un registro de estado duradero fuera del historial de desplazamiento de la terminal: tarea, rama, estado, estado de revisión.
- [ ] Una puerta de revisión explícita; ninguna rama se fusiona hasta que un humano la acepte.
- [ ] Una comprobación de conteo: con tres o más agentes, o dos o más repos, saca el estado de tu cabeza.
Aplica la versión manual hasta que el impuesto del sondeo duela. Cuando eso ocurra, ejecuta tus agentes de programación actuales a través de Sharkly para que el seguimiento sea tarea del tablero, no tuya.
Preguntas frecuentes
¿Cuántos agentes de Codex puedo ejecutar realmente a la vez? Tantos como permitan tu máquina y tus límites de tarifa; el techo con el que chocas primero suele ser humano, no técnico. Hacer seguimiento de tres o más a mano es donde la mayoría de la gente pierde el hilo. Consulta hilos concurrentes y subagentes de Codex para los límites del lado de la ejecución.
¿Un tablero de tareas reemplaza a Codex? No. Codex ejecuta; el tablero gestiona la asignación, el aislamiento, el contexto y la revisión a su alrededor. Se complementan mutuamente.
