feat(scope): need new features for chat context awareness, and memory.

[noamindark]

Area

Web app

Problem

need new features for chat context awareness, and memory.

Proposal

Can chat sessions be managed by a user like Git, having many branches?

Alternatives considered

No response

Compatibility and migration

No response

Contribution

Not right now

Checklist

• I searched existing issues before opening this request.
• I described the problem before the proposed solution.
• I kept this request focused on one improvement.

[Yevanchen]

Thank you for sharing this idea — Git-like branching for chat sessions is an interesting direction, and we’d be happy to learn more about what led you to it.

When you have a moment, could you walk us through the most recent real situation that prompted this issue? We’d especially like to understand what you were trying to accomplish with Mosoo, how you hoped to use it, and where the current chat context or memory behavior fell short.

A concrete example would help us better understand the underlying need and explore the right solution with you. We’re very open to continuing the discussion here.

[AsperforMias]

@RockChinQ hey bro,do u know about the question about how to do state branch diff and version management about the agent think/state and their combinations for new agent ? maybe we need ur help()

[noamindark]

@Yevanchen

举例一些应用场景
一种是整理资料，比如探索历史人物，不确定上下文环境时，就无法事先确定具体提示词或role.md，在会话过程中刚好因为对一个历史事件感兴趣，从而产生一个前置的聊天背景，而之后探索的每个具体人物在是在同一个历史事件中，同时会话中也记录了一些细节信息，但是一旦某个人物对话过深或者有2-3次偏离原先聊天背景的对话，后续的对话会受到影响，如果能在聊到历史事件时的对话作引用或以此产生聊天分叉，则可以根据前置对话的聊天背景作为提示词或记忆，那么对后续具体的人物探索则可以分开进行又人物彼此之间不受影响

另外一种是基于资料的创作，比如单个人物生成多次介绍，挑选满意的，甚至沿用到其他人物中，一些小说生成工具具有类似的功能，我了解现有的做法，一种是让ai提取风格或生成模板，一种是记录到记忆或skill中，但都会因为上下文的迁移有一定的失真

最后是对于长文生成或局部细节的生成，仍然需要类似comfyui那样的节点画布来进行微调或拼接。不限于小说或故事，像报告、科普类文章、讲解词，篇幅大同时需要兼顾大纲和资料纠正，目前一种是agent通过脚本来执行这种文字的编排，另外一种就是消耗大量token去反复思考来生成，人和ai的协作方式在我看来从工程视角可以用更好的流程来进行

I’d like to propose a feature that addresses several real‑world use cases where current context management falls short. Below are some scenarios that illustrate the need.

1. Organizing Research – Historical Figures in a Shared Event
   When exploring historical figures, the context is often unclear at the outset – you don’t know in advance what prompts or role.md to prepare. During a session, you might become interested in a specific historical event, which naturally establishes a conversational background. Then, as you dive into individual figures within that same event, the chat history retains useful details.

However, if you go too deep into one figure, or if the conversation drifts 2–3 times away from the original event, subsequent dialogues become polluted by irrelevant context.

Proposed solution: Allow the user to “quote” or “fork” the conversation at the point where the historical event is discussed. That way, the background context (the event’s details) can serve as persistent prompt or memory for all related explorations. Each figure’s thread can then be developed separately, without interfering with others, while still benefiting from the shared context.

2. Content Creation Based on Source Material – Style Transfer and Reuse
   Another common scenario is generating multiple introductions or descriptions for a single character, picking the best one, and then reusing that style or template for other characters. Some novel‑writing tools already offer similar functionality.

Existing approaches include:

Asking the AI to extract a style guide or generate a template.

Storing the style in memory or as a “skill”.

But both methods suffer from context drift – when you move to a new character or a different part of the work, the transferred style often degrades or becomes distorted because the original conversational context is left behind.

Proposed improvement: A more robust way to capture and apply stylistic elements across different threads, while preserving the integrity of the source material, without relying solely on the linear chat history.

