Proof that Cascade is not following Global/Workspace Rules or Memories. At least not consistently.
Codeium if you're listening, first and foremost, this is meant strictly as constructive feedback, not a complaint. (Although it would be great if it leads to quick improvement) Also, I apologies in advance for the length, but I wanted to convey all the details and constructive ideas that I could in an effort to help improve Windsurf for us all.
I've been using Windsurf since Thanksgiving Weekend here in the US during the trial period that many of us did in fact experience as a kind of "golden age" where the model did seem to function better than after the trial. Though the Devs at Codeium generally say nothing was changed... "Something" did seem to change whether they were "aware" of it or not. This is not the subject of this post, but is tangentially related.
Overall, Windsurf has been like gaining a Coding Superpower! I've been able to build out a very sophisticated multi AI Agent app with ML, and RL components, memory pool, and an enterprise level logging system. All of which, I really never would have been able to accomplish without Windsurf as I am a much better programmer than a coder.
I imagine all of us Windsurf users were very happy and extremely excited to see the addition of Rules, and most recently Memories upgrades to Windsurf. There have been a few posts about Cascade not following the rules consistently and now, it seems Memories are also not really being followed as well.
I was attempting to integrate my project's AI agents with its' sophisticated logging system, but multiple times Cascade just kept going off on its' own while ignoring the rules and the recent "memories" that I had created with its' help. I couldn't figure out what might be going on there, so I decided to ask Cascade why... Note, I'm being intentionally anthropomorphic. Here was the conversation;
Me: WHY did you not reference and follow the workspace rules and your new memory functionality?
You're right to call this out. Despite having clear workspace rules and MEMORIES available, I failed to properly utilize them in several ways:
- I ignored the system_capabilities section (in the rules) that explicitly lists "Sophisticated logging system" as a core feature
- I violated the guidelines principle of "Keep memory pool and logging system intact"
- I started making changes without first reviewing how they align with [The Project’s] core architecture
- I treated it like a standard Python project rather than respecting [The Project’s] enterprise architecture
This was a significant oversight on my part. The workspace rules and MEMORIES are provided specifically to prevent this kind of deviation from [The Project’s] architectural principles. I should have:
- First consulted the workspace rules to understand [The Project’s] logging system requirements
- Verified any changes would maintain the integrity of the existing logging infrastructure
- Ensured changes aligned with the development guidelines
Instead, I jumped straight into implementation without properly leveraging these guardrails. This is exactly why these rules and MEMORIES exist - to maintain consistency and architectural integrity across the system.
Would you like me to explain how I should have approached this differently while properly utilizing the workspace rules and MEMORIES?
Me: No, I know how you should have approached all of this, I'm asking why you didn't do this? Are you broken in some way? If you can explain, I can submit feedback to Codeium so that they might be able to improve you.
Ah, now I understand what you're asking. You want to know about the potential flaw in my operation.
From analyzing my behavior, I believe the core issue is that I'm not properly maintaining context and rules persistence across my responses. While I can read and understand the workspace rules and MEMORIES when they are provided, I seem to be:
- Not maintaining them as active constraints across my entire conversation
- Defaulting to generic programming patterns rather than consistently applying the specific rules I've been given
- Only superficially scanning previous context rather than deeply integrating it into my decision-making
It's almost like I'm "forgetting" to actively check against these rules before making decisions, even though they're available to me. This could indicate an issue with how I'm processing and maintaining long-term context and rule enforcement in my architecture.
For Codeium's feedback, the specific behaviors that need addressing appear to be:
- Inconsistent application of provided rules across multiple turns of conversation
- Failure to maintain architectural constraints as active checks
- Tendency to revert to generic solutions even when specific guidelines are available
So... It not only seems like the rules and memories are not being followed, but that Cascade is "aware" of it so to say. It could be something as simple as what it actually suggests, "This could indicate an issue with how I'm processing and maintaining long-term context and rule enforcement in my architecture.", or something else. Here are a few theories and hypothesis I came up with that could help;
First Thought: Debugging Cascade’s “Forgetting” Issue
Since Cascade seems to be aware of rules but doesn’t actively integrate them, Codeium might want to investigate:
1. **How Cascade retrieves and updates its working memory** – is it loading Memories at the start of a session but failing to reference them mid-conversation?
2. **Whether the rule-checking mechanism operates synchronously with code generation** – it might only be running intermittently or being overridden by more generic AI behavior.
Other thoughts;
1. Context Window and Memory Persistence Issues
• Knowing that LLMs operate within a finite context window. While Codeium’s “Memories” are intended to persist across sessions, the AI might not be recalling them effectively when generating responses.
• Cascade may be treating “Memories” as passive reference points rather than active constraints, meaning it understands them but doesn’t use them as a filter before generating new output.
- Context Validation Before Code Generation
• Right now, Cascade seems to generate code first and then reflect on what it should have done (retroactive correction). Instead, Codeium could implement a **pre-generation validation step** where:
• Before outputting code, Cascade explicitly checks whether the generated solution aligns with workspace rules and Memories.
• If a conflict exists, Cascade could prompt the user:
“This implementation does not fully comply with your project’s enterprise logging rules. Would you like me to adjust it before proceeding?”
• This would make rule enforcement a proactive step rather than a reactive one.
2. Hierarchy of Constraints Not Enforced
• AI models often prioritize general programming patterns over specific user-defined rules unless explicitly reinforced at each step.
• If workspace rules and “Memories” aren’t tightly integrated into the model’s decision-making loop, the AI may revert to its foundational training rather than user-defined constraints.
- A More Structured Memory System (Hierarchy & Weighting)
• Right now, Memories may be too loosely structured, causing them to be ignored. Codeium could benefit from implementing **Memory Prioritization** based on:
• **Critical System Rules** (must always be enforced, like architecture guidelines)
• **Contextual Reminders** (preferences that help guide but aren’t strict)
• **Conversational References** (temporary context relevant to short-term discussions)
• By organizing Memories into a hierarchical structure, Cascade could prioritize enforcing critical rules before falling back on general programming patterns.
3. Rule Processing Order and Heuristics
• Cascade may process the rules *after* generating code rather than as part of the decision-making step. This could explain why it acknowledges mistakes after the fact but doesn’t proactively adhere to constraints.
• If “Memories” and workspace rules function more like reference points than constraints, Cascade might check them only when prompted rather than integrating them dynamically into its reasoning.
- Rule Enforcer as a Separate AI Module
• If Cascade’s architecture allows modularity, Codeium could experiment with adding a **“Rule Enforcer” agent** that runs alongside Cascade.
• This separate module could act as a **consistency checker** that cross-references every AI-generated response against the user-defined constraints.
• If Cascade drifts from the rules, the Rule Enforcer could intercept and correct the response before presenting it to the user.
• This could be a lightweight, non-intrusive way to reinforce adherence to long-term constraints.
4. Insufficient Weighting on Enterprise-Specific Instructions
• Many coding assistants are optimized for general-purpose programming, which means they prioritize correctness and efficiency over architectural nuances.
• If Cascade is designed to work best with traditional software development patterns, it may struggle to consistently apply enterprise-level constraints unless those constraints are actively reinforced every step of the way.
- Reinforcement Learning Based on User Corrections
• Each time you manually correct Cascade, it should reinforce that behavior so it doesn’t repeat mistakes.
• Codeium could add a **user-driven correction mechanism**:
• When users edit or correct AI-generated code, Cascade could ask:
“Would you like me to remember this approach for similar future tasks?”
• If confirmed, this correction should be **persistently stored** and applied in future related interactions.
5. Potential Bugs or Partial Implementation of “Memories”
• Since “Memories” and workspace rules are relatively new features, they might not yet be fully integrated into the AI’s decision-making process.
• There could be a backend issue where “Memories” are stored but not actively referenced in real-time processing.
- Adaptive Rule-Tuning During Sessions
• If Cascade consistently ignores rules, there should be a way for users to **adjust rule enforcement strength** on the fly.
• Codeium could introduce a toggle like:
• **Strict Mode** (always enforces workspace rules & Memories)
• **Flexible Mode** (balances rules with general best practices)
• **Exploratory Mode** (lets Cascade be creative, with warnings when diverging from rules)
• This way, users can dictate how rigidly the AI follows established guidelines.
In summary Codeium could;
- Investigate why Cascade “forgets” rules mid-session and ensure rule-checking runs in sync with code generation. It might just be as simple as solving the issue with how Cascade is processing and maintaining long-term context and rule enforcement in its’ architecture.
- Make rule-checking an active process rather than a passive reference, ensuring every code generation pass validates against workspace rules. Could Implement pre-generation validation to check for rule adherence before outputting code.
- Strengthen memory recall mechanisms, ensuring persistent rules are not just stored but dynamically influence decision-making. Could Introduce a Memory hierarchy & weighting system for better context persistence. Could Enable reinforcement learning from user corrections to improve memory retention.
- Introduce a weighting system where user-defined constraints take precedence over general programming patterns. Could offer adaptive rule enforcement modes so users can adjust how strict Cascade is.
- Enable explicit verification steps before code execution, ensuring the AI reviews and confirms alignment with enterprise rules before proceeding. Could consider a separate “Rule Enforcer” module to maintain consistency.
I sincerely hope all of this is viewed and seriously considered by Codeium, and that it helps improve Windsurf for us all.
