Cómo migrar de Amazon Q Developer a Amp sin perder el contexto (2026)

El contenido de las reglas se transfiere limpiamente. Las reglas de proyecto de Amazon Q son Markdown plano sin frontmatter; su documentación dice que un archivo de regla "debe ser un archivo Markdown" y muestra un cuerpo que es solo prosa. AGENTS.md de Amp también es Markdown plano. Concatena los cuerpos de tus archivos .amazonq/rules/*.md en un archivo AGENTS.md en la raíz del repositorio y el contenido quedará intacto.

La ubicación de los directorios se transfiere, con un valor predeterminado más amplio. Vale la pena leer dos veces las reglas de inclusión de Amp:

"Los archivos AGENTS.md en el directorio de trabajo actual (o en las raíces del espacio de trabajo del editor) y en los directorios padres (hasta $HOME) siempre se incluyen."

"Los archivos AGENTS.md de subárboles se incluyen cuando el agente lee un archivo en el subárbol."

La parte del subárbol es lo que deseas: un archivo de instrucciones por área, cargado cuando el agente interactúa con esa área. La parte del directorio padre es la que debes revisar. Si guardas repositorios bajo un directorio padre compartido y hay un AGENTS.md en cualquier parte de la ruta hacia tu directorio de inicio, se cargará en cada uno de ellos. La ubicación documentada de las reglas de Amazon Q es {{project-root}}/.amazonq/rules, y su documentación no describe una búsqueda hacia arriba en los directorios padres, por lo que este alcance es nuevo al llegar aquí.

La alternativa de nombre de archivo funciona a tu favor. Amp documenta: "Si no existe un AGENTS.md en un directorio, pero sí existe un archivo llamado AGENT.md (sin la S) o CLAUDE.md, ese archivo se incluirá". De modo que un repositorio que ya contiene un CLAUDE.md de otra herramienta se detectará por directorio. Ten en cuenta el orden de prioridad: AGENTS.md primero, los otros dos como alternativas, que es lo opuesto al orden que publican algunos agentes.

La selección de reglas por sesión no tiene un destino equivalente. Este es el verdadero cambio. Tu hábito en Amazon Q es abrir el botón de Reglas y elegir un subconjunto para la tarea en cuestión. Amp tiene una capa siempre activa y un mecanismo condicional, y el condicional funciona de manera diferente: mencionas con @ un archivo desde AGENTS.md, y ese archivo mencionado puede llevar un campo globs en su frontmatter. La documentación de Amp: "Los archivos mencionados con globs solo se incluirán si Amp ha leído un archivo que coincida con alguno de los globs", y "si no se especifican globs, el archivo siempre se incluye cuando se menciona con @".

Esa es una indirección de dos pasos: una mención en AGENTS.md, más un glob en el archivo mencionado, y se activa según los archivos que lee el agente, no por lo que seleccionaste antes de comenzar. Explicamos ese mecanismo en detalle en scoping Amp's instructions to the files they apply to; el punto aquí es más específico. Tus casillas de verificación de Amazon Q eran una declaración sobre esta tarea. Los globs de Amp son una declaración sobre estas rutas. Ambos no son intercambiables, y las reglas que seleccionabas por tarea deben reexpresarse como reglas sobre rutas de archivos, o aceptarse como siempre activas.

Tu banco de memoria se transfiere como archivos estáticos. Amazon Q puede generar un banco de memoria: cuatro archivos, product.md, structure.md, tech.md y guidelines.md, escritos en una subcarpeta memory-bank bajo .amazonq/rules. Su documentación describe el mecanismo claramente: la función "analiza archivos clave en tu proyecto para crear archivos de resumen que ayudan a Amazon Q a comprender tu base de código sin tener que analizar todo el proyecto cada vez que haces una pregunta". Actualizarlos significa elegir Regenerate Memory Bank.

Las superficies de instrucción documentadas de Amp son los archivos AGENTS.md, las habilidades (skills) y los complementos (plugins), y ninguna de esas páginas describe un paso de generación o regeneración. Por lo tanto, esos cuatro archivos se convierten en Markdown ordinario que debes mantener a mano, y tres de ellos describen cosas que el código ya declara. Esa distinción es lo suficientemente importante como para que hayamos creado una guía completa al respecto desde la otra perspectiva, en migrating from Cursor to Amazon Q Developer. La versión corta: lo que una herramienta puede regenerar a partir de tu repositorio ya estaba en tu repositorio. Es el cuarto archivo, guidelines.md, el que puede contener decisiones que ningún analizador podría producir, y ese es el que debes transferir manualmente.

La compactación se comporta de manera diferente y ninguna versión es duradera. Amazon Q documenta /compact, un resumen que "reemplaza el historial de conversación detallado en la ventana de contexto", y añade dos líneas que vale la pena recordar: "tu historial de conversación completo permanece visible en la interfaz de chat hasta el final de la sesión actual" y "el historial de chat detallado se restablecerá cuando reinicies tu IDE". La documentación de Amp describe hilos (threads) en lugar de un comando de compactación. De cualquier manera, la conversación no es el lugar para dejar nada que necesites la próxima semana.

No hay un almacén de memoria de sesión para migrar. El banco de memoria de Amazon Q es un conjunto generado de resúmenes de repositorios, no un registro de lo que aprendió sobre ti. El índice de documentación de Amp describe AGENTS.md, habilidades y complementos como sus superficies de personalización y no describe un almacén de memoria por sesión. Por lo tanto, no hay una migración de almacén a almacén en ningún lado, lo que suena a menos trabajo pero en realidad es la razón por la cual esta migración pierde conocimiento si no eres deliberado.

Paso 1: Clasifica tus reglas según si se refieren a una tarea o a una ruta

Abre el botón de Reglas en Amazon Q y anota, para cada archivo de regla, las sesiones en las que realmente lo marcas. Esa lista es lo que estás migrando, no los archivos.

Las reglas que marcas para cada sesión van directamente al AGENTS.md raíz. Estas son las fáciles: convenciones internas, el comando de compilación, la lista de verificación de revisión.

Las reglas que marcas cuando trabajas en un área en particular se convierten en archivos AGENTS.md de subárbol. Coloca la regla del frontend en el directorio del frontend. Amp la carga "cuando el agente lee un archivo en el subárbol", lo cual es lo más cercano a tu comportamiento de casilla de verificación que hay disponible.

Las reglas que marcas por tipo de archivo se convierten en archivos mencionados con @ que contienen globs. Añade una línea de mención a AGENTS.md, luego dale al archivo mencionado una lista de globs. Dos detalles literales te darán problemas aquí. Amp documenta que "los globs tienen el prefijo implícito **/ a menos que comiencen con ../ o ./, en cuyo caso se refieren a rutas relativas al archivo mencionado", por lo que un simple *.ts coincide en todas partes, no solo al lado del archivo. Y "las menciones con @ en bloques de código se ignoran para evitar falsos positivos", por lo que una mención dentro de un ejemplo delimitado no hace nada.

