Your project remembers. Do your projects learn from each other?

CRAFT for Claude Cowork · Cross-Project Transfer

The single-project continuity story — sessions that resume, work that carries forward — is told elsewhere on this site, with receipts. This post is about what happens at a project’s edges: where most knowledge goes to die, and why yours doesn’t have to.

If you have used CRAFT for Claude Cowork at all, you know the first promise: your AI stops forgetting. Sessions end, a handoff is written, the next session picks up exactly where you stopped — because the project’s state lives in plain files you own. Those pages make that case in detail — and leave one question open: what happens when you run more than one project?

Because for most tools — and most teams — the honest answer is: every new project starts naive. The hard lessons your last project paid for stay locked inside it. The conventions you settled, the failure you finally diagnosed at 11 p.m., the configuration that turned out to matter — all of it lives where it was learned, and nowhere else. Project two starts from zero. So does project five. Continuity that stops at a project’s border is only half of continuity.

CRAFT’s answer follows from the same design decision that makes single-project memory work: if state lives in files, state is portable. The framework ships a cross-project transfer registry — a recipe-governed way (a recipe is CRAFT’s unit of reusable, documented procedure, invoked in conversation) for one project to package what it knows into a transfer file, and for another project to receive it, record where it came from, and fold it into its own working knowledge. Transfers are files you can read. Each project’s registry keeps the accounting — what went out, what came in, from where — so inheritance is auditable, not folklore.

What that looks like on a real week

This is not a hypothetical — it happened to us while this post was being written. One of our projects runs a set of metrics automations it took real effort to get right: schedules, credential field names (no secrets), output formats, and a set of lessons learned the expensive way. A second, newer project needed the same capability. The request arrived as a message; the answer was one file — the task definitions, the exact formats, and ten hard-won lessons, exported from the first project’s records and delivered to the second project’s inbound-transfers folder. The new project received the source project’s recorded operating knowledge — down to the lessons — in an afternoon, with unrecorded details marked NOT RECORDED rather than guessed. And the handover moves the way transfers move here: exported from the source project’s records on request, delivered to the inbound folder the receiving recipe reads, then registered on receipt — the recipe-governed packaging and accounting steps the registry page documents.

Real lines from that file (the export covering the Google Analytics metrics tasks), lightly condensed and redacted — shown at the raw-export stage; the receiving project’s registry filing wraps it as a packet and records the inheritance.

How this would work in one of your projects

Say you have run a client-reporting project with CRAFT for six months. It has accumulated the things six months buys: the report formats your client actually reads, the data-source quirks you diagnosed the hard way, the conventions your sessions follow without being told, and a lessons file that remembers every mistake so you don’t have to. Now a second client signs, and you start a fresh project for them.

Without transfer, that new project knows none of it. With it, the move is three steps, in plain conversation:

In the older project, you ask Claude to export what the new project should inherit — not everything, just what you name: the format conventions, the data-source lessons, the working rules. It writes one transfer file from the project’s records — the recipe wraps it as a transfer packet — marking anything not recorded as NOT RECORDED instead of guessing; that last part is an export rule we hold ourselves to. You deliver that file to the new project’s inbound transfers folder (transfers/inbound/pending/) — it is a file; drag it. Then, in the new project, you ask Claude to receive it — registration happens automatically as part of the receiving recipe: the registry records what arrived and where it came from, and the knowledge folds into the new project’s own working files. From its first real session, the new client’s project behaves like a project that has read your last six months of records — because it has.

Do that across a few projects and the shape of the value becomes clear:

Why files are the whole trick

None of this needs a platform feature, an export API, or anyone’s permission — and that is the point. Because a CRAFT project’s knowledge is plain, versioned text on your machine, moving knowledge between projects is moving a file, and auditing an inheritance is reading one. The same property that makes your work survive between sessions makes it survive between projects — and, for what it’s worth, between machines, accounts, and AI model versions too.

So the continuity claim compounds: your first project gets a memory. Your second project gets a memory and an ancestor. The more projects you run this way, the less any new one starts from zero — not because anything is automatic, but because inheritance is a deliberate, recorded act: a file you move and a line the registry writes, instead of knowledge you rebuild.