3. Long‑Form Generation and Localized Polishing – A Node‑Based Canvas
   For long documents (reports, popular science articles, scripts, etc.) or for fine‑tuning specific sections, we need a visual, node‑based canvas similar to ComfyUI. This would allow:

Micro‑adjustments and splicing of segments.

Simultaneous management of high‑level outlines and low‑level factual corrections.

Currently, two approaches dominate:

Agents orchestrate the text structure via scripts.

The model iterates over the entire content repeatedly, consuming huge token budgets and often losing coherence.

Neither is ideal from a human‑AI collaboration perspective.

Proposed solution: A workflow that enables better orchestration – e.g., a branching, non‑linear editing environment where users can manually adjust sections, link context nodes, and refine parts independently, all while keeping the overall structure under control.

Summary
In all these cases, the current linear chat paradigm limits effective collaboration. I’m requesting a feature set that includes:

Conversation forking with retained context anchors.

Style/memory transfer that resists drift across threads.

A node‑based editing canvas for long‑form and fine‑grained generation.

I believe this would significantly improve the way humans and AI work together on complex, multi‑step creative and research tasks.

[noamindark]

另外，我自己设想的最酷的方式其实是将tui、workflow、node-graph结合起来在一个界面中

tui完成的是对话工程和指令，可以操控workflow 或 node-graph 甚至3d 空间，chat的斜杠魔法可以理解为一种模式或沙盒的运行，运行显化渲染到web UI甚至系统窗口，变成对话节点甚至应用节点，这就像ubuntu的server版和用户界面版，假设上下文如果带有系统配置或文件内容，session就像应用进程或服务线程，我认为这是一种实现aios的途径

Additional Vision – A Unified Interface Combining TUI, Workflow, and Node-Graph

The coolest way I envision is to combine TUI (Text User Interface), workflow, and node-graph into a single interface.

The TUI handles conversation engineering and command issuing. It can control the workflow, the node-graph, or even a 3D space.

Chat slash commands (like /magic) can be seen as modes or sandboxes – they trigger actions that are manifested and rendered from the TUI into the web UI or even native system windows, turning them into conversation nodes or application nodes.

This is similar to how Ubuntu has both a server edition and a graphical desktop edition – the TUI is the "server" backend, while the UI is the "desktop" frontend.

If the context includes system configurations or file contents, each session behaves like an application process or a service thread. and I believe this is a viable path toward realizing AIOS (AI Operating System).

[Yevanchen]

谢谢你把这些场景展开得这么具体。站在你的使用过程里看，我们理解这个问题并不是简单地“多记住一些内容”：当一段对话已经形成了有价值的共同背景，你希望分别深入人物、版本或局部内容，却不得不在“保留前文”与“避免后续支线互相污染”之间二选一。每次手动把它总结成 prompt、模板、memory 或 Skill，不只增加操作负担，也可能丢掉对话里逐步形成的细节与风格。

基于这些例子，我们会把这个 issue 的核心收窄为：

Continue in a new Thread from this turn
从某一轮开始创建新的 Thread，继承此前明确可见的上下文，之后各自独立演进。

我们目前把它标记为 needs-validation：这是值得验证的产品假设，但还不是 roadmap 承诺。对 coding Agent 而言，“分叉”不仅包含文字，还可能涉及文件、Sandbox、memory、provider session，以及已经发生的工具副作用。我们不希望直接用“Git branch”让人误以为这些状态都能完整复制、合并或回滚。

你提出的 node canvas / workflow / TUI / AIOS 是一套更完整的人机协作产品愿景，我们能理解它为什么对长文创作和复杂资料整理有吸引力。不过 Mosoo 当前聚焦 coding-agent runtime 与 Thread API，不会在这个 issue 中扩展为通用节点编辑器或 AIOS。更符合 Mosoo 边界的方向，是先把 Thread 的派生与运行能力做可靠，让上层产品能够据此构建画布或工作流体验。

因此，这个 issue 会保留用于验证“从某一轮开启独立 Thread”；canvas / AIOS 不纳入当前核心范围。感谢你提供的具体场景，它们帮助我们把问题从泛化的 memory 需求收敛成了更清楚的用户行为。