Project interfaces like Claude Projects and ChatGPT Projects are convenient because everything lives in one place. That convenience is also what makes them hard to change, because the pieces inside move at very different rates. This post takes an idea from Stewart Brand about how buildings age, and applies it to an afternoon spent moving files onto a disk.
You ask Claude for the context files you have been refining inside a Project for six months. It cannot hand them over, because a Project has no export, no download and no file on a disk you own. The instructions are in there, doing their job perfectly well. They just won't come out.
What I wanted was pretty basic: all my context files and instructions, in a folder on my computer, readable by any AI agent. Not a migration. A copy. So what do you do when the tool holding your working knowledge will not hand it back? Rewrite it from scratch? Reconstruct it from memory and hope you remember the awkward bits?
Stewart Brand has a name for what is going wrong here. In How Buildings Learn he describes shearing layers, an idea he takes from the architect Frank Duffy. A building is not one object but several, each ageing at a different rate. Site outlasts structure, structure outlasts electrical wiring, wiring outlasts the furniture.
Your AI setup has the same multi-speed problem. Instructions change most weeks. The model and the provider will change most years, maybe more often than that. Plain text on a disk has not changed since the 1970s and will comfortably outlive both.
The problem is not that the Claude Projects interface is bad. It is good, and that is precisely the trouble: it holds all these layers in one place and makes them feel like a single object. Brand's version of this is services cast into concrete - where new plumbing means structural demolition.
One of Brand's favourite examples is MIT's Building 20, thrown up in six months in 1943 for radar work and slated for demolition almost immediately. It was plywood, but it stood for fifty-five years. The people inside knocked holes in the walls whenever they needed to run cable, because nobody was precious enough about the place to stop them.
What came out of it outlasted the building: microwave radar and the LORAN navigation system, Edgerton's stroboscopic photography, the loudspeaker work that became Bose, and the linguistics department Noam Chomsky and Morris Halle founded there in 1976. The New York Times counted nine Nobel laureates among the four thousand researchers who passed through.
Brand called that a Low Road building: cheap, ugly, unloved, and modified constantly for exactly those reasons. A folder of markdown files is a Low Road building. It has no product manager and nothing in it is anyone's design, which is precisely why you will keep changing it.
“
“It turned out to be absolutely perfect for research. You can knock down a wall, you can punch out a ceiling, and you could get space. In academics, space is everything.”
Another of Brand's points about buildings is that every one of them is a prediction about how it will be used, and predictions are often wrong. The workflow you designed in March may well be outdated by August.
The firms that get this right standardise the slow layers and let the fast ones move: one agreed location, one file format, one owner. What people write inside stays theirs to change. A versioned text file is easier to review than anything locked inside a vendor's interface.
Ask the next tool for your instructions and it reads them straight off the disk. Nothing needs recovering. Building 20 finally came down in 1998. Everything that mattered had already moved out.
☳
“The firms that get this right standardise the slow layers and let the fast ones move”
Start with the context files(1) you cannot download. Ask the model to rebuild them from whatever it can still see of the project, then read the result properly, because it will probably be close rather than right. It warned me about the token cost while it worked. I was paying, in tokens, to get my own files out of the interface.
Then put the custom instructions(2) in an AGENTS.md file at the folder root. It's a convention rather than a product, which is why Codex, Cursor and Copilot all read it without being told. Add a CLAUDE.md beside it holding one line: a pointer to AGENTS.md and an instruction to follow it. Two files. Neither of them in an inaccessible proprietary format.
Memory is the complicated bit. A Claude Project keeps its own, sealed off from your other chats, and rewrites it as you work: your role, your preferences, where the project has got to.
Copy the project memory(3) into a MEMORY.md and you have the content but not the habit, because the interface was updating it for you and a folder will not. So write the maintenance rules into the file itself: when to write, when not to, and how to edit in place rather than append.
The quickest way to get those rules is to ask for them. This is roughly what I sent:
I want to migrate the context of this project out of here and into a series of markdown files I can use with Cowork. I can get the context files into a directory, I can update the CLAUDE.md with my instructions. How do I migrate the memory to a new MEMORY.md file and give instructions for it to be kept up to date?You end up with a folder on your hard drive looking like this:
/folder root/
AGENTS.md
CLAUDE.md
context/
example file.pdf
example file.doc
MEMORY.md
❝
“Not marble nor the gilded monuments
Of princes shall outlive this powerful rhyme”
If you would like to find out more about working effectively with AI, please do get in touch.