What Devin Desktop actually shipped
Three first-party statements matter here, and they come from three different pages.
The changelog dates the removal and names the replacement path for conversations. The migration prompt it points to is Continue in Devin Local, and what it carries over is conversations.
The Devin Local documentation is blunter about what does not carry over. Under Limitations:
"Memories — The Devin Local agent does not persist memories between sessions. Migrate your critical memories to skills with the Devin: Open Cascade Migration Wizard command."
"Workflows — Workflows are not available with the Devin Local agent."
And the Memories page explains where those memories were:
"Cascade's autogenerated memories are associated with the workspace they were created in and are stored locally in ~/.codeium/windsurf/memories/. Cascade retrieves them when it believes they're relevant. Memories generated in one workspace are not available in another, and they are not committed to your repository."Read those three together and the shape of the problem is clear. The memories were local to one machine, scoped to one workspace, and absent from version control. Nothing about that was hidden — it is all documented — but it means the accumulated knowledge had exactly one copy, in a directory nobody thinks about.
There is also a gap worth flagging, because it affects what you should do this week. The changelog's migration instruction covers conversations. The memories path, in both the Memories page and the Devin Local limitations, is a separate command named Devin: Open Cascade Migration Wizard — named after the agent the changelog says has been removed. As of this writing the Memories page still describes Cascade in the present tense. Two paths for two different things, and the documentation has not caught up with the release. If you have memories you care about, look at the machine they are on before you assume a wizard will still be there.
The removal was also not sudden, and the signal was in the conditional clauses. On July 29, models marked Devin Local only began showing as disabled in Cascade's model picker. On August 10, the release notes described hiding "Cascade-specific configuration and customization options when Cascade is disabled for your team." On August 21, Explain and Fix Problem began sending problems to Devin Local "when Cascade is disabled." For six weeks the changelog described behavior for a world in which Cascade was off, before the release that turned it off for everyone.
What this does and doesn't change
It is easy to over-read this, so let us be precise about what Devin Local does and does not carry.
Devin Local is not a tool without persistence. Its documentation says the opposite:
"The Devin Local agent does support rules and AGENTS.md files as well as skills for providing persistent context and reusable workflows."
It also writes planning artifacts to a stable location:
"The plan is written to a persistent Markdown file at ~/.devin/plans/plan-<session>.md, so you can edit it, come back to it later, or hand it to a fresh session."So the honest summary is narrow: Devin Local's persistence is file-based. Rules, AGENTS.md, and skills survive because they are files, and most of them are files in your repository. Plans survive as files too, though by default they land in your home directory rather than the project. What does not survive is the one mechanism where the agent, not you, decided what was worth keeping.
The rule folders themselves came through the transition intact, including their precedence order — .devin/rules preferred, .windsurf/rules as a fallback, and the legacy root file still read. If you have not sorted out which of those is actually winning in your repo, merging your Windsurf and Devin rule folders walks through consolidating them, and that work is now more valuable than it was a week ago, because rules are carrying more of the load.
What also does not change: the vendor's own recommendation, which has been sitting in the Memories page the whole time.
"For knowledge you want Cascade to reliably reuse, write it as a Rule or add it to AGENTS.md in your repo rather than relying on auto-generated Memories. Rules are version-controlled, shareable with your team, and give you explicit control over activation."That advice was written about reliability of retrieval, not about surviving a product decision. It turned out to be the right advice for both.
What people will take from this, and shouldn't
The reaction going around is that Cascade users need to hurry up and move to Devin Local, and that the lesson is to keep up with your editor's release notes. Both of those are true and neither is the interesting part.
The first thing to resist is treating this as one vendor retiring one feature. It is the third instance of the same pattern in recent months, and the other two come from vendors with no relationship to this one.
Kilo Code's documentation carries this notice:
"The Kilo Code memory bank feature has been deprecated in favor of AGENTS.md."
Its migration instruction is to move the memory bank content into the project's AGENTS.md, and its description of that file explains why:
"AGENTS.md is an open standard for configuring AI agent behavior in software projects... The standard is supported by multiple AI coding tools."
OpenHands went the other direction and arrived in the same place. Its persistent memory feature exists, and the documentation describes it as "opt-in and off by default," noting that without it "agents keep the existing AGENTS.md-based guidance and prompts are unchanged." A repository file is the default; agent-maintained memory is the thing you switch on.
Three independent teams, three products, one convergence: the durable container for project knowledge is a file in your repository, and the accumulating agent-side store is the layer that gets deprecated, made optional, or removed. That is not a criticism of any of them. An auto-generated store is genuinely useful — it captures things you would never bother to write down — and it is tied to a specific agent implementation, which is exactly the kind of thing product teams change.
The second thing to resist is concluding that skills are the answer because that is where the wizard was pointing. Skills are procedures the model invokes when it decides they are relevant — a good home for "how we run a release" and a poor home for "we rejected the other queue library in March because of the redelivery semantics." Why agent skills aren't memory covers that distinction, and it matters more when a migration path nudges you to flatten one into the other.
The third is the framing that this is a lock-in story. It partly is — whether AI memory is a feature or lock-in is a fair question to ask any vendor. But lock-in usually means you cannot get your data out. Here the files were always readable, in a documented path, on your own disk. The problem was not access. It was that nothing in the workflow ever moved them somewhere a second machine or a second teammate could see.
The Fix: Write the decision where the repo can carry it
The practical version of all this is a sorting exercise. Do it once and the next retirement is uneventful.
Step 1: Look at what the retired store actually holds
Before deciding where things go, read what accumulated. Cascade's memories sit in a documented directory on the machine that generated them, one set per workspace. Open them and sort each entry into three buckets: a standing instruction ("use bun, not npm"), a decision with a reason ("we moved off the ORM because of the migration story"), or a transient note about a task that finished months ago.
Most of what auto-generated stores accumulate is the third bucket, which is why these deprecations sting less than people expect. But the second bucket is the expensive one, and no repository file currently holds it, because nobody writes "why" into a rules file.
Step 2: Send standing instructions into the rules layer
Bucket one goes where the vendor said it should go: a rule in .devin/rules/, or your repository's AGENTS.md. Both are read by Devin Local, both are version-controlled, and both are read by other tools following the same convention. Keep each entry to a sentence or two, in the file whose activation mode matches how often it should apply.
One naming note, free to get right and silent to get wrong: Devin Desktop's documentation says both AGENTS.md and agents.md are recognized, but other tools reading the same convention require the uppercase filename. In a shared repository, use AGENTS.md.
Step 3: Give the reasons a home that is not a product surface
Bucket two has nowhere to go. A rules file is the wrong container — rules load on every session, so filling them with history is expensive, and the point of a rule is to be short and imperative. Skills are wrong too, for the reason above.
That content needs somewhere queryable, outside any one editor, that a teammate on a different tool can reach. It is the layer these deprecations keep pointing at, and the one thing none of the three vendors ships.
Setting this up in MemoryLake
MemoryLake is where the reasons live. It sits outside your editor and serves whichever agent asks, over MCP or the API, so a decision you record today is still answerable after the next agent surface is retired. Your rules and AGENTS.md stay in the repository exactly as Devin Local's documentation describes; the shared layer holds the part those files were never meant to carry.
Step 1: Create an API key
Generate a key and make your first request in about thirty seconds. Do this before you start sorting, so you have somewhere to put each reason as you read through the old memories.
Step 2: Upload your first memories
Work through bucket two entry by entry. For each decision, write down what was chosen, what was rejected, and why. Supporting documents — the architecture note, the incident writeup, the vendor comparison — go in the same place.
Step 3: Connect your AI & agents
Give Devin Local, Claude, Codex, and your other agents access over MCP or the API. When someone asks why the convention exists, the answer arrives with its reasoning attached instead of as a restated rule.
What this changes in practice
The first change is that a retirement stops being an emergency. When a vendor removes an agent surface, you check the repository and the shared layer, and both are still there.
The second is that the sorting only happens once. Everything you pulled out of Cascade's memories is now in a form the next tool reads on day one, which is the difference between a migration and a re-adoption.
The third is that new machines and new teammates start where you do. Cascade's memories were workspace-scoped and local, so a second checkout began empty. A repository file plus a queryable shared layer has no such asymmetry — the same problem Devin losing task context between sessions always came down to.
The fourth is that your rules files get shorter rather than longer. Once the reasoning has a home, a rule can be one imperative line, which is what the activation-mode system was built for.
Best practices for surviving a retired agent surface
Read the conditional clauses in release notes. Six weeks of "when Cascade is disabled" preceded "Cascade has been removed." Language about a feature being off is usually a schedule, not a hypothetical.
Treat anything not in version control as a single copy. A documented path on your own disk is not a backup or a handoff. If it matters and it is not committed, it exists once.
Do not let a migration wizard decide your information architecture. A guided flow moves content into whatever container the destination has. That is convenient, and not the same as the container being right.
Keep commands in files and reasons out of them. Standing instructions belong in the rules layer, loaded every session. History belongs somewhere retrievable on demand.
Check filename casing across tools. One vendor's case-insensitive matching is another's silent miss. Uppercase AGENTS.md is recognized everywhere that reads the convention.
Assume the auto-generated layer is the one that changes. Across three vendors this year it was deprecated, made optional, and removed.
Conclusion
Devin Desktop's changelog dates the removal of Cascade to the September 8, 2026 release, and the documentation is explicit that the agent replacing it does not persist memories between sessions while fully supporting rules, AGENTS.md, skills, and persistent plan files. All of that is documented and defensible. What it exposed is that most teams had never decided where their project reasoning lived — they let an agent accumulate it in a local directory and treated the result as a feature.
The fix is unglamorous and permanent. Standing instructions go in the repository, where the vendor has been telling you to put them for months. The reasons behind them go somewhere queryable that no single product surface owns. Do that, and the next release note retiring something is a paragraph you read with mild interest instead of a Monday spent reconstructing decisions.