After releasing ThoughtDAG in August, the most significant feedback was that while editable context graphs were interesting, people didn't want to migrate their existing work to a separate application.
This prompted me to create Session Atlas. It reads local Codex and Claude Code sessions, organizes them by project, and retains conversations, tool calls, and results. The original session remains read-only, and the graph in ThoughtDAG is an editable mirror; content visible on the canvas doesn't automatically carry over to the next model request.
Now, you can select a context from a past session, launch a new CLI experiment, and then connect the results back to the original graph.
Currently, it's not bidirectionally synchronized, only supporting two local sources. But what I want to explore is: should Agent history be just a log, automatically remembered, or source material that can be reorganized and referenced by the user?
There is a way to delete a highlight. On the node side panel, there is a folded highlight section; you can manage your highlights there. Also, on your canvas, top-right ... menu, you can manage your highlights as well.
Thanks! I'm not very familiar with Neo4j and Cypher yet. How do you control the context using Cypher? Do you manually write queries for each request, or do you select nodes through the interface and then automatically generate queries? I'm also curious about how the graph structure obtained from the query is ultimately transformed into an ordered model context.
Thanks, oh I see, Cypher acts as a context selector.
ThoughtDAG addresses the same issue but uses a visual approach: it searches for nodes first, then uses connections or references to determine which content enters the request. I'd love to see how it compares to writing Cypher directly, especially after conversations start branching and merging, if you get a chance to try it.
Thank you for sharing! That did occur to me. ThoughtDAG now marks affected downstream answers as needing updates after an upstream node is modified, allowing users to rerun the algorithm in dependency order; alternatively, automatic refresh can be enabled only for specific nodes.
I didn't rebuild the entire tree by default, mainly because modifying earlier nodes might trigger a large number of calls and could overwrite some still valuable intermediate results. Older answers are retained as historical versions for easy comparison.
The slime mold analogy is very accurate: research begins by exploring multiple directions, then gradually strengthens the path supported by evidence, stopping other branches from entering subsequent reasoning, but still leaving traces of exploration.
ThoughtDAG currently deliberately leaves this strengthening and pruning to the user, rather than letting the model choose automatically (I think human-in-the-loop is important). I'm curious, in your prototype, is the path strengthened manually by the user, or is it done through model scoring or other signals?
I think we need to distinguish between "what the model received" and "why the model generated this answer." ThoughtDAG currently focuses on the former: accurately displaying the context of the incoming request and allowing users to modify it.
Sometimes it’s just an awkward turn of phrase on my part that creates a wrinkle in the conversation. Sometimes agents identify that, and we can work together and direct that, but correction itself eventually loses competition to the original error.
Most LLM tools (Claude Web, OpenAI, and their harness) offer re-editable questions. That is how I avoid such problems by myself.
In ThoughtDAG, you can re-edit questions by double-clicking the question. Or edit the answer by clicking the edit icon at the end of each answer text. Or.. you can just remove the connection or delete the node.
If you're referring to the loom analogy, then it's quite similar: you choose which threads to weave into the next context; unwanted threads can be unraveled :)
Thank you for pointing out this issue. The homepage did indeed use too many common landing page elements before actually showcasing the product. I redesigned the homepage, removing status labels, promotional slogans, and unnecessary entry points, making the interactive context graph the main focus of the page.
This prompted me to create Session Atlas. It reads local Codex and Claude Code sessions, organizes them by project, and retains conversations, tool calls, and results. The original session remains read-only, and the graph in ThoughtDAG is an editable mirror; content visible on the canvas doesn't automatically carry over to the next model request.
Now, you can select a context from a past session, launch a new CLI experiment, and then connect the results back to the original graph.
Currently, it's not bidirectionally synchronized, only supporting two local sources. But what I want to explore is: should Agent history be just a log, automatically remembered, or source material that can be reorganized and referenced by the user?
Previous HN discussion: https://news.ycombinator.com/item?id=49307700