Empiezas una funcionalidad en Claude Code. Se atasca con un error de tipos complicado, así que le pasas el mismo repositorio a Codex, que es mejor para ese tipo de trabajo pesado. Codex lo arregla, pero ahora no tiene ni idea de para qué era la funcionalidad, qué archivos ya habías acordado no tocar ni qué significa "terminado" en este caso. Le vuelves a explicar todo de memoria. Diez minutos después vuelves a cambiar y Claude Code también lo ha olvidado. El código avanzó. El contexto, no.
Este es el precio de usar más de un agente de programación. Cada herramienta guarda su propia memoria en su propio formato y su propia sesión, así que en el momento en que el trabajo pasa de un agente a otro, todo excepto el diff se queda por el camino. Mantener el contexto al cambiar entre agentes de programación significa hacer que ese contexto viva en algún lugar fuera de cualquier agente individual, en un formato que el siguiente pueda leer sin que tú se lo tengas que narrar.
Este artículo explica cómo hacerlo, usando Sharkly como flujo de trabajo: la capa que se sitúa por encima de tus agentes de programación y mantiene visibles el contexto, el progreso, los bloqueos, los resultados y la revisión humana desde la petición hasta el lanzamiento. Ya tienes agentes de programación. El problema aquí es la costura entre ellos, y se ensancha con cada agente que añades.
Por qué el contexto no viaja entre agentes
El contexto de una tarea de programación vive en tres lugares, y solo uno de ellos es portátil.
El primero es el archivo de instrucciones: CLAUDE.md, AGENTS.md, GEMINI.md. Reglas permanentes, convenciones, los comandos para ejecutar las pruebas. El segundo es el estado de la sesión: el historial de lo que tú y el agente acabáis de decir, lo que intentó, lo que descartó. El tercero es el propio artefacto, el diff en disco o la rama.
Solo el tercero viaja gratis. Un agente distinto puede leer el código, pero no puede leer una conversación de la que no formó parte, y no va a leer un archivo de instrucciones dirigido a otra herramienta. Esa es la frontera que merece la pena enunciar con claridad: cambiar de agente conserva el código y descarta el razonamiento. El commit sobrevive. El "porqué" estaba en un búfer de scrollback que un agente vio y el siguiente nunca verá.
Así que mantener el contexto durante un cambio son en realidad dos tareas: hacer que las reglas permanentes sean legibles para todos los agentes, y hacer que el estado de la tarea en curso exista como algo distinto de la memoria de una sola herramienta. Las siguientes secciones las abordan en orden. (Si tu problema es perder el contexto entre ejecuciones del mismo agente, ese es un problema relacionado pero distinto, tratado en mantener el contexto entre sesiones de IA).
Haz que las reglas permanentes sean un único archivo que todos los agentes lean
Empieza por la victoria fácil. Claude Code lee CLAUDE.md, Codex lee AGENTS.md, Gemini CLI lee GEMINI.md. La misma función, tres nombres de archivo. Si los mantienes por separado, se desincronizan, y el agente al que has cambiado ahora sigue reglas obsoletas mientras tú das por hecho que no es así.
Escribe las reglas una sola vez y haz que los otros nombres de archivo apunten a ellas. En macOS o Linux:
# AGENTS.md is the source of truth; the others are aliases
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md
git add AGENTS.md CLAUDE.md GEMINI.md
Ahora todos los agentes que abran el repositorio leen las mismas convenciones, y hay un solo archivo que actualizar cuando cambien. Mantenlo breve y factual: el comando de pruebas, los directorios prohibidos, la regla de revisión, cómo deben verse los commits. Este es el contrato compartido que cada agente hereda en el instante en que arranca, sin importar a cuál hayas cambiado.
El modo de fallo que hay que vigilar: incluir detalles específicos de una tarea en estos archivos. El archivo de instrucciones es para reglas que son válidas en todas las tareas del repositorio. "Usamos Vitest, no Jest" pertenece aquí. "Termina la lógica de reintento del checkout y no toques el middleware de autenticación" no; eso es cierto para una tarea de esta semana y falso para la siguiente. Mezclar las dos cosas hace que todos los agentes lean instrucciones pensadas para un trabajo que ya se entregó.
Lleva contigo el contexto de trabajo, no solo las reglas
El archivo de reglas lleva a un nuevo agente hasta la línea de salida. No dice nada sobre la tarea en curso: qué se ha decidido, qué está a medias, qué sigue siendo incierto. Ese conocimiento es exactamente lo que se evapora cuando cambias, porque solo vivió en la sesión del agente anterior.
El arreglo manual es una nota de traspaso. Antes de cambiar de agente, haz que el actual escriba dónde está: el objetivo, los archivos que cambió, lo que verificó y esa única cosa de la que no estaba seguro. Pega eso en el siguiente agente como primer mensaje. Funciona, y para un solo cambio es suficiente. Merece la pena interiorizar el patrón por sí mismo; la forma de una buena nota se trata en plantillas de traspaso entre agentes.
El modo de fallo es que la nota no vive en ningún sitio duradero. Es un párrafo en un terminal que vas a cerrar, o un mensaje que reescribes cada vez. Cambia de un lado a otro dos veces y estarás manteniendo la nota de traspaso a mano, en tu cabeza, entre tres herramientas. El contexto existe, pero te has convertido en la base de datos donde se almacena. Eso aguanta para una tarea. No aguanta cuando llevas varias, que es donde el enfoque artesanal se queda sin recorrido.
Donde la configuración artesanal deja de escalar
Reglas con enlaces simbólicos más una nota de traspaso pegada te llevan muy lejos con un repositorio y dos agentes. Añade un tercer agente, un segundo repositorio o una tarea que abarca todo un día, y la aritmética se te vuelve en contra. Cada cambio es una exportación y una reimportación manuales. Cada tarea tiene su propio hilo de "qué está hecho" que solo vive donde lo dejó el último agente. Nada te avisa de que un agente de backend terminó el endpoint que el agente de frontend está esperando, porque "avisar" era un mensaje en un terminal que nadie está mirando.
Llegados a ese punto, la solución no es una nota mejor. Es sacar el contexto de trabajo de los agentes por completo y llevarlo a una Tarea compartida de la que todos los agentes y personas lean y en la que escriban. Una Tarea en Sharkly contiene el objetivo, los criterios de aceptación, el diff, los bloqueos y la conversación en un único registro. La ejecución, los bloqueos, los resultados y el seguimiento vuelven a la línea temporal de esa Tarea, así que cambiar de agente deja de ser una exportación por completo. Reasignas la Tarea; el siguiente agente lee el mismo registro en el que escribió el anterior.
Aquí también se vuelve limpia la separación entre humano y agente. Los agentes investigan, ejecutan, prueban y reportan a la Tarea. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo, y el registro que lee el siguiente trabajador es el mismo que lee un revisor. Eso solo funciona porque el contexto ya no está atrapado en una sesión.
Aquí está el par de decisiones honesto. Si usas un solo agente en un solo terminal sobre un solo repositorio, no necesitas nada de esto; el contexto nunca se va, así que no hay nada que preservar. Recurre a una Tarea compartida en el momento en que el contexto tenga que sobrevivir a un cambio, ya sea un cambio de agente a agente, de agente a humano o simplemente tú mañana por la mañana. Si quieres seguir usando varios agentes de programación en lugar de comprometerte con un único ecosistema, esa portabilidad es el punto: tu flujo de trabajo sobrevive al agente que elijas después, porque el contexto nunca estuvo almacenado dentro de ninguno de ellos. Esa es también la configuración que te permite usar Claude Code y Codex juntos en un mismo código base sin que ninguno de los dos se quede ciego en el traspaso, y encaja de forma natural con los worktrees, un checkout por tarea, para que los agentes en paralelo no colisionen.
La lista de comprobación que puedes ejecutar hoy
Recórrela en orden. Las tres primeras no cuestan nada; la cuarta es a la que asciendes cuando las tres primeras dejan de dar abasto.
- Unifica el archivo de reglas. Enlaza con enlaces simbólicos
CLAUDE.md,AGENTS.mdyGEMINI.mda una única fuente. Limítalo a convenciones de todo el repositorio, sin detalles de tareas. - Escribe una nota de traspaso antes de cada cambio. Objetivo, archivos modificados, qué se verificó, pregunta abierta. El agente actual puede redactarla; tú la pegas en el siguiente.
- Decide el cambio según la tarea, no por costumbre. Empareja el agente con el trabajo que tienes delante, usando una guía de enrutamiento en lugar de recurrir por defecto al terminal que tengas abierto.
- Saca el contexto de los agentes cuando las notas dejen de escalar. Cuando estés haciendo malabares con más de un par de agentes o repositorios, pon el objetivo, el estado y la revisión en una Tarea compartida, para que cambiar sea una reasignación y no una reexplicación.
Si ya usas varios agentes y vuelves a narrar el mismo contexto cada vez que cambias, ese es el problema en torno al cual está construido Sharkly: un único lugar donde las tareas, el progreso y los resultados de cada agente permanecen visibles, para que el contexto sobreviva al cambio.
