How to Migrate From Amazon Q Developer to Amp Without Losing Context (2026)

Rule content transfers cleanly. Amazon Q's project rules are plain Markdown with no frontmatter — its documentation says a rule file "must be a Markdown file" and shows a body that is just prose. Amp's AGENTS.md is also plain Markdown. Concatenate your .amazonq/rules/*.md bodies into an AGENTS.md at the repository root and the content is intact.

Directory placement transfers, with a wider default. Amp's inclusion rules are worth reading twice:

"AGENTS.md files in the current working directory (or editor workspace roots) and parent directories (up to $HOME) are always included."

"Subtree AGENTS.md files are included when the agent reads a file in the subtree."

The subtree half is what you want — one instruction file per area, loaded when the agent touches that area. The parent-directory half is the one to check. If you keep repositories under a shared parent and there is an AGENTS.md anywhere on the path up to your home directory, it loads in every one of them. Amazon Q's documented rule location is {{project-root}}/.amazonq/rules, and its documentation does not describe a walk up into parent directories — so this reach is new when you arrive.

Filename fallback works in your favour. Amp documents: "If no AGENTS.md exists in a directory, but a file named AGENT.md (without an S) or CLAUDE.md does exist, that file will be included." So a repository that already carries a CLAUDE.md from another tool gets picked up per directory. Note the ranking — AGENTS.md first, the other two as fallbacks — which is the opposite of the ordering some agents publish.

Per-session rule selection has no destination. This is the real change. Your habit in Amazon Q is to open the Rules button and pick a subset for the task at hand. Amp has one always-on layer and one conditional mechanism, and the conditional one works differently: you @-mention a file from AGENTS.md, and that mentioned file can carry a globs frontmatter field. Amp's documentation: "Mentioned files with globs will only be included if Amp has read a file matching any of the globs," and "if no globs are specified, the file is always included when @-mentioned."

That is a two-step indirection — a mention in AGENTS.md, plus a glob in the mentioned file — and it is triggered by which files the agent reads, not by what you selected before starting. We wrote up that mechanism in detail in scoping Amp's instructions to the files they apply to; the point here is narrower. Your Amazon Q checkboxes were a statement about this task. Amp's globs are a statement about these paths. The two are not interchangeable, and rules you were selecting by task have to be re-expressed as rules about file paths, or accepted as always-on.

Your memory bank transfers as static files. Amazon Q can generate a memory bank — four files, product.md, structure.md, tech.md, and guidelines.md, written into a memory-bank subfolder under .amazonq/rules. Its documentation describes the mechanism plainly: the feature "analyzes key files in your project to create summary files that help Amazon Q understand your codebase without having to analyze the entire project each time you ask a question." Updating them means choosing Regenerate Memory Bank.

Amp's documented instruction surfaces are AGENTS.md files, skills, and plugins, and none of those pages describes a generation or regeneration step. So those four files become ordinary Markdown you maintain by hand, and three of them describe things the code already states. That distinction matters enough that we built a whole guide around it from the other direction, in migrating from Cursor to Amazon Q Developer. The short version: whatever a tool can regenerate from your repository was already in your repository. It is the fourth file, guidelines.md, that may contain decisions no parser could produce — and that is the one to carry across by hand.

Compaction behaves differently, and neither version is durable. Amazon Q documents /compact, a summary that "replaces the detailed conversation history in the context window," and adds two lines worth remembering: "your complete conversation history remains visible in the chat interface until the end of the current session," and "the detailed chat history will reset when you restart your IDE." Amp's documentation describes threads rather than a compaction command. Either way, the conversation is not the place to leave anything you need next week.

There is no session memory store to port. Amazon Q's memory bank is a generated set of repository summaries, not a record of what it learned about you. Amp's documentation index describes AGENTS.md, skills, and plugins as its customization surfaces and does not describe a per-session memory store. So there is no store-to-store migration on either side — which sounds like less work and is actually the reason this migration loses knowledge if you are not deliberate.

Step 1: Sort your rules by whether they are about a task or about a path

Open the Rules button in Amazon Q and write down, for each rule file, the sessions in which you actually check it. That list is the thing you are migrating, not the files.

Rules you check for every session go straight into the root AGENTS.md. These are the easy ones — house conventions, the build command, the review checklist.

Rules you check when working in a particular area become subtree AGENTS.md files. Put the frontend rule in the frontend directory. Amp loads it "when the agent reads a file in the subtree," which is closer to your checkbox behaviour than anything else on offer.

Rules you check by file type become @-mentioned files with globs. Add a mention line to AGENTS.md, then give the mentioned file a globs list. Two literal details will bite you here. Amp documents that "globs are implicitly prefixed with **/ unless they start with ../ or ./, in which case they refer to paths relative to the mentioned file" — so a bare *.ts matches everywhere, not just beside the file. And "@-mentions in code blocks are ignored, to avoid false positives," so a mention inside a fenced example does nothing.

