Cascade shows up everywhere - in old repositories, articles, tutorial videos and a team's own notes. It was the main agent of the former Windsurf and over the years grew its own household: memories, workflows, rules, hooks, MCP, Arena and App Deploys. The application is already called Devin Desktop, yet half of the instructions you find still describe Cascade - and that throws you off from the first step.
The naive move is to read any such instruction as current and apply it to whichever agent is open now. Since the word "agent" is one, the executor seems to be one too: it says "turn on Turbo" or "put the file in .windsurf/workflows" - so you just do it in the current tab. The expectation is understandable: the brand changed, so the old thing simply moved under a new name.
It breaks on the fact that Cascade and Devin Local are two different agents, not one application under two signs. For new work Cognition recommends Devin Local; Cascade remains as a legacy of the Windsurf era - to read an old session, run a specific workflow or prepare a migration. The documentation calls Devin Local the successor to Cascade and a next-generation agent, and new tabs pick it by default; Cascade, when unavailable, sometimes serves as a fallback. An instruction written for Cascade either finds no matching mechanism in Devin Local or finds a different one, with different behavior, so behind the single word "agent" stand two executors with different permission models.
Belonging to Cascade is recognized by vocabulary. If an instruction says "Turbo", refers to .windsurf/workflows, to the legacy MCP marketplace or to memories in ~/.codeium/windsurf, it belongs to Cascade even if the window is already labeled Devin Desktop. That is more reliable than the brand: the application's name changed at once, while texts and habits change gradually, so the language of an instruction gives away its addressee more precisely than the window title.
Why both lines live at once. Cascade carries baggage that cannot be erased in a single release: accumulated memories, written workflows, configured MCP servers, a history of sessions. Devin Local was rewritten around explicit permissions, a sandbox and subagents and became the default agent for new tabs. Keeping Cascade nearby is the price of the transition: the old does not break immediately, but the new is already built on a different foundation. Part of what accumulated - Arena and App Deploys - is tied to Cascade altogether and has no direct mirror in Devin Local, so simply "switching all the commands at once" will not work: some of the old tooling has no new address yet.
A separate variable is team policy. In stable an administrator can fully disable Cascade; then its settings simply disappear, and an instruction meant for it becomes unexecutable in principle rather than "not working for some reason". So before hunting for a bug in the text of an instruction, it is worth checking whether the agent it addresses is available at all.
The cost of ignoring the distinction is concrete. A Cascade instruction is applied in Devin Local and yields the wrong result: the workflow does not launch by slash command, the memory is not picked up, the MCP server is not visible - and time goes into debugging a mechanism that does not exist in this environment. The reverse mistake is costly too: new work is started in Cascade out of habit, depriving you of a more economical and better-fenced agent. The silent version of this mistake is especially treacherous: the agent does not fail with a "not supported" message but quietly does the wrong thing - a workflow phrased as an ordinary prompt is simply run as a free-form task without the expected steps.
When Cascade is justified, the list is short and closed. Read and understand an old session. Run a workflow that has not yet been ported. Prepare and carry out a migration of memories, rules, workflows and MCP into a new home. In all other cases a new task is run by Devin Local, and Cascade is opened deliberately and temporarily, not because "that is how it was before".
You should check belonging before acting, not after a failure. First name the agent: which one the instruction is for - Cascade or Devin Local. Look at the selector and confirm which agent is chosen for the tab. Check team policy - whether Cascade is disabled. For a migration open the Cascade Migration Wizard rather than copying files by hand. These glances take a minute and remove most of the "why isn't it working" before launch.
The typical failure is treating a symptom on the wrong agent. "The workflow did not run" - because it belonged to Cascade while the tab opened Devin Local. "A memory was lost" - because it lives locally in the Cascade profile and does not migrate on its own. "The command is gone" - because the administrator disabled Cascade entirely. The sign is the same: an instruction was applied without naming which of the two agents it was written for. Name the agent first - and in most cases the discrepancy is explained right away.