12 de octubre de 2026
CFD con varios agentes: cómo mantener el contexto entre worktrees
El 10 de octubre, Ahmed, de Winskel, me escribió después de leer Context-First Development. Estaba construyendo una aplicación para coordinar tareas entre Claude Code y Codex. Su pregunta, traducida, era esta:
¿Cómo preservarías el contexto del proyecto cuando dos agentes se encargan de piezas distintas?
Me dio gusto recibirla. Alguien había leído la metodología, la había relacionado con su trabajo y había encontrado algo que todavía necesitaba explicar mejor.
CFD propone dejar por escrito las decisiones de un proyecto para que un agente pueda retomar el trabajo sin que tengamos que explicárselo todo de nuevo. La pregunta de Ahmed añadía un problema: mientras un agente aprende algo nuevo, otro puede estar trabajando con información que ya quedó desactualizada.
Eso dio pie a ampliar la metodología para trabajar con varios agentes en paralelo.
El mismo movimiento, dos meses distintos
Imagina una aplicación financiera. Un agente prepara la descarga de movimientos y otro construye el resumen mensual.
Cada uno trabaja en su propio worktree: un directorio separado donde puede modificar una rama del mismo repositorio. Así sus ediciones locales no se mezclan. Git permite mantener esos directorios abiertos al mismo tiempo.
Pero aparece un movimiento cerca de medianoche. El primer agente usa la hora de la cuenta y lo ubica en septiembre. El segundo usa la hora UTC y lo cuenta en octubre.
Los archivos pueden integrarse sin conflictos. La aplicación, sin embargo, muestra dos respuestas para el mismo dato.
30 sept · 21:30 · Hora de la cuenta
Descarga: septiembre
1 oct · 00:30 · UTC
Resumen: octubre
≠ No coinciden: el mismo dato, dos meses
Un movimiento cerca de medianoche llega a los dos worktrees.
Separar los archivos permite trabajar en paralelo. También hace falta que ambos agentes conozcan la regla que determina a qué mes pertenece un movimiento.
Primero, acordar qué va a hacer cada uno
En CFD, cada agente recibe una tarea pequeña, con un resultado esperado y una forma de comprobarlo. También queda definido qué partes del proyecto puede modificar.
Para nuestro ejemplo, antes de empezar hay que decidir qué fecha se usa. Esa decisión se registra en el repositorio y ambos agentes la leen. La descarga y el resumen se construyen desde el mismo criterio.
Si los dos necesitan cambiar una pieza compartida, ese cambio se resuelve primero. Después pueden continuar por separado.
Cada agente conserva sus propias notas de avance. «Falta probar el cierre de mes» pertenece a la tarea de quien lo anotó. Las reglas del proyecto, en cambio, quedan disponibles para todos. Un tablero de tareas permite ver quién está haciendo qué.
Si cambia una decisión, hay que incorporarla al trabajo en curso
Algunas preguntas aparecen recién al implementar. Supongamos que nadie había definido qué hacer con las fechas cercanas a medianoche.
El agente que descubre el problema se detiene. El desarrollador resuelve la decisión y la incorpora al repositorio. Si el otro agente está trabajando en algo afectado, también pausa esa parte hasta actualizarse.
Ambos deben leer la nueva regla y comprobar el trabajo que ya hicieron. Actualizar los archivos no garantiza que una conversación abierta con el agente deje de usar la interpretación anterior.
- 1. Resolver
- 2. Actualizar archivos
- 3. Releer y comprobar
Revisión del desarrollador
Fecha ambigua
Trabajo afectado en pausa
Descarga: septiembre
Trabajo afectado en pausa
Resumen: octubre
A encuentra una fecha ambigua. El trabajo afectado se detiene en ambos worktrees.
En el ejemplo, la comprobación es concreta: la descarga y el resumen deben ubicar ese movimiento en el mismo mes.
Esta fue la mejora principal respecto a mi primera respuesta a Ahmed. Documentar una decisión al terminar puede llegar tarde para el agente que lleva un rato trabajando con otro supuesto.
Revisar los resultados de uno en uno
Los agentes pueden implementar al mismo tiempo. Sus cambios se incorporan al proyecto de uno en uno, con revisión humana en cada paso.
Si la descarga entra primero, el resumen se revisa sobre el proyecto que ya incluye esa descarga. Se comprueba que cumple su tarea y que sigue respetando las decisiones compartidas.
- 1En paraleloAgente A · Descarga
Implementa
Agente B · Resumen mensualImplementa
Proyecto compartidoVersión de partida
- 2Entra la descargaAgente A · Descarga
Revisión humana
Agente B · Resumen mensualSigue en su worktree
Proyecto compartido+ Descarga
- 3El resumen se pone al díaAgente A · Descarga
Integrada
Agente B · Resumen mensualActualizar y comprobar con la descarga integrada
Proyecto compartidoIncluye la descarga
- 4Entra el resumenAgente A · Descarga
Integrada
Agente B · Resumen mensualRevisión humana
Proyecto compartido+ Resumen
Cuatro pasos: los agentes implementan en paralelo y se integran de uno en uno.
Por eso CFD propone empezar con dos o tres agentes cuando hay tareas independientes y tiempo para revisar sus resultados. Si los cambios terminados se acumulan esperando revisión, abrir otro agente aumenta esa espera.
La capacidad de revisar forma parte de la planificación, igual que la capacidad de implementar.
Lo que cambió en CFD
La metodología ahora deja explícito cómo repartir las tareas, qué contexto comparte cada agente y cuándo detenerse para incorporar una decisión nueva. También mantiene la revisión humana antes de integrar cada resultado.
La pregunta de Ahmed ayudó a precisar un escenario que yo no había desarrollado lo suficiente. Esas reglas ya están en el repositorio de CFD, en la decisión sobre trabajo paralelo con worktrees, con el detalle técnico para aplicarlas.