Las reglas que marcas por tarea —"usa la lista de verificación de revisión estricta para esta tarea"— no tienen un destino claro. Decide por cada regla si se vuelve siempre activa o si se descarta, y registra cuál descartaste. Esta categoría es donde las migraciones pierden comportamiento silenciosamente, porque el archivo de regla sigue existiendo pero simplemente nunca se aplica.

Luego verifica. Amp ofrece una forma de ver la respuesta: "Para ver los archivos de agente que Amp está utilizando, selecciona agents-md list en la paleta de comandos". Ejecútalo desde el directorio en el que realmente trabajas, no desde la raíz del repositorio, y compara la lista con lo que esperabas, especialmente para los archivos de directorios padres que no sabías que tenías.

Paso 2: Aborda el banco de memoria y el alcance del directorio de inicio

Dos limpiezas, ambas más fáciles de hacer ahora que en tres meses.

Primero, el banco de memoria. Lee los cuatro archivos generados y marca cada frase que un analizador no podría haber producido a partir del repositorio. En product.md, structure.md y tech.md eso será casi nada; esos son resúmenes del código, y el código sigue ahí. En guidelines.md puede ser sustancial, porque Amazon Q te permite moldear la generación con una regla de proyecto, y los equipos a menudo usan eso para inyectar estándares en lugar de descripciones. Mueve las frases a prueba de analizadores a AGENTS.md y elimina el resto. Llevar tres archivos de descripción de repositorio regenerada a una capa de contexto siempre activa te cuesta tokens en cada solicitud y no le dice al agente nada que no pudiera leer por sí mismo.

Segundo, recorre la ruta desde tu directorio de trabajo hasta $HOME y enumera cada AGENTS.md, AGENT.md y CLAUDE.md que encuentres. La inclusión de directorios padres de Amp llega hasta arriba, y sus dos ubicaciones en $HOME/.config —$HOME/.config/amp/AGENTS.md y $HOME/.config/AGENTS.md— "siempre se incluyen si existen". También lo hacen los archivos de todo el sistema en /etc/ampcode/AGENTS.md, /Library/Application Support/ampcode/AGENTS.md o %ProgramData%\ampcode\AGENTS.md según tu plataforma.

Si tu organización implementa uno de esos archivos del sistema, tu conjunto de instrucciones efectivo es más grande que tu repositorio, y nada en el repositorio lo registra. Toma nota de lo que hay allí antes de comenzar a depurar comportamientos para los cuales no encuentras una causa. La forma general de ese ejercicio es auditing what your AI actually remembers.

