Implement Memory Bank Functionality

[olearycrew]

Proposal Summary

We should implement a Memory Bank feature similar to what Cline and Roo Code have developed. This would provide a structured way for our AI assistant to maintain context across sessions by accessing a designated set of documentation files, solving a key limitation of AI assistants (context loss between sessions).

Additional context

Background

Cline and Roo Code both have sort of "community sourced" Memory Bank implementations that are receiving positive feedback from users:

1. Cline Memory Bank: A methodology for managing AI context through structured markdown documentation stored in a project's repository. When users instruct Cline to "follow custom instructions," it reads the Memory Bank files to rebuild its understanding of the project.

2. Roo Code Memory Bank Project: A GitHub project by GreatScottyMac that provides "seamless project context in Roo Code" with "no more repetition, just continuous development" including multiple operational modes (Architect, Code, Ask, Debug, and Test).

Proposed Implementation

We should create an integrated, user-friendly Memory Bank feature with the following:

1. Simple Activation: Add an "Enable Memory Bank" toggle button in the UI that handles the setup/initialization automatically (rather than requiring users to follow manual instructions as in the existing implementations).

2. File Structure: Implement a standardized directory/file structure to store project context:

   • Core files for tracking current session state, technical decisions, project overview, and progress
   • Optional files for project brief and system patterns

3. Context Management: Develop commands or automatic triggers to:

   • Initialize the Memory Bank when first enabled
   • Update the Memory Bank files when significant progress is made
   • Prompt users to update context when closing sessions

4. Multi-Mode Support: Consider supporting different operational modes similar to the Roo implementation:

   • Planning/architecture mode for high-level design
   • Implementation mode for coding tasks
   • Documentation/knowledge base mode
   • Debugging mode for troubleshooting

User Experience Considerations

• Setup should be largely automatic with minimal configuration required
• Should offer to create a Memory Bank directory when starting new projects
• When closing sessions, prompt users to update the Memory Bank to preserve context
• Provide clear documentation on how to effectively use and maintain the Memory Bank

Technical Approach Options

We have two potential implementation paths:

1. Build From Scratch: Develop our own Memory Bank system inspired by Cline's approach, with a focus on simplicity and automation.

2. Adapt Existing Solution: Incorporate the Roo Code Memory Bank project since it's open source and already well-developed. Per Justin's suggestion, we could integrate this directly.

Next Steps

1. Evaluate both the Cline approach and the Roo Code implementation to determine which provides a better foundation
2. Develop a prototype showing how the feature would appear in our UI
3. Create a technical design doc for the selected approach
4. Implement a beta version and gather feedback

Resources

• Cline Memory Bank Documentation
• Roo Code Memory Bank Project
• Cline Blog on Memory Bank

Priority and Impact

Priority: Medium-High
Impact: High - This feature would significantly improve the user experience by reducing repetitive context-setting between sessions, making our product more efficient and competitive.

[Juice10]

From Oleksandr on https://discord.com/channels/1349288496988160052/1349288496988160055/1371543202175258794

Every time you ask the AI model a question, even within the same task, it has no memory of you or your project. This is how all AI models work without exception.
Therefore, with each new question you ask, your entire dialogue from this session and the text of all related files are sent to it again.
Because of this - if you want to continue something, continue by returning to the session where it was discussed, or you will have to explain everything all over again.
BUT! If you are always working in the same workspace - you can add the following prompt - in the User Prompts for all projects:

"When the session ends, I will state this explicitly -
Ending the session, or Let's finish here, or something similar in meaning.
For you, these words should be a trigger to create a brief session report in the lastcontext.md file in the workspace root.
The report should contain everything important for restoring context but be compact - only what's essential for continuation.
If the file already contains information - it should be deleted first.

When starting a new session (a new task), read the lastcontext.md file located in the workspace root."

Your AI Agent will compile a condensed context at the end of the session and read it at the beginning. It works well, I use it.

From lwl99 on https://discord.com/channels/1349288496988160052/1349288496988160055/1371558873407684739

Memory bank mcp should have have this, kilocode should also add this "memory bank" feature to truncate context when nearing limit .

[OleynikAleksandr]

Proposal for Implementing "Cross-Session Project Memory" in Kilo Code (MVP)

Introduction: The Importance of a Structured Approach to "Memory"

The "Memory Bank" feature for an AI assistant like Kilo Code is highly sought after. However, to implement it effectively and avoid common issues (such as overloading the LLM's context window, high query costs, and low relevance of "recalled" information), it's crucial to clearly categorize "memory" by its purpose and usage.

This proposal focuses on one of the most critical categories: cross-session memory for the current project. Its goal is to ensure a smooth transition and context preservation when working on a single project, even if sessions are interrupted (e.g., closing VS Code, switching tasks, long breaks).

Problem: Loss of Context Between Project Sessions

When working on large or long-term projects with Kilo Code, a primary challenge is the need to re-brief the LLM each time: what was being worked on, what were the last steps, and what are the goals for the current session. This consumes time, increases token usage, and reduces overall efficiency.

Attempting to solve this with universal vector databases storing the entire project's information might be ineffective for restoring the context of the immediately preceding session. In a large project with many similar modules or tasks, retrieving relevant information about the directly preceding session can be difficult and imprecise.

Proposed Solution: Leveraging Kilo Code's Existing Infrastructure for Saving and Loading Session Summaries with an Intuitive UI

I propose implementing a cross-session project memory mechanism by leveraging Kilo Code's existing, well-designed structure of prompts and configuration files, particularly the system for project-specific instructions in the .kilocode/rules/ folder. A key element for user convenience will be the addition of two new buttons to the Kilo Code interface, placed in the same row as the existing "Start New Task" button (see attached visual example / screenshot).

Core Components of the Solution (MVP):

1. File for Storing Session Summaries:

   • We propose using a dedicated file within the current workspace's .kilocode/rules/ directory, for example, project_session_summary.md. Using Markdown format will enhance human readability and allow for basic markup to structure summaries in the future.
   • Storing it in this folder automatically ensures project-specificity and aligns with Kilo Code's current logic for handling project-based settings.

2. Mechanism for Saving Session Summaries (Triggered by a New Button):

   • New Interface Button: An "End Session & Summarize" button will be added in the same row as the "Start New Task" button.
   • Kilo Code Actions (via LLM) upon clicking "End Session & Summarize":
     • Kilo Code (using the LLM) generates a concise yet comprehensive summary of the concluding session. The prompt for the LLM should focus on extracting key information: main tasks worked on; important files modified or discussed; unresolved issues or problems; and planned next steps.
     • Kilo Code writes this generated summary to the project_session_summary.md file in the current workspace's .kilocode/rules/ folder, overwriting any previous content if the file already exists.
     • (Optional: Kilo Code can notify the user upon successful summary saving).

3. Mechanism for Loading and Using Summaries at the Start of a New Session (Triggered by a New Button):

   • New Interface Button: A "Continue Project Task" button will be added in the same row.
   • Logic for the "Continue Project Task" button:
     • Upon clicking, Kilo Code checks for the existence of the project_session_summary.md file in .kilocode/rules/.
     • If the file is found, its content is automatically read by Kilo Code.
     • This content is included by Kilo Code at the very beginning of the prompt (or in a dedicated, clearly marked section of the system prompt) sent to the LLM along with the first user input (${userInput}) for the new session.
     • (Optional: If the file is not found, Kilo Code can notify the user and suggest starting a new clean session, or the "Continue Project Task" button could be inactive/hidden if no file exists).
   • Logic for the existing "Start New Task" button: Remains unchanged – it starts a session from scratch, without using project_session_summary.md.

4. Instructions for the LLM on Handling Summaries (Optional but Recommended):
   • In the general custom instructions (Custom Instructions for All Modes), which can be loaded from .kilocode/rules/.kilocoderules, a rule for the LLM could be added, for example:

     "If the context provided by Kilo Code begins with text explicitly marked as 'PREVIOUS PROJECT SESSION SUMMARY', you MUST use this information as the primary context for continuing work. This text describes the project's state at the end of the previous session."
     

     This will help the LLM correctly interpret and use the provided summary.

Benefits of the Proposed MVP:

• High Usability: Explicit buttons "End Session & Summarize," "Continue Project Task," and "Start New Task," located in a single functional block, make session management intuitive and easily accessible.
• Simplicity and Rapid Implementation: Implementing the buttons and their associated logic is a standard task for UI extensions, with the main complexity remaining in prompt engineering.
• Leverages Existing Architecture: Organically fits into the project-specific rules system of .kilocode/rules/.
• Immediate and Tangible User Benefit: Significantly improves the experience of working on projects.
• Native Multi-Project Support: Context is strictly tied to the workspace (project).
• User Control: The user explicitly controls when to save and load context via dedicated buttons.
• Context Recovery After Interruptions: Even if a session is interrupted without a proper shutdown (e.g., due to a crash, accidental VS Code closure, or the user simply forgetting to click the button), the user can always return to the relevant dialogue in Kilo Code's chat history and click the "End Session & Summarize" button for that session. This allows generating and saving the summary retroactively, ensuring context recovery.
• Token Efficiency: Only a concise, relevant summary of the last session is passed in the prompt.
• Focus on Relevance: Ensures that precisely the context needed for continuing work is provided.

Further Development (Post-MVP):

• Improving Summarization Quality: This is a key and critically important aspect requiring dedicated, serious research and iterative refinement. The quality of any provided context directly impacts the LLM's output.
  • Configurable Detail/Compression Levels: Similar to some existing tools (e.g., the Refact VS Code extension, where dialogue is compressed into a summary), exploring user-selectable levels of summary compression could be beneficial. However, it's crucial not just to offer compression levels but to ensure high quality at each level.
  • Applying Approaches from "Enhance Prompt": Investigate adapting the principles from Kilo Code's existing "Enhance prompt with additional context" feature. If this feature successfully transforms user tasks into more complete and technically sound prompts, a similar mechanism of "intelligent enrichment and structuring" could be applied to generate high-quality session summaries when "End Session & Summarize" is clicked. This could include not only compression but also identifying key entities, formulating next steps, etc.
• Partial Automation: Consider offering to save context when VS Code is closed or after prolonged inactivity (with user confirmation), perhaps via a dialog box with a "Summarize & Exit" button.
• Summary Visualization/Editing: Allow users to view and, if necessary, edit the saved summary (e.g., by opening the project_session_summary.md file in the editor).

Conclusion:

The proposed approach to implementing cross-session project memory, emphasizing a user-friendly interface with new, logically grouped buttons (as shown in the attached screenshot), is a pragmatic first step. It addresses one of the most pressing user needs with minimal development overhead, while laying the groundwork for more comprehensive "Memory" features in Kilo Code, particularly regarding the quality of generated contextual summaries.

[Juice10]

Another alternative is to use SPARC for this as it also comes with built in memory management.

• https://github.com/ruvnet/rUv-dev (nodejs)
• https://github.com/simonpfrank/create-sparc (python)

[OleynikAleksandr]

Hi Justin,
Thanks for sharing the SPARC concept and the links. It's an interesting approach to long-term memory.
In my view, it's beneficial to clearly distinguish between different types of "memory" or "knowledge" for an AI assistant:
Operational Memory for the Current Project Session: This is about maintaining immediate context to seamlessly continue the current task (as detailed in my proposal above regarding project_session_summary.md). This seems to be the most pressing and currently missing piece for day-to-day workflow.
Personal/Project Knowledge Base: This would store user-curated findings, solutions, and snippets. The key here is user control – only the user decides what's valuable enough to save to prevent this base from becoming cluttered.
Fundamental Knowledge Base: This would comprise curated SDK/API documentation, best practices, etc., maintained enterprise teams.
My proposal above primarily addresses the first type – operational, short-term memory.
SPARC and similar RAG systems are certainly relevant for building out the Personal and Fundamental Knowledge Bases (types 2 and 3). However, I believe that for both these types, the ingestion of information should be explicitly triggered or heavily curated by the user (for personal KBs) or dedicated teams (for fundamental KBs). Automatic ingestion of everything risks creating a noisy and unhelpful data store very quickly.
This might be one reason why tools like VS Code Copilot, Cursor, or Windsurf haven't deeply integrated such broad knowledge base systems natively yet, often deferring to third-party solutions, thereby sidestepping responsibility for their potentially inefficient use if not properly managed.
Focusing on a robust solution for operational session memory first could provide immediate high value, with personal and fundamental knowledge bases being separate, important areas for future development.

[OleynikAleksandr]

Hi Brendan,
Hi Justin,

I've been following the interesting discussion regarding the implementation of a "Memory Bank" feature for Kilo Code to enhance cross-session context retention (like in this GitHub discussion). Your proposal and insights there are very valuable.

To help better understand how a cross-sessionsemory Bank would integrate with Kilo Code's existing capabilities, and to ensure any new feature complements the current user experience, i were wondering if you could shed some light on how Kilo Code currently manages dialogue context within a single, long-running session.

Specifically, i're curious about:
Dialogue History Management: How does Kilo Code currently manage the conversation history as a session progresses?
Context for New Prompts: With each new user prompt within the same session, is the entire preceding dialogue history typically sent to the LLM, or is there a selection/summarization process?
In-Session Dialogue Condensation: Does Kilo Code employ any built-in mechanisms for interactively condensing or summarizing the ongoing dialogue during a session? The idea would be to pass a more concise summary of relevant prior turns to the LLM, rather than the full history, especially as the dialogue grows and approaches context window limits.
Understanding the current in-session context handling would be very helpful for the community in thinking about how a persistent, cross-session Memory Bank could best be designed and implemented.

Thanks for your time and any insights you can share!

[OleynikAleksandr]

Hi Brendan,
Hi Justin,

Hope I'm not bothering you too much with these thoughts? :)

Reflections and Questions for Discussion: Optimizing Context Management in Long LLM Sessions

1. Context for Discussion

1.1. Observed Problem
During my long interactions with LLMs, especially in tasks requiring the maintenance of complex context (e.g., programming), I've noticed the current volume of dialogue can quickly exceed optimal limits or even the model's context window limits. Standard approaches, such as sending the entire accumulated dialogue or its simple truncation, appear to have several drawbacks:

Resource Utilization Efficiency: The question arises for me as to how efficiently LLM resources are used when a significant portion of the transmitted context may no longer be relevant to the current stage of the dialogue.
Cost: Transmitting a large number of tokens directly impacts API usage costs.
Response Speed: Processing redundant context can slow down response retrieval.
Response Quality: Is there a risk that an excess of information or "noise" in the context might distract the LLM or lead to less accurate answers? Can "recency bias" occur to the detriment of earlier, but still important, information?
Information Loss with Truncation: If simple truncation is used to adhere to context window limits, is important information accumulated earlier lost in the process?

1.2. Purpose of This Document
The purpose of this document is for me to raise these questions for discussion with the Kilo Code development team and to offer some of my observations and assumptions that could provide food for thought in finding ways to optimize context management within a single work session.

2. Key Aspects and Possible Challenges for Consideration

2.1. LLM Context Window Limitation
Question: If the primary mechanism for combating window overflow is truncation, how can we (or I, as a user, hope you can) minimize the risk of losing useful information? Is it possible that periodic semantic consolidation of the dialogue could allow for more effective use of the available context window throughout the entire session, even a very long one?

2.2. Context "Noise" and Model Focus
Assumption: It seems to me that a large volume of information, especially if part of it is no longer relevant, can make it difficult for models to focus on truly important details.
Question: Could regular consolidation, filtering out "noise" and preserving only key dialogue milestones, help the LLM maintain a cleaner and more focused context? How can it be ensured that necessary details are not lost in this process, and how can a balance be struck between a preference for recent information and the need to remember important points from earlier stages?

2.3. Cost and Time of Processing Context
Question: How significant could the token savings and response speed improvements be if the context underwent intelligent compression or summarization before being sent to the LLM?

2.4. Complexity of Automating "Correct" Consolidation
Key question for developers: How complex is the task of automatically, reliably, and effectively extracting truly important information from a dialogue without losing critical details? What approaches or known "best practices" exist for solving this task?

2.5. Determining Moments for Consolidation (My Observation on "Micro-stages")
My Observation from practice: In the course of solving a task with AI, I've found natural "turning points" or "micro-stages" often arise: when an intermediate solution is found, a conclusion is formulated, or, conversely, a problem arises requiring a change of approach.
Question for discussion: Could such "micro-stages" serve as natural triggers for context consolidation? This would make the process more intuitive and tied to the logic of task resolution from my perspective.

3. Possible Directions for My Research and Your Implementation Discussion

3.1. Using "Micro-stages" for Consolidation
Assumption: If I, as a user, explicitly or implicitly signal the completion of such a "micro-stage," this might be an appropriate moment to consolidate the dialogue accumulated at that stage.
Questions for developers:
What mechanisms could be used to detect such "consolidation points" (explicit user commands, dialogue pattern analysis, integration with a task system, feedback buttons)?
Which detection approach would be most convenient for the user and technically effective?

3.2. Consolidation and Summarization Techniques
Questions for consideration:
LLM-based Summarization: How effective would it be to periodically assign the LLM itself (either the main one or a specialized, possibly local one) the task of creating a concise summary of the previous dialogue stage? What prompts would be optimal for this?
Prompt Engineering for "Built-in" Consolidation: Can system prompts or instructions encourage the LLM to maintain brevity and focus in its responses, perhaps implicitly performing elements of consolidation?
Structured Information Extraction: Would it be useful to explore the possibility of not just a text summary, but extracting structured data from the dialogue (key decisions, problems, artifacts)? How could this help the LLM further?

3.3. Forming New Context After Consolidation
Question: If a chain of consolidated summaries is used, how can the optimal balance between the compression degree of old summaries and the preservation of sufficient detail be determined? What elements should the context transmitted to the LLM after consolidation include (e.g., a global project summary, a chain of stage summaries, the last N "raw" messages, current <environment_details>)?

3.4. User Interface (UI) and Control
Questions for discussion:
How important is explicit user control over the consolidation process for me (e.g., via special buttons or commands)?
Should I, as a user, be able to view and, possibly, edit the generated stage summaries?
What settings related to consolidation might be useful to me?

3.5. Handling Complex Cases
Questions for consideration:
How could the system effectively handle situations when I return to a topic discussed several consolidation stages ago? Would access to more complete (unconsolidated) session logs be required?
What mechanisms could help if automatic consolidation leads to the loss of important information?

4. Experimental Validation and Iterative Improvement
   Proposal for consideration: It might be useful for Kilo Code to conduct comparative experiments (e.g., solving the same task with different context management strategies) to obtain empirical data on effectiveness.
   Question: What metrics (besides cost and time) would be important for assessing the quality of consolidation mechanisms and their impact on my final work result with Kilo Code?

5. Link to "Memory Bank" (Cross-Session Memory)
   Question for discussion: How could the proposed mechanisms for intra-session consolidation interact with and complement the concept of a cross-session "Memory Bank"? Could consolidated stage summaries serve as a basis for forming the final session report stored in the "Memory Bank"?

6. As a Conclusion for Discussion
   It appears to me that a shift towards more intelligent methods of context management within a session, including periodic semantic consolidation, could significantly improve my Kilo Code interaction experience. This document, from my perspective, aims to initiate a discussion of these issues with the development team to jointly find the best approaches to this complex but important task. Any thoughts, counterarguments, or alternative visions from the Kilo Code team would be extremely valuable.