Six months in, the assistant knows things. AI memory is the industry's name for that. Yours is probably closer to it finally gets how I work.
It knows you never quote a fixed price before the site visit. It knows the one client whose invoices go to a different address than everything else. It knows you want the summary first and the detail underneath, never the other way round. You didn't sit down and teach it any of that. It picked it up.
Then the price changes, or the plan you're on gets reorganised, or you just want to see whether the other one is better. And the question nobody gives you a straight answer to is: does any of that come with you?
Here's the straight answer. The part you typed moves. The part it worked out on its own doesn't.
That isn't an opinion, and it isn't a prediction. On 31 July 2026 I went through the official documentation of every major assistant and coding tool I could get to — what its memory stores, where that lives, whether you can see it, whether you can edit it, and whether there's any way to get it out. 14 mechanisms, grouped by how they work rather than by who sells them. The table is a few sections down. Not one of the vendor-hosted ones has a format you can hand to a different vendor.
Quick disambiguation before we go further: if you searched for ai memory looking for the physical kind — the chips Micron and Samsung sell into data centres — this isn't that. This is about what a chat assistant remembers about your business between conversations.
The fix is unglamorous and takes about 20 minutes. Decide what actually needs remembering, write it in plain files, and point the assistant at the files. By the end of this you'll have 4 short files, a one-page index, and a rule for what must never go in them.
Two kinds of memory, and only one of them is yours
Every product in this space blurs two completely different things under the same word. Separate them and most of the confusion goes away. In the table further down, 2 of the 14 rows are the first kind. The other 12 are the second.
The part you typed. A file sitting somewhere you control — your machine, your project folder, your document store. You wrote it. You can open it, read it, edit a line, delete a line, print it, email it to your bookkeeper. It is text.
The part it worked out. Notes the product wrote about you, held on the vendor's servers, generated from your conversations. You did not author it. Depending on the product you may be able to look at a summary of it, edit some of it, or delete it. You almost never get to hold it.
If you've read anything else about this, you've probably seen memory split up a different way — short-term versus long-term, or episodic versus semantic. That split is about how the storage works. It's the right cut if you're building the storage. It's the wrong cut if you're the one who might leave.
The distinction that matters to you is who wrote it, not which company you're with. Inside a single company the two can behave completely differently.
- Anthropic's desktop coding tool keeps its instructions as ordinary text files in your own project folder — fully yours. Its chat product keeps memory on Anthropic's servers as entries you can view but can't hand to anybody else.
- OpenAI runs two separate stores too: the memory behind the ChatGPT website, and a different local one used by its desktop coding client, sitting in a folder on your machine. Same account, two memories, different rules.
- Microsoft is the sharpest example. On the GitHub and VS Code side, Copilot's memory is hosted and opaque. In Visual Studio, the same feature was shipped by writing your preferences into a
copilot-instructions.md file on disk. One company, two products, opposite answers.
So the useful question is never "does this brand have good memory." It's "which of these two things am I relying on right now, for this particular rule?"
Take a rule that a lot of firms actually run on. In a law practice, the intake sequence is fixed: you collect only what the conflict check needs — names, entities, the other side, the other side's counsel, which court — and you do not let the person describe the matter until the check clears. That's not a preference. The duty to a prospective client attaches to what they tell you whether or not you take the case, and the resulting disqualification can be imputed to the whole firm (ABA Model Rule 1.18; the Kentucky Bar Association's published consultation form prints the warning at the top of the page).
If that rule lives only in the second kind of memory, then it lives on someone else's server, in a format nobody else reads, subject to a product decision you don't control. It is, functionally, a verbal understanding.
What actually moves when you switch
Here's the table. I built it by mechanism rather than by company, because as noted above, one company can sit in two different rows.
Checked 31 July 2026. Three grades: ✅ it's yours and another tool can read it; 🟡 you can see and edit it, but moving it means retyping; ❌ there's no user-facing way out at all.
| Mechanism |
Where it lives |
See it |
Edit it |
Get it out |
After you switch |
✅ Instruction files sitting in your own project folder — AGENTS.md, CLAUDE.md, GEMINI.md, .cursor/rules/, .github/copilot-instructions.md |
Your machine, next to the work |
Yes |
Yes |
Yes — they're just text files |
Still there. Often just a rename away |
| ✅ Claude Code auto memory |
~/.claude/projects/<project>/memory/ on your machine |
Yes (/memory) |
Yes — plain Markdown |
Yes |
Still there, but you carry it. Not shared across machines or cloud environments |
| 🟡 ChatGPT memory summary |
OpenAI's servers |
Yes — but officially incomplete |
Yes |
Copy the text by hand |
Gone. Retype, and you can't see everything to retype |
| 🟡 Custom instructions (ChatGPT, Cursor user rules, and equivalents) |
Vendor settings |
Yes |
Yes |
Copy by hand |
Gone. Short enough to retype |
| 🟡 Claude memory entries |
Anthropic's servers |
Yes, grouped by category |
Yes, item by item |
Ask it to print them; account export includes memory |
Gone. Re-import is lossy and flagged experimental |
| 🟡 Project knowledge (Claude Projects, ChatGPT Projects) |
Vendor's servers |
Yes |
Yes |
The source files were always yours |
Files survive. The project doesn't |
| 🟡 VS Code local memory tool |
Your machine, memories/ |
Yes |
Only clear-all — no deleting one entry |
Files are local |
You move them yourself |
| 🟡 Codex local memories |
~/.codex/memories/ |
Files are readable |
Officially don't hand-edit — it's generated state |
Local, but it's the tool's scratchpad |
Doesn't carry |
| 🟡 Gemini app saved info |
Google's servers |
Yes |
Yes |
Copy by hand |
Gone |
| 🟡 Gemini app memory / personal intelligence |
Google's servers |
Partly |
Can pause and delete |
Takeout gives you activity, not memory |
Gone |
| ❌ ChatGPT referencing past chats |
OpenAI's servers |
You can't see the whole picture |
Delete sources only |
None |
Gone |
| ❌ Copilot memory — repository facts |
GitHub-hosted |
Repo owner can view and delete |
Delete only |
No export |
Gone. Also deleted automatically after 28 days unused |
| ❌ Copilot memory — user preferences |
GitHub-hosted, owned by whoever pays for the licence |
You can view and delete |
Delete |
Only Business/Enterprise admins can export |
Gone. Change employer and they're unreachable |
| ❌ Cursor Memories |
— |
The feature was removed in a minor update |
— |
Export to Rules before it went |
The feature itself is gone |
Sources for every row: the vendors' own documentation — ChatGPT memory FAQ, Claude memory, Claude Code memory, Copilot memory, VS Code memory, Codex memories, Gemini CLI context files, Cursor rules.
Read the ✅ block and the ❌ block next to each other. Every green row is a plain text file in a folder. Every red row is something a company is holding for you.
Five facts that settle it
I don't need to argue this. Five things are true right now, each independently checkable.
1. A vendor deleted an entire memory feature in a minor update. Cursor shipped Memories in mid-2025, stored per project, manageable in settings. It's not there anymore. Staff on the company's own forum told a user asking where their memories went that the feature was intentionally removed, and that you could export them from the command palette and paste them into Rules by hand. Corroboration: the documentation site no longer has a memories page, and cursor.com/docs/memories returns 404. Caveat worth stating plainly — the only direct source is a staff reply in a public forum, because this vendor doesn't publish a full changelog.
2. The two biggest challengers built the same escape hatch, and it's copy-paste. Both Anthropic and Google shipped an "import your memory from another AI" flow. Both work identically: they hand you a suggested prompt, you paste it into the competitor's assistant, the competitor writes out a list of what it remembers about you in prose, you copy that, you paste it back. Both prompts ask the other model to be verbatim, not to summarise, not to group, not to leave anything out, and then to confirm whether that was everything. The whole transfer takes about 5 minutes and ends with you pressing paste.
That is the state of the art in 2026. If any usable API or file format existed, neither company would have chosen this.
3. One vendor admits you can't see all of it. OpenAI's memory FAQ states that the memory summary won't contain everything ChatGPT has remembered from your chats, and that if you want to know whether it remembers something specific, you should ask it in a conversation. Sit with that for a second: the thing you'd need to copy is not fully visible to you.
4. Some memory belongs to whoever pays for your licence. GitHub's agentic memory stores user-level preferences under the active billing entity — the organisation that issued your seat. It's recorded there and it's retrieved from there. Change employer and it isn't yours to take. Separately, both repository facts and user preferences are deleted automatically after 28 days without use.
5. OpenAI tells you to write the important things in a file. This is the one I'd put on a poster. In the Codex documentation on memories, the guidance is to put durable team conventions in AGENTS.md or a checked-in document, and to treat memories as a helpful recall layer rather than the only source of rules that must always apply.
The company that shipped the format is telling you not to trust its own memory feature with anything that matters. I agree, and I'd extend it to every product in that table, theirs included.
Four things worth writing down
So what actually goes in a file? Not everything. Four categories, and if something doesn't fit one of them, leave it out.
1. Fixed operating facts about a client or a job
Not the matter. The handling: which portal, which cutoff, which naming convention, who signs, what the memo line has to contain.
- Front office — this buyer's agreement has to be signed before any showing, including a live video walkthrough, and the compensation terms are in that one agreement rather than a lightweight touring form. (That timing became a nationwide requirement for MLS participants on 17 August 2024 under the NAR settlement.)
- Delivery — this client's files go out as one PDF per document, never a merged bundle, and the file name carries the source-language date format.
- Back office — statement lands on day 2, cutoff is day 6 at 17:00, and a memo line reading just "Deposit" gets rejected. It needs client, matter number, purpose, and what authorises it.
2. Decisions you made, and why you made them
The why is the part that gets lost. A rule without its reason gets "optimised" by the next person — or the next model — six months later.
## 2026-03-04 — Intake order is fixed: conflicts first, matter second
We take names, entities, the opposing party, opposing counsel and the court
before anyone describes what happened. We do not "just get the story first"
to save a phone call.
Why: the duty attaches to whatever a prospective client tells us whether or
not we take the case, and disqualification can be imputed to the whole firm.
Source: ABA Model Rule 1.18.
3. Things that went wrong once
This is the highest-value category and the one nobody keeps. One entry per incident, ending in the rule it produced.
## 2025-11 — We let the architect build the first punch list
What happened: we skipped our own walk-through and went straight to the
architect's. Fresh eyes found a page of items we would have caught. Substantial
completion slipped, and the warranty clock, the retainage release and the
one-year correction window all slid with it.
Rule now: we produce the list first. They verify and amend it. Never the
other way round.
Source: AIA A201-2017 section 9.8.2.
A note on why this category earns its keep. The ABA's Profile of Legal Malpractice Claims 2016–2019 breaks claims down by cause: substantive errors 51.93%, administrative errors 19.59% — inside which sit failure to calendar properly at 7.4% and clerical error at 4.08% — client relation errors 16.7% combined, and conflict of interest 4.9%. Add those last three together and more than 40% of these claims have nothing to do with knowing the law. It's sequence, calendar and communication. Those are exactly the things a written rule catches and a remembered impression doesn't.
4. Exceptions to your house wording
Every trade has phrases that must appear verbatim and phrases that must never be softened.
## Certification block — never paraphrase, never sign
The certificate must state that the translation is complete and accurate AND
that the translator is competent to translate from the source language into
English. Both parts. A notary stamping the signature is not enough on its own.
Draft it. Do not sign it — a person signs this.
Source: 8 C.F.R. 103.2(b)(3).
What does not belong in these files
This section is shorter than the last one and it will save you more trouble.
Anything that expires. Prices, staffing, a temporary workaround, "we're using the old portal until March." A stale rule in a file is worse than no rule, because the assistant will follow it with total confidence. If you must write something time-bound, put the expiry date in the heading and go back to it.
Live example of why: the FinCEN residential real-estate reporting rule was scheduled, then delayed to 1 March 2026, then vacated nationwide on 19 March 2026 by a federal court in the Eastern District of Texas, and FinCEN has appealed. Any file written in January that said "we file this" was wrong by spring. Any file that said "as of January 2026 we file this — recheck before relying on it" was still useful.
One-off details. What happened on one job, one invoice, one call. That's what your matter file is for. The memory folder is for things that repeat.
Anything confidential — and this one is not a style preference.
If you carry professional obligations, the surface you're writing onto is regulated. Three concrete examples, all published:
- The duty to a prospective client under Model Rule 1.18 covers any information, not just harmful information, and ABA Formal Opinion 512 (2024) extends that confidentiality duty to AI tools. A potential client's account of their dispute does not belong in a rules file, and it doesn't belong in a vendor's memory either.
- Under North Carolina Rule 1.15-3(i)(1), a lawyer must review the bank statements and cheque images for trust accounts every month, and the state bar's handbook says plainly that this review cannot be delegated. The reason given is specific: looking at the images yourself is how you notice a cheque made out to an employee. Write down that the review is yours. Don't write down the statement.
- Hiring a properly trained bookkeeper is allowed, and the California handbook is explicit that you remain personally responsible to your clients and the State Bar for the money regardless. Delegation of work is not delegation of responsibility. Same logic applies to delegating to a model.
And then there's the deletion problem. Getting something out of the second kind of memory is not one click. OpenAI's own guidance for fully removing a piece of information is to delete every place it appears — past conversations, archived conversations, uploaded files, the memory summary — and to disconnect any connected apps that might contain it. On the Anthropic side, resetting memory is permanent and includes per-project memory. Compare that to a file: you open it, you delete the line, you save. You can also read the whole thing before you hand it to a colleague, which is not a thing you can do with a hosted summary.
Build the folder in 20 minutes
Here's the thing you're building. Five files, all plain text with a few # marks for headings — that's all Markdown is — no special format, nothing to install.
my-work/
├── AGENTS.md ← the file it reads first (one new line goes in here)
└── memory/
├── README.md ← one-page index. The only file that must stay short
├── accounts.md ← fixed handling facts per client or job
├── decisions.md ← what we decided, and why
├── incidents.md ← what went wrong once, and the rule that came out of it
└── wording.md ← phrases that must not be changed
Step 1 — make memory/README.md and keep it under two screens. This is the file that gets loaded every time. Everything else is looked up when needed.
# What we've written down
Read this first. Open the other files only when the work touches them.
- `decisions.md` — standing decisions and the reason behind each. If a rule here
conflicts with a general best practice, the rule here wins.
- `incidents.md` — things that went wrong once. Each ends in a rule. Treat those
rules as non-negotiable.
- `wording.md` — phrases that must appear exactly as written. Never paraphrase
anything in this file.
- `accounts.md` — per-client handling: cutoffs, formats, who signs.
Rules for this folder:
- No client confidences, no matter details, no account numbers. Handling only.
- Every entry is dated. Anything time-bound says so in its heading.
- If something here is wrong, say so instead of working around it.
Step 2 — seed each file with three real entries. Not ten. Three. Use the four categories above. Ten minutes of "what did I retype into the chat this week?" will give you all three.
Step 3 — add one line to AGENTS.md. Whatever else is in that file, this goes near the top:
## Before you start
Read `memory/README.md`. It lists what we've already written down and when to
open the rest. If a rule in `memory/` contradicts anything else in this file,
the rule in `memory/` is newer and it wins. If you are about to do something a
rule covers and you have not read that rule, read it first.
Why AGENTS.md and not a name of your own choosing: it's the one filename a lot of different tools already look for without being told. It came out of OpenAI in August 2025 and was donated to the Linux Foundation's Agentic AI Foundation on 9 December 2025 — the same foundation Anthropic donated MCP to, and Block donated goose to. As of today the project's own site lists 23 named tools that read it. It's plain Markdown; the official FAQ answers "are there required fields?" with no.
Step 4 — put the folder where your assistant can see it. If you work in a chat product, that's a Project you upload the files into. If you work in an editor or a terminal, that's the top level of the folder you're already working in — the same place your other files live. The last section of this article has the hookup for each.
Step 5 — the next time you correct the assistant twice on the same thing, that's an entry. That's the whole maintenance routine, and it's deliberately the only one. Two corrections means you're looking at a rule you never wrote down. If you find yourself doing weekly reviews of your own memory files, you've built something too big to survive contact with a busy week.
Getting it read every time — and where that breaks
I'd be doing you a disservice if I stopped at step 5, because the honest position is that a file in a folder is not a guarantee.
Three things you should know before you build a habit on this:
Attaching isn't injecting. Anthropic's documentation for its coding tool states directly that instruction files and auto memory are treated as context, not enforced configuration, and that if you need to hard-stop an action regardless of what the model decides, you need a separate mechanism that runs before the action and can cancel it — not an instruction in a file. That framing is honest and it applies everywhere, including to products that don't say it out loud.
The chat products don't promise to read everything, every turn. Claude Projects doesn't let you upload a folder at all — files go in one at a time — and on paid plans, once the attached material gets close to what the model can hold, it starts looking things up on demand instead of holding all of it. ChatGPT Projects caps how many files you can attach per plan (5 on Free, 25 on Plus, 40 on the top tiers — and OpenAI's own help pages disagree with each other here, the Projects page saying 25 for Plus while the file uploads FAQ still says 20). Its wording is that it prioritises project files, which is not the same as loading them.
Even file-based memory truncates silently. Claude Code loads the first 200 lines or 25KB of its memory index, whichever comes first, and content past that is simply not loaded at session start. Codex stops appending project documents past a default of 32 KiB.
What to do about it, in order of how much it buys you:
- Keep the index short. Two screens. Everything else is a topic file it opens when it needs to. This is the single biggest thing you can do, and it's why the folder is structured that way.
- Write rules as instructions, not as description. "We produce the punch list first" beats "our approach to punch lists."
- Paste the index at the top of the session when the work is high-stakes. Ten seconds. On the days it matters, do it.
- Spot-check. Ask it a question whose correct answer only exists in your folder. If it gets it wrong, your file is too long or too buried.
[NEEDS REAL RUN: a measurement of how often the folder is actually reflected in the answer — the same rule-dependent question asked twenty times in each of two chat products, with a folder of a known size, counting how many answers show the rule. Without that number, everything in this section is documentation reading, not measurement.]
When the vendor's memory is fine to use
I've spent most of this article on what the hosted memory can't do, so let me be fair about what it's good at, because it's genuinely good at it.
It's effortless. You don't maintain it. It picks up the small stuff you'd never bother to write down — that you like short answers, that you work in a particular unit, that you keep saying "no bullet points." Anthropic's memory panel is the most transparent implementation I looked at: entries grouped by category, editable one at a time, deletable one at a time, and changes take effect on the next turn. That's a real product, well built.
So here's the line I'd draw, and it's a cost line rather than a principle:
If losing it means redoing work, it goes in a file. If losing it just means being mildly annoyed for a week, let the vendor keep it.
Tone preferences: let it remember. Which of your two email addresses gets the invoices: let it remember. The sequence you follow at intake, the reason you stopped doing something the obvious way, the sentence your certification has to contain: file.
Most people don't need to turn hosted memory off. They need to stop assuming it's a filing cabinet.
Instructions got a standard. Memory didn't.
Here's the part I find genuinely clarifying, and it's the reason I think this is worth the 20 minutes rather than none.
For instructions, this industry produced a working cross-vendor format. AGENTS.md went from a reaction to filename chaos in mid-2025 to a neutral default within months, and then into a foundation with OpenAI, Anthropic and Block as founding contributors. 23 named tools on the project's own site. Adoption at more than 60,000 as of the December 2025 donation announcement — a figure the project site hasn't revised since, and one worth reading as a floor rather than a current count, since the underlying search counts files rather than projects. No schema, no required fields, no version number. Plain Markdown.
For tools, this industry produced a working cross-vendor format too. MCP standardises how a model connects to outside tools and data. There are memory servers built on it, but those are implementations, not an interchange format — each one defines its own storage, so swapping servers has the same problem as swapping vendors.
For memory, there is nothing. I looked hard. The only thing that exists calling itself a cross-platform memory standard is a specification published in February 2026 by a single individual, with no standards body behind it and no vendor behind it. Its own text states that AI vendors do not natively support it, and describes its guidance on vendor export formats as best-effort rather than supported. It compares itself to vCard for contacts. vCard has been implemented by everybody for thirty years. This has been implemented by nobody for six months.
And look at how compatibility actually gets achieved in the absence of a standard: tools read each other's filenames. The Claude Code /init command reads Cursor's rules and Copilot's instructions files and folds them in. Copilot's cloud agent accepts CLAUDE.md and GEMINI.md. opencode, Zed, Warp, Devin's CLI and Amp all read CLAUDE.md in one way or another — while Claude Code itself doesn't read AGENTS.md at all. Compatibility is being hand-stitched, one filename at a time, in one direction.
And it's only ever happened at the file layer. Not once between two hosted memory systems.
That gap is the answer to the question this article opened with. You don't need me to tell you the hosted memory isn't yours. Look at what the industry built a standard for, and what it didn't.
I'm not a lawyer, a contractor, or a bookkeeper. I don't carry any of those obligations, and that's exactly why I can look at the file layer without defending anybody's product. What I did was take real published procedures — the ABA's intake sequence, a substantial-completion certificate and its punch list pulled out of a city council packet, a state bar's trust accounting handbook, the EU translation directorate's contractor quality pack — and turn them into folder entries. The entries in this article came out of that. If you do this work for a living, I'd genuinely like to know which of them is wrong.
Copy this prompt
Run this at the end of a working session. It reads what just happened and proposes entries. It does not write your files — you paste, so you stay the editor.
You are helping me maintain a folder of plain-text files that tell any AI
assistant how my business works. Today's session is above.
Go back through it and find anything that should be written down permanently.
Something qualifies only if all three are true:
1. It would still be true in six months.
2. If a new assistant did not know it, the work would come out wrong.
3. It is a rule, a decision, a format, or a past mistake — not a fact about one
specific matter, and not anything told to me in confidence.
For each item, output exactly this and nothing else:
FILE: (decisions.md | incidents.md | wording.md | accounts.md)
ENTRY:
## (date) — (one line, written as an instruction)
(two to four lines: what the rule is, and why it exists)
(source, if there is one)
Non-negotiable:
- Do not invent a reason. If you do not know why a rule exists, write
"reason not recorded - ask me" and stop there.
- Do not carry over names, matter numbers, addresses, account numbers, or
anything a client told me in confidence. Replace with (client) or (matter).
- Do not restate anything already in the files I gave you. Say "already
covered" and move on.
- If an item is only true for a limited time, put the expiry in the heading.
- If nothing qualifies, say "nothing to add". That is a valid answer.
List the items. Do not write the files yourself. I will paste them in.
Two notes. Give it your existing memory/ files first if you have them, or it'll re-propose things you already wrote. And read every proposed entry before it goes in — the reason clause is where a model will quietly make something up, which is why the prompt forbids it explicitly.
Receipts: what I checked, what I refused, what I didn't test
What I checked, and when. Everything in the table and the five facts came from vendor documentation read on 31 July 2026: the ChatGPT memory FAQ and data-export pages, the Codex memories and AGENTS.md pages, Anthropic's memory, memory import/export, data export and Projects articles, the Claude Code memory documentation, GitHub's Copilot memory concept page, the VS Code memory documentation, the Visual Studio devblog on Copilot memories, Cursor's rules documentation plus the forum thread about the removed feature, Gemini CLI's context file and commands references, Google's Gemini import and Takeout help pages, and the AGENTS.md project site. I counted the tool list on that site by hand the same day: 23 named tools, and Claude Code is not among them.
Where I quoted verbatim. One line, because it's the one people get wrong: Anthropic's documentation states, in its own AGENTS.md section, "Claude Code reads CLAUDE.md, not AGENTS.md." Two published third-party guides say the opposite. The vendor's page is the one to believe.
What I refused to write.
- I refused "export your account data and import it into the other one." I checked. Anthropic's own export article says exported data cannot be imported into another personal account of the same product. If it doesn't cross accounts inside one company, it isn't crossing companies.
- I refused to recommend a memory service. That swaps one dependency for another, and I haven't run one long enough to have anything worth saying.
- I refused to quote the ISO translation standard verbatim. The text costs money to obtain and I didn't buy it, so the requirement in this article is paraphrased from certification bodies rather than the standard itself.
- I refused "currently 60,000 projects." The number is from a December 2025 announcement, hasn't been updated since, and counts files rather than projects.
- I refused a widely-repeated claim about how early one chat product switches from loading files to looking them up. There's a user report with a specific number. It isn't confirmed by the vendor, so I've only said the behaviour exists.
What I did not test.
- [NEEDS REAL RUN: an actual move. Export memory from two hosted assistants, open what comes out, then set up the same work on a third product from scratch — recording exactly what had to be retyped, what could not be retrieved at all, and how long the whole thing took.]
- [NEEDS REAL RUN: a bill. What the same month of work costs on each of the products in the table, so the switching argument is grounded in a number rather than a principle.]
- [NEEDS REAL RUN: a six-week follow-up on the folder itself — which entries turned out to be wrong, which went stale, which were never read, and how many the assistant actually acted on.]
Until those exist, treat this article as a careful reading of the documentation plus a folder structure you can build today. It is not a report of a migration I performed.
| What you're using |
How to hook the folder up |
|
| Codex, Cursor, GitHub Copilot's coding agent, Windsurf, Zed, Amp, Devin, goose, opencode and the rest of the 23 tools on the standard's own list |
Put AGENTS.md and memory/ in the project root. Read automatically. |
✅ |
| Claude (web or desktop) |
Upload into a Project. No folder upload — one file at a time — and it isn't guaranteed to read all of them every turn. |
🟡 |
| ChatGPT (web) |
Add to a Project. Hard file limit per plan, and files are prioritised rather than loaded whole. |
🟡 |
| Claude Code |
Doesn't read AGENTS.md. Put @AGENTS.md on the first line of CLAUDE.md, or ln -s AGENTS.md CLAUDE.md. On Windows use the import — symlinks need admin rights. |
❌→🟡 |
| Gemini CLI |
Reads GEMINI.md by default. Set context.fileName in settings to point at AGENTS.md. |
❌→🟡 |
| Anything else |
Paste memory/README.md at the top of the conversation. Every time. |
🟡 |
| The memory layer — all of them |
No cross-vendor format exists. There is nothing to hook up. |
❌ |
✅ native · 🟡 works with a workaround · ❌ this one doesn't have it.
That last row is the point of the whole table.
Questions people actually ask
Does turning memory off make the assistant worse?
Only for the things you never wrote down. Anything in a file you attach is still there. What you lose is the convenience layer — small preferences it picked up that you never bothered to record. If that layer turns out to matter, that's a signal about what should have been in a file.
What happens if I move from a personal plan to a company one?
Depends on the vendor, and it isn't always reversible. Merging a personal ChatGPT account into a business workspace permanently deletes the personal workspace, and business workspaces can't export from settings. GitHub's Copilot memory ties user preferences to the billing entity that issued your seat, so changing employer puts them out of reach. Worth checking before, not after.
How long should the files be?
Shorter than feels right, because tools truncate quietly rather than warning you. Claude Code loads the first 200 lines or 25KB of its memory index. Codex stops appending project docs past a default 32 KiB. Windsurf caps global rules at 6,000 characters and workspace rules at 12,000 per file. Keep the index under two screens and let the topic files be long.
Do I need a dedicated memory tool?
Not to start. A memory service is another vendor with its own storage format, so it relocates the problem. Write the folder first. If you outgrow plain files you'll at least know precisely what you're asking a tool to hold.
We already have a written procedure. Do I copy it in?
No — you'll end up with two versions that drift. Leave the procedure where it lives and put two things in the memory file: a pointer to it, and the two or three decisions the procedure doesn't state out loud. Those unstated decisions are usually the part the assistant gets wrong.
Is AGENTS.md really meant for this?
Not as advertised. The format describes itself as being for coding agents; its docs, examples and tool list are all software-oriented, and nobody has published a method for professional-services use. But it's plain Markdown with no schema and no required fields, so there's nothing technical in the way. The gap is the reason to try it, not a reason not to.
Next
The piece before this one in the series covers the other half of the boundary question: which parts of the work you can hand over whole, which parts an assistant can only help with, and which parts have to stay with you because the responsibility does. The next one covers what to do when the folder gets big — how to split it up, and when splitting makes things slower instead of faster. Both link from here once they're up.
And yes, the folder moves. That's the whole reason to build it this way rather than teaching a product about your business for six months and hoping.
Want the version for people already living in a terminal? Two pieces on this site go further down the command-line road: a three-layer memory setup inside a self-hosted assistant runner, and a line-by-line treatment of the instruction file itself. Both assume you're comfortable in a shell. If you're not, the folder above is the whole job and you're already done.
Stay in the loop (no account signup)
This site does not ask you to create a product account. Free readers just leave an email—or follow where the build is posted.
| Channel |
What you get |
Where |
| Email (free) |
Occasional field notes as we pressure-test more systems in the wild. Articles on the site stay free. |
Open aiworkflowpro.com, scroll to Subscribe, enter your email, confirm the link in your inbox. |
| X |
Short ops notes and build-in-public updates |
@aiworkflowprolk |
| YouTube |
Longer industry-workflow rebuilds |
@aiworkflowprolk |
This article is free to read in full, and there's nothing gated behind an account. If you only want one next step: use the email box at the bottom of the site, or follow on X if you prefer the timeline.
— hh