Rules you check by task — "use the strict review checklist for this one" — have no clean destination. Decide per rule whether it becomes always-on or gets dropped, and record which you dropped. This category is where migrations quietly lose behaviour, because the rule file still exists and simply never applies.

Then verify. Amp ships a way to see the answer: "To see the agent files that Amp is using, select agents-md list from the command palette." Run it from the directory you actually work in, not the repository root, and check the list against what you expected — especially for parent-directory files you did not know you had.

Step 2: Deal with the memory bank and the home-directory reach

Two cleanups, both of which are easier now than in three months.

First, the memory bank. Read all four generated files and mark every sentence that a parser could not have produced from the repository. In product.md, structure.md, and tech.md that will be close to nothing — those are summaries of the code, and the code is still there. In guidelines.md it may be substantial, because Amazon Q lets you shape generation with a project rule, and teams often use that to inject standards rather than descriptions. Move the parser-proof sentences into AGENTS.md and delete the rest. Carrying three files of regenerated repository description into an always-on context layer costs you tokens on every request and tells the agent nothing it could not read.

Second, walk the path from your working directory to $HOME and list every AGENTS.md, AGENT.md, and CLAUDE.md on it. Amp's parent-directory inclusion goes all the way up, and its two $HOME/.config locations — $HOME/.config/amp/AGENTS.md and $HOME/.config/AGENTS.md — are "always included if they exist." So are the system-wide files at /etc/ampcode/AGENTS.md, /Library/Application Support/ampcode/AGENTS.md, or %ProgramData%\ampcode\AGENTS.md depending on your platform.

If your organization deploys one of those system files, your effective instruction set is larger than your repository, and nothing in the repository records that. Note what is there before you start debugging behaviour you cannot find a cause for. The general form of that exercise is auditing what your AI actually remembers.

The rules you selected by task are the ones this migration cannot carry, and they are also the most valuable ones. A rule you apply to every file is usually a convention. A rule you apply to this change is usually a judgement — and judgements have reasons.

MemoryLake holds those: the decision, what it applies to, what it rules out, and why. It is not path-scoped and not session-scoped, so a rule that was only ever meaningful in context keeps its context. Get started here.

Step 1: Create an API key

Create a workspace for the repository and generate an API key. Keep the scope at the repository level so the layer is not tied to either tool's configuration directory.

Step 2: Upload your first memories

Start with the task-level rules you could not place in Step 1 — the ones you were checking selectively. For each, record what it applies to and why it exists. Then add anything from guidelines.md that survived your parser test, plus the decisions you made during this migration: which rules became always-on, which became globs, and which you dropped.

Step 3: Connect your AI & agents

Connect Amp, and keep Amazon Q connected while both are in use. Both read the same decision set, so a rule you have not re-expressed as a glob yet still has its reasoning available.

You stop losing the selective rules. The rules you were checking situationally are the first casualty of any move to an always-on model, because nothing errors when they stop applying — they simply become files nobody reads.

Your always-on layer stays small. Instead of concatenating everything including three files of regenerated repository description, you carry the parser-proof sentences and leave the rest.

Debugging gets a starting point. When Amp behaves in a way your repository does not explain, you have a written list of the parent-directory and system files on your path, and agents-md list to confirm it.

And you re-explain less. The recurring cost of a lost rule is a person restating it in a prompt, which is the pattern described in how to stop re-explaining context to your AI. A rule that is always-on or glob-triggered does not need restating. A rule that quietly stopped applying needs restating forever.

Run agents-md list from three different directories in the first week. The result changes with your working directory, and that is the whole point of the subtree mechanism.

Prefer subtree files over globs when the boundary is a directory. Fewer moving parts, no implicit **/ prefix to reason about, and the file sits where the person editing that code will find it.

Give each glob-scoped file one job. Amp includes a mentioned file when any glob matches, so a file covering four unrelated patterns loads four times as often as it needs to.

Keep personal preferences out of the shared path. $HOME/.config/amp/AGENTS.md is always included in every project you open. That is the right place for device-specific commands and the wrong place for opinions your colleagues have not agreed to. Amp's own table says as much, listing that location for "personal preferences, device-specific commands, and guidance that you're testing locally before committing to your repository."

Split large subprojects deliberately. Amp's recommendation is to keep "the top-level AGENTS.md general" and create "more specific AGENTS.md files in subtrees for each subproject." That is also the cheapest way to approximate what the Rules button was doing for you.

If you later move on again, the inventory you built here is what makes it cheap — the same inventory that makes migrating from Amp to Codex a file exercise rather than an archaeology exercise, and the same one behind migrating from Claude Code to Amp.

Amazon Q hands you a checkbox and asks you to curate. Amp hands you an inclusion rule that reaches from your working directory up to $HOME and asks you to be careful about what you leave on that path. Both are defensible designs. Neither is a superset of the other.

The migration that goes well starts by writing down which rules you were selecting and why — before the files move, while the answer is still in your head. The migration that goes badly copies four files, deletes a checkbox, and discovers six weeks later that the rule about the payments module has not applied since the switch.