Las reglas que seleccionabas por tarea son las que esta migración no puede trasladar, y también son las más valiosas. Una regla que aplicas a cada archivo suele ser una convención. Una regla que aplicas a este cambio suele ser un juicio, y los juicios tienen motivos.

MemoryLake guarda esos elementos: la decisión, a qué se aplica, qué descarta y por qué. No está limitado por rutas ni por sesiones, por lo que una regla que solo tenía sentido en contexto conserva su contexto. Comienza aquí.

Paso 1: Crea una clave de API

Crea un espacio de trabajo para el repositorio y genera una clave de API. Mantén el alcance a nivel de repositorio para que la capa no esté vinculada al directorio de configuración de ninguna de las dos herramientas.

Paso 2: Sube tus primeras memorias

Comienza con las reglas a nivel de tarea que no pudiste ubicar en el Paso 1, las que estabas marcando selectivamente. Para cada una, registra a qué se aplica y por qué existe. Luego añade cualquier elemento de guidelines.md que haya sobrevivido a tu prueba de analizador, además de las decisiones que tomaste durante esta migración: qué reglas pasaron a ser siempre activas, cuáles se convirtieron en globs y cuáles descartaste.

Paso 3: Conecta tu IA y agentes

Conecta Amp y mantén Amazon Q conectado mientras ambos estén en uso. Ambos leen el mismo conjunto de decisiones, por lo que una regla que aún no hayas reexpresado como un glob seguirá teniendo su razonamiento disponible.

Dejas de perder las reglas selectivas. Las reglas que revisabas según la situación son la primera víctima de cualquier cambio a un modelo siempre activo, porque nada falla cuando dejan de aplicarse: simplemente se convierten en archivos que nadie lee.

Tu capa siempre activa se mantiene pequeña. En lugar de concatenar todo, incluidos tres archivos de descripción de repositorio regenerada, conservas las frases a prueba de analizadores y dejas el resto.

La depuración obtiene un punto de partida. Cuando Amp se comporta de una manera que tu repositorio no explica, tienes una lista escrita de los archivos del sistema y de directorios padres en tu ruta, y agents-md list para confirmarlo.

Y vuelves a explicar menos cosas. El costo recurrente de una regla perdida es que una persona tenga que volver a formularla en una instrucción (prompt), que es el patrón descrito en how to stop re-explaining context to your AI. Una regla que está siempre activa o que se activa mediante un glob no necesita ser reformulada. Una regla que silenciosamente dejó de aplicarse necesita ser reformulada para siempre.

Ejecuta agents-md list desde tres directorios diferentes en la primera semana. El resultado cambia según tu directorio de trabajo, y ese es precisamente el propósito del mecanismo de subárbol.

Prefiere los archivos de subárbol sobre los globs cuando el límite sea un directorio. Menos piezas móviles, sin prefijos implícitos **/ sobre los que razonar, y el archivo se ubica donde la persona que edita ese código lo encontrará.

Asigna una sola tarea a cada archivo con alcance de glob. Amp incluye un archivo mencionado cuando cualquier glob coincide, por lo que un archivo que cubre cuatro patrones no relacionados se cargará cuatro veces más a menudo de lo necesario.

Mantén las preferencias personales fuera de la ruta compartida. $HOME/.config/amp/AGENTS.md siempre se incluye en cada proyecto que abres. Ese es el lugar adecuado para comandos específicos del dispositivo y el lugar equivocado para opiniones que tus colegas no han acordado. La propia tabla de Amp lo indica, listando esa ubicación para "preferencias personales, comandos específicos del dispositivo y guías que estás probando localmente antes de enviarlas a tu repositorio".

Divide los subproyectos grandes de manera deliberada. La recomendación de Amp es mantener "el AGENTS.md de nivel superior general" y crear "archivos AGENTS.md más específicos en subárboles para cada subproyecto". Esa es también la forma más económica de aproximarse a lo que el botón de Reglas hacía por ti.

Si más adelante decides migrar de nuevo, el inventario que construiste aquí es lo que lo hará económico; el mismo inventario que hace que migrating from Amp to Codex sea un ejercicio de archivos en lugar de un ejercicio de arqueología, y el mismo detrás de migrating from Claude Code to Amp.

Amazon Q te entrega una casilla de verificación y te pide que selecciones. Amp te entrega una regla de inclusión que se extiende desde tu directorio de trabajo hasta $HOME y te pide que tengas cuidado con lo que dejas en esa ruta. Ambos son diseños defendibles. Ninguno es un superconjunto del otro.

La migración que sale bien comienza por anotar qué reglas estabas seleccionando y por qué, antes de mover los archivos, mientras la respuesta aún está en tu cabeza. La migración que sale mal copia cuatro archivos, elimina una casilla de verificación y descubre seis semanas después que la regla sobre el módulo de pagos no se ha aplicado desde el cambio.