Implementation of Agent-Driven Memory Management (Targeted RAG Extraction & Selective Context Pruning)

[JohnMRising]

What problem would this solve?

When building advanced autonomous agents using MCP servers in ToshLLM, the chat context grows indefinitely. While the built-in "Recover Speed" button (history summarization) is great for manual use, it's just a basic compression mechanism. It doesn't allow agents to manage their own operational memory selectively—such as extracting specific blocks of context, dumping them into a local RAG storage, and surgically removing those turns from the active message array to free up tokens.

Proposed behavior

I would love to see a more agent-driven approach to memory management in ToshLLM. Ideally, this could be exposed via native API hooks or MCP-compatible control actions allowing an agent (or an external MCP server) to:

1. Targeted Extraction: Send a specific part of the conversation history (e.g., a solved coding problem or a specific topic) to an external RAG/storage mechanism.
2. Selective Pruning: Programmatically trim or replace specific message ranges in the chat array rather than just doing a blanket compression.
3. Autonomous Lifecycle: Let the model decide when a topic is wrapped up, enabling true active memory management instead of a reactive, read-only loop.

Alternatives considered

Building external proxy wrappers around the backend, but having native support or proper hooks within ToshLLM would make it an absolute game-changer for local agentic orchestration.

Additional context

Thank you an advance and many-many thanks for your incredible work.

Before submitting

• I searched the existing issues and did not find the same request.

[engeldlgado]

Hi, thanks for taking the time to write this suggestion. I think it's great because it allows for better fluidity in agent mode. I'll study it and hope to have an implementation that fulfills part of its purpose. I also need to review the context-related speed recovery feature because it was implemented very early on and may need better adjustment and implementation. I'll leave this issue open so I can follow up on it in the coming days. I'll respond when I have something concrete implemented. Thanks again.