Cambiar de agentes de codificación no debería significar empezar de nuevo — pero para la mayoría de los equipos sí lo es, porque el contexto residía en el agente, no en el repositorio. Aquí le mostramos cómo migrar sin perder la memoria del proyecto.
El problema de migrar entre agentes de codificación — Claude Code a Codex, Cursor a Gemini — no es el cambio de agente. Es que el contexto del proyecto residía en el chat del agente, no en el repositorio, y cambiar de agente significa restablecerlo desde cero.
Lo primero: el contexto en el repositorio, no en el chat
Comience con el fin en mente: el contexto del proyecto — la arquitectura, las convenciones, las decisiones, el estado en curso — reside en el repositorio, no en el chat del agente. Una migración entre agentes es entonces un cambio, no un reinicio, porque el contexto es portátil.
- Documentos de arquitectura en el repositorio.
- Convenciones y decisiones documentadas.
- Estado en curso capturado en el repositorio, no en el chat.
- El agente hereda el repositorio, no al revés.
La lista de verificación para la migración
- **Contexto en el repositorio.** Los documentos, las convenciones, las decisiones — todo en el repositorio, no en el chat.
- **Un plano de control compartido.** Un registro que abarca agentes, para que la migración conserve el historial de la sesión.
- **Una primera tarea pequeña.** La primera tarea en el nuevo agente es pequeña, para que pueda confirmar que hereda el contexto.
- **Un retroceso.** Si el nuevo agente no se ajusta, puede volver atrás sin perder el trabajo.
Qué rechazar
- Una migración que asume que el nuevo agente "recogerá" el contexto (no lo hará, a menos que esté en el repositorio).
- Una migración sin retroceso.
- Una migración que desecha el registro del agente antiguo.
- Una migración realizada primero en una tarea grande.
La historia que hace que la migración sea segura
La historia es el repositorio que lleva el contexto. Un equipo que puede cambiar de agentes porque el contexto está en el repositorio es un equipo que no está cautivo de ningún agente — y ese es el equipo que puede adoptar la herramienta adecuada para cada trabajo, en lugar de la herramienta a la que está atado.
Cómo lo enmarca FACTA
NEST de FACTA es el plano de control que hace que la migración sea segura — un servidor Rust, un registro, cada agente de codificación rinde cuentas a él. El contexto reside en el repositorio y el plano de control; el agente es el trabajador, no la memoria. Una migración es entonces un cambio, no un reinicio.
Conclusión
Migrar entre agentes de codificación sin perder el contexto significa que el contexto reside en el repositorio y en un plano de control compartido, no en el chat del agente. Migre con el repositorio llevando la memoria, una primera tarea pequeña y un retroceso — y el cambio es un cambio, no un reinicio.
Acerca de FACTA
FACTA ayuda a startups y equipos en fase de crecimiento a convertir la IA en sistemas de producción que siguen funcionando — no en demos que impresionan una sola vez.
Diseñamos la arquitectura en torno a las partes que realmente fallan bajo uso real: herramientas propias, credenciales que usted controla, conmutación por error, controles de costos, observabilidad. La infraestructura aburrida que mantiene un sistema vivo después del lanzamiento.
Dirigidos por Matías Baglieri y Carolina Fogliato, nos enfocamos en una cosa:
Liderazgo en IA que construye. No solo asesora.
Díganos a qué agente está migrando.
Le diremos qué poner primero en el repositorio para que no empiece de cero. Consulte el plano de control NEST para el lado del registro compartido.
Explorar la automatización de IA