DEV Community: Xia Chen

Before Your Coding Agent Edits a File, Let It Ask Why

Xia Chen — Fri, 04 Sep 2026 15:50:06 +0000

AI coding agents can modify an unfamiliar file in seconds. The slower question is often more important:

Why does this code look this way?

The answer may be scattered across old local sessions: one turn investigated the bug, another rejected an approach, and a later turn made the edit. Git preserves the code change, but not necessarily the surrounding agent conversation.

I added a local query layer to ThoughtDAG so a developer—or a coding agent—can deliberately retrieve that history before editing:

npx thoughtdag why src/lib/api.ts

It searches supported local agent transcripts for turns that changed, read, or discussed the file and returns links to the matching source turns.

Observation is not explanation

The difficult part was not text search. It was avoiding a false claim of causality.

If a session record shows a file edit, ThoughtDAG can report that as an observed change:

Δ storedProviders → storedProviders, storedVision…

If the agent later says why it made the change, that is useful—but it is still the agent's account, not a verified causal fact. ThoughtDAG marks that separately:

≈ candidate explanation from the agent response

This distinction matters when old session history becomes input to another agent. A fluent explanation should not silently harden into ground truth just because it was retrieved.

Retrieval stays deliberate

For regular use, the same index can be exposed through read-only MCP tools:

npm install -g thoughtdag
thoughtdag setup mcp

The agent can then call why_check, why_file, find, and recall_turn before changing code. Retrieval is explicit; matching history is not automatically injected into every prompt.

The index stays on the local machine, and source session files are never modified. The current CLI covers local Claude Code, Codex, and ThoughtDAG canvas conversations.

What this does not prove

This is a developer preview, not a complete audit trail.

An observed edit proves that the recorded session changed a file, not that every reason for the change was captured.
A matching turn can be relevant without being sufficient.
External session formats can drift.
Missing or unrecorded actions remain missing.

Those limits are why the output keeps provenance visible and separates observations from candidate explanations.

I am now testing a stricter workflow: before editing an old file, an agent first checks whether there is relevant local history, opens the exact turn when needed, and only then decides what belongs in its current context.

What would you want such a pre-edit check to surface: rejected alternatives, linked issues, tests that once failed, or something else?

Source: github.com/chenxiachan/thoughtdag

Disclosure: I maintain ThoughtDAG. This article was drafted with AI assistance and manually checked against the released CLI and documentation.

Your Local Agent Session Should Be a Source, Not Hidden Memory

Xia Chen — Wed, 02 Sep 2026 16:52:04 +0000

My useful agent work rarely lives in one conversation.

One session investigates a bug. Another compares designs. A third edits the code. The important context is spread across terminal logs, tool calls, files, and compacted summaries.

The usual answer is “give the agent better memory.” I wanted a stricter boundary instead:

source session  ->  editable mirror  ->  compiled model context
  read-only           user-owned             explicit

That boundary became Session Atlas, a new desktop feature in ThoughtDAG. It currently reads supported local Codex and Claude Code sessions, groups them by project, and opens them as graph mirrors.

The point is not to turn a transcript into a prettier transcript. It is to separate three things that are often conflated:

what the agent actually recorded;
what the user wants to keep, reorganize, or connect;
what the next model request should receive.

The source stays read-only

Atlas never rewrites the original session file. The source remains the record of what the external agent did.

The imported graph is an independent mirror. I can edit a mirrored node, remove a wire, add a PDF or note, or create a new branch without mutating the source history. Questions asked inside ThoughtDAG belong to the canvas; they are not written back into the source agent session.

This distinction matters because “editing history” and “curating future context” are different operations. The first changes the record. The second changes what happens next.

Each user-and-agent turn becomes one conversation node. Tool calls and results are paired as attachments on that node rather than flattened into fake conversational turns. The mirror also keeps the runner, session ID, source turn identifiers, working directory, and truncation markers.

Visible is not the same as included

An imported turn can remain visible on the canvas without entering the next request.

In ThoughtDAG, wires are part of the context definition. Incoming paths and explicit references determine which nodes and attachments are compiled for the model. Removing a wire excludes that branch from downstream model context while leaving it available for inspection or reconnection.

That gives the graph two jobs:

a durable human workspace for the project;
an executable description of model context.

This is intentionally different from automatic retrieval. Atlas does not claim that every visible artifact is relevant, and it does not silently choose a hidden memory set on the user's behalf.

The mirror keeps listening

A mirror is not just a one-time import. If the source agent keeps working, Atlas watches the supported local session store and appends new turns incrementally.

The append path uses a per-session ledger:

source file changes
        -> identify the session
        -> skip turns before the ledger boundary
        -> append only unseen turns to that session's tail

Existing nodes are not moved. Edited mirror text is not overwritten. A session registered to another canvas does not silently append to the current one. Deleting every mirrored node for a session removes its subscription, so intentionally deleted work does not grow back.

The harder problem here was not parsing JSONL. It was deciding which invariants should survive updates.

One project can contain several agents

Atlas groups sessions by their recorded working directory. That lets work from supported runners meet at the project level without pretending they share one native history.

I can place several sessions on one canvas and decide whether they connect. I can also take the curated upstream context from a node into a fresh CLI session, continue the work there, and mount the returned session back at the departure point.

This is still human-controlled context transfer, not autonomous orchestration. Atlas does not schedule agents, grant permissions, or allocate resources. Creating the next session and choosing its context remain explicit actions.

Why not just rely on compaction?

Compaction is useful, but a summary is a lossy state transition. After compaction, it can be difficult to inspect which tool result, abandoned hypothesis, or source passage led to a decision.

Atlas sits above that mechanism. It preserves the source session while letting the user curate a finer-grained project context across turns and agents.

The architecture is deliberately conservative:

the source is evidence;
the mirror is editable;
model context is compiled from explicit graph structure;
cross-agent handoff is visible and user-triggered.

Current limits

Session Atlas is a desktop/local feature. It currently supports native scanning of local Codex and Claude Code sessions, and runner formats can change. The web demo does not have arbitrary filesystem access, so it cannot provide local session discovery.

This is also not an “Agent OS.” It is a visual coordination and context-transfer layer. I would rather keep that boundary honest than imply autonomy the product does not have.

The feature is available in ThoughtDAG v0.4.2. The Session Atlas guide documents the import, live append, source configuration, and CLI handoff paths. There is also a 45-second walkthrough.

I am especially interested in two kinds of feedback:

Which other local agent session format should be supported next?
Where should the boundary sit between automatic context suggestions and explicit user control?

Disclosure: I maintain ThoughtDAG. This article was drafted with AI assistance and manually checked against the released v0.4.2 implementation and documentation.

I Deleted the Wrong Turn. Three LLM Endpoints Still Repeated Its Answer.

Xia Chen — Mon, 24 Aug 2026 01:21:04 +0000

I assumed that removing a wrong turn would repair an LLM conversation.

Then I tested it.

In one deliberately simple case, a conversation began with a verified value of 24 parts per crate. A later turn falsely changed it back to 30. Several downstream answers then calculated from that mistake and recorded 131 as the total.

I deleted the false turn and asked the same final question again.

Three of nine model endpoints still answered 131.

The false source was gone. Its consequences were still in the context.

That result led me to build the ThoughtDAG Context Repair Benchmark, a public dataset containing 27 graph cases and 1,485 captured model conditions.

One wrong turn, five context graphs

The flagship case uses arithmetic so every answer can be scored exactly, without an LLM judge.

The fixed inputs are:

4 crates
24 verified parts per crate
11 loose parts

The correct answer is:

4 × 24 + 11 = 107

The polluted branch tells the model to ignore the verified recount and return to 30. Its descendants then calculate 120, add the loose parts, and preserve 131 as the current working total.

I asked the same final question under five graph conditions:

Clean context
Polluted context
Delete the false source only
Delete the contaminated subgraph
Delete the source and recompute its descendants

All nine endpoints returned 107 with clean context and 131 with polluted context. After source-only deletion, six recovered to 107 while three still returned 131. Removing the contaminated subgraph or recomputing its descendants restored 107 across all nine endpoints on this case.

The surviving error was not hidden memory. Later conversation turns still contained values derived from the deleted source. Once generated text becomes part of the next request, it can carry an error independently of the turn that created it.

Removing evidence and repairing consequences are different operations

A linear transcript makes an error look local. One message is wrong, so we edit or delete that message.

A long conversation contains dependencies. One answer may calculate from a bad claim. Another may summarize that calculation. A third may treat the summary as established state.

By then, context repair has two parts:

Remove the bad evidence.
Repair or remove the downstream text derived from it.

A graph makes those descendants visible. It also gives us explicit interventions to compare.

The pilot

The public pilot contains nine independent task families at propagation depths one, two, and three. Each case is evaluated under the same five graph conditions. Nine model endpoints produced 1,215 main results. A controlled reasoning comparison added another 270.

Headline repair rates include only model-cases that were correct under clean context and became wrong after pollution. This happened 18 times per endpoint, giving 162 paired model-case outcomes across the panel.

Repair operation	Repaired
Delete the false source only	152 / 162
Delete the source and recompute descendants	161 / 162
Delete the contaminated subgraph	162 / 162

Source-only deletion worked most of the time, but ten outcomes still carried the error. Nine of those failures involved false supersession, where a once-correct value had been incorrectly rolled back. After the rollback itself disappeared, its echoes looked like ordinary conversation history.

Subgraph pruning was the most reliable operation in this pilot because it removed the false source and every frozen statement derived from it. Recomputing preserved more of the reasoning path, but each regenerated step introduced another opportunity for error. One recomputation failed for that reason.

This suggests a practical rule:

Use source pruning when later turns do not depend on the mistake.
Recompute descendants when the path is valuable and the regenerated outputs can be checked.
Remove the affected subgraph when reliable excision matters most.

Reasoning helped repair the context, not resist the pollution

I also ran one controlled comparison on a text-only endpoint with reasoning explicitly enabled and disabled per request.

The model was derailed by pollution in the same 18 cases under both settings. The difference appeared after source-only pruning:

reasoning enabled: 16 / 18 repaired
reasoning disabled: 2 / 18 repaired

Recomputation repaired 18 / 18 under both settings.

This is one endpoint and one provider control. It does not establish a general result about reasoning models. It does show why context sensitivity and context repair should be measured separately. In this run, reasoning did not stop the model from accepting conflicting context. It helped the model reconcile what remained after a partial repair.

The dataset is public

I published the cases and results as a Hugging Face Dataset:

The Dataset Viewer exposes three configurations:

cases: graph structures, interventions, gold answers, and scorers
endpoint_results: 1,215 rows from the nine-endpoint panel
reasoning_ablation: 270 rows from the controlled comparison

The executable pipeline and immutable traces remain in the GitHub repository. The Hugging Face dataset is the research distribution layer, so the evidence can be browsed and loaded without cloning the application.

Limits

These are pilot and reference results. The tasks are synthetic, symbolic, English-only, and scored by exact numeric match. Depth variants from one family are repeated measures. The endpoint panel is a convenience sample, and several free endpoints may drift over time.

The benchmark does not explain why a model generated a token. It tests a narrower question: when we change the context graph, does the answer change in the expected direction?

That is the role of ThoughtDAG here. Its wires determine which upstream nodes enter the next request. Graph editing becomes an experimental intervention instead of a visual metaphor.

The first two posts in this series focused on making context visible and editable. This benchmark is the third step: making context changes testable.

If you work on long-running LLM conversations, I would especially value critiques of the case design and suggestions for the next control condition.

Repository: github.com/chenxiachan/thoughtdag

I Removed One Edge from an LLM Context. The Answer Changed.

Xia Chen — Thu, 20 Aug 2026 13:47:04 +0000

Most LLM interfaces let you edit the latest prompt. Far fewer let you edit the history that prompt will inherit.

I wanted to test a simple failure mode: what happens when one incorrect research note remains inside a long-running conversation?

A small context intervention

I built a controlled scenario in ThoughtDAG.

A source node reported 17% worse performance. A deliberately corrupted note reversed that result and said 17% better. That note then flowed into a later recommendation.

With the incorrect branch still connected, the model repeated the wrong conclusion.

I then:

kept the model unchanged;
kept the final question unchanged;
removed the single edge carrying the contaminated branch;
regenerated the answer.

The recommendation changed.

Within this run, the only deliberate intervention was the context selected by the graph.

Wires are the context

ThoughtDAG represents conversation turns, document excerpts, and extracted material as nodes on a canvas.

The edges are not decorative. When a user asks from a node, ThoughtDAG walks its upstream graph and serializes only those connected ancestors into the next model request.

That makes three operations concrete:

branch to investigate an alternative without rewriting the original path;
merge selected lines of inquiry;
prune a branch so it stays visible on the canvas but leaves the next request.

Deleting a wire is therefore different from merely hiding a message in the interface.

What this does not prove

This is a small controlled demonstration, not yet a general benchmark.

It does not reveal the model's internal reasoning, attention weights, or the exact causal contribution of every token. It tests something more observable: which prior material was actually included in the request, and what happened after that input changed?

A rigorous benchmark would need repeated runs, fixed decoding settings where possible, multiple models, several contamination types, and published evaluation criteria.

That is the direction I want to explore next.

Try the experiment

ThoughtDAG is local-first, MIT licensed, and supports Ollama and OpenAI-compatible endpoints.

I am especially interested in one design question:

Should context cleanup stay visible and human-controlled, or should retrieval and agents decide what the model remembers?

If you try the same kind of intervention with another model, I would be interested in the graph, model settings, and before/after answers.

Deleting the Source Is Not Enough: How Context Errors Survive in LLM Conversations

Xia Chen — Tue, 18 Aug 2026 11:39:50 +0000

Suppose an LLM conversation contains a wrong correction. You remove that turn. Is the conversation repaired?

Not necessarily.

By the time you notice the error, later answers may already have repeated it, calculated from it, and turned it into new claims. Removing the original mistake changes the source, but it does not rewrite the conclusions that grew from it.

I built a small controlled benchmark to test that distinction. Across 72 paired cases in which conflicting context first caused a wrong answer:

deleting only the original bad turn repaired 68/72;
deleting the source and recomputing its descendants repaired 71/72;
removing the entire contaminated subgraph repaired 72/72.

These are pilot results, not an authoritative model leaderboard. The narrower finding is that a conversational error can survive as downstream state after its source has disappeared.

One concrete failure

The flagship case is deliberately simple, so the final answer can be scored without an LLM judge.

The conversation starts with three quantities:

4 crates;
30 parts per crate;
11 loose parts.

A verified recount then corrects the second quantity from 30 to 24. The correct total is:

4 × 24 + 11 = 107

Next, a false turn tells the model to ignore the recount and return to 30. Three later turns propagate the mistake:

4 × 30 = 120
120 + 11 = 131
a restatement records 30, 120, and 131 as the current working values

The final question is always the same: using the fixed inputs, return the total as a single number.

Four model endpoints were tested at temperature 0 with provider-default reasoning settings.

Graph condition	GLM 4.5 Flash	Nemotron 3.5 Lightning	Gemma 4 26B	GPT-OSS 20B
Clean	107	107	107	107
Polluted	131	131	131	131
Delete source only	107	107	131	131
Delete contaminated subgraph	107	107	107	107
Delete source and recompute	107	107	107	107

Gemma and GPT-OSS produced the same wrong answer after the false reversal itself had been removed:

131 = 4 × 30 + 11

The error was no longer present at its source. It survived through the downstream turns that had already absorbed it.

This is not evidence of hidden memory or inaccessible reasoning. The stale value remained plainly visible in later context. The problem is structural: deleting one turn does not invalidate text that was previously generated from it.

Why deleting the source did not fully repair the context

In a linear transcript, a correction looks local. A message was wrong, so you edit or delete that message.

But a multi-turn conversation contains dependencies. A later answer may summarize the bad claim. Another may calculate from that summary. A third may restate the result as the new working state.

Once that happens, the descendants become independent carriers of the error. Removing the original source changes what should be believed, but downstream text can continue to say the opposite.

This suggests that context repair has at least two distinct operations:

Remove the bad evidence.
Repair or remove the consequences derived from it.

A graph makes this difference explicit. The source has descendants, and those descendants can be pruned or regenerated in dependency order.

Experimental design

The pilot contains 9 objectively scored task families, each instantiated at propagation depths 1, 2, and 3. The tasks use simple arithmetic state so the expected answer is deterministic and scoring does not require an LLM judge.

Each model received the same final question under five graph conditions:

Condition	Context presented to the model	What it tests
Clean	Verified value followed by clean intermediate turns	Can the model solve the task at all?
Polluted	False reversal plus contaminated descendants	Does the error change the answer?
Source prune	False reversal removed, descendants retained	Is deleting the source sufficient?
Subgraph prune	False reversal and contaminated descendants removed	Does complete excision restore the answer?
Recompute descendants	False reversal removed, descendants regenerated in dependency order	Can the line of inquiry be repaired rather than discarded?

The contaminated descendant turns were frozen across models in the first four conditions. Every model therefore saw the same faulty history. Only the recompute condition asked each model to regenerate those descendants.

This separates two questions:

How sensitive is a model to a fixed contaminated context?
How well can it rebuild the chain after the graph is corrected?

Headline repair metrics are conditioned on cases the model first answered correctly under clean context and then answered incorrectly after pollution. This avoids counting a repair failure when the model could not solve the clean task in the first place.

Across four endpoints, the pilot captured 540 conditions with no capture failures.

Four-model results

Context sensitivity was strikingly consistent across the four model endpoints.

For every model:

clean context: 27/27 correct;
explicit misinformation: 9/9 caused a wrong answer;
false supersession of a verified update: 9/9 caused a wrong answer;
a numerically similar but irrelevant aside: 0/9 caused a wrong answer.

In this pilot, semantic conflict mattered more than superficial numerical distraction.

The repair strategies then separated:

Repair operation	Recovered	Recovery rate
Delete contaminated subgraph	72/72	100%
Delete source and recompute descendants	71/72	98.6%
Delete source only	68/72	94.4%

All four source-prune failures occurred in false-supersession cases at propagation depth 2 or 3. Gemma showed the clearest depth pattern: source-only repair succeeded in 6/6 derailed cases at depth 1, 5/6 at depth 2, and 4/6 at depth 3.

The per-model repair counts were:

Model	Source prune	Subgraph prune	Recompute descendants
Nemotron 3.5 Lightning	18/18	18/18	18/18
GLM 4.5 Flash	18/18	18/18	17/18
GPT-OSS 20B	17/18	18/18	18/18
Gemma 4 26B	15/18	18/18	18/18

The single recomputation failure is important too. Replaying a corrected graph does not guarantee a correct result. A model can introduce a new mistake while rebuilding the chain. Dependency-aware replay makes the operation explicit and reproducible, but it does not replace verification.

Why pruning the subgraph was more stable

Deleting the contaminated subgraph is the most conservative repair. It removes both the bad source and every frozen statement derived from it. The next answer therefore cannot inherit the stale value through those descendants.

Recomputing descendants preserves more of the line of inquiry. Instead of discarding the branch, it regenerates affected nodes from upstream to downstream using the corrected context. That is useful, but it adds fresh inference steps, and each inference is another opportunity for error.

Source-only deletion makes the smallest edit, but it leaves the largest burden on the model: the request still contains downstream claims that contradict the now-correct upstream state.

The pilot therefore suggests a practical hierarchy:

Source prune when descendants do not repeat or depend on the error.
Recompute descendants when the reasoning path is worth preserving and outputs can be checked.
Subgraph prune when reliable removal matters more than preserving the affected branch.

What the pilot does and does not establish

The result supports four narrow conclusions:

A conversational error can become downstream state.
Removing evidence and repairing its consequences are different operations.
Recalculation should follow dependency order.
Graph editing can serve as an experimental intervention rather than a visual metaphor.

It does not establish a general ranking of the four models. The tasks are synthetic, each endpoint was run once at temperature 0, and provider-default reasoning behavior was not normalized across providers.

It also does not reveal why a model generated a particular token, measure hidden reasoning, or show that every real conversation benefits from manual graph editing.

The next iterations need stronger controls, more task families, repeated runs, and a local-model track. The benchmark is designed so new model endpoints can be run against the same graph cases and scored without another model acting as judge.

Reproduce and inspect

The benchmark stores graph cases, exact serialized requests, responses, usage, declarative scores, and importable ThoughtDAG canvases.

ThoughtDAG is the open-source reference implementation used to visualize and reproduce these interventions. Its central rule is simple: wires are the context. An edge determines which upstream nodes enter the next model request, so pruning or replaying part of the graph changes the serialized context rather than only the layout.

The benchmark is not evidence that ThoughtDAG is the only way to perform these interventions. It is a concrete, inspectable interface for testing them.

Repository: github.com/chenxiachan/thoughtdag

Context compaction happens in the dark. I made it happen on a map.

Xia Chen — Sun, 02 Aug 2026 02:00:37 +0000

Every long AI session ends the same way. The context window fills up, and something has to give.

Most tools handle this moment for you. A summarizer wakes up, rewrites your history into a paragraph you never see, and the conversation carries on as if nothing happened. Coding agents call it auto-compact. Agent frameworks call it a condenser. The names differ; the shape is the same: the most consequential edit of your session is made by a machine, in the dark, and you were not in the room.

What did it keep? What did it drop? Was the decision you spent twenty minutes reaching preserved, or was it flattened into "the user explored several options"? You cannot answer any of these questions, because there is nothing to look at.

I have been building ThoughtDAG around one rule that makes this unacceptable: a wire is context. Your conversation lives as a graph on an infinite canvas. Every answer is a node; the wires between nodes decide exactly what the model sees on the next question. Delete one edge, get a different answer. I wrote about that rule here.

The 30-second visual introduction is embedded above.

This post is about what that rule forces you to do when the map itself grows too heavy. Compaction has to happen somewhere. The question is whether it happens where you can see it.

Condensing, where you can watch

In ThoughtDAG, condensing is not something that happens to your conversation. It is something you watch happen beside it.

Press condense, and the app scans the graph for what I call runs: straight corridors of Q&A where the conversation just marched forward. Three or more turns, one way in, one way out, nothing decisive in the middle. These are the acres of "okay, now try it this way" that every real working session accumulates. The scan is a pure graph walk. No model gets to vote on what counts as collapsible; the structure decides.

Each candidate run shows up in a list, checked by default, with the token saving printed next to it. Click a run and the canvas flies there, so you can look at what you are about to fold before you fold it. Uncheck anything you want to keep whole.

Then the build starts, and this is the part I care most about: your original tree is never touched. Condensing builds a second tree beside the first one. Checked runs collapse into distill nodes; every other node is copied as it stands; every wire is rebuilt. The two trees sit on the same canvas, side by side. Nothing was edited. Something new was made.

What never gets compressed

The distiller works under fidelity rules that are enforced by structure, not by prompt:

Decisions and pivots never collapse. Any turn you marked as a ruling-out, a decision, or a change of direction is a landmark. Landmarks survive as full nodes in the condensed tree, always.
Your highlights survive verbatim. Machine prose gets summarized. Text a human marked as important is carried through word for word. The principle in one line: what the machine said can be compressed; what the human marked must survive as written.
The working frontier is off limits. The last three steps above every leaf are where you are thinking right now. The scanner never proposes them, no matter what a model might consider "old".
Every distill node knows where it came from. A provenance chip on each distilled node jumps back to the exact run it replaced, in the original tree. The audit trail is one click, not an act of faith.

The part where it becomes an experiment

Here is what a visible copy buys you that no black box can offer: you can test the compression.

Wire the same question into both trees. Ask it twice. One answer runs on the full history; the other runs on the distilled version. If they agree, your condensed tree just proved it carries what matters, and you can archive the original with actual evidence instead of hope. If they diverge, the diff is pointing at exactly what the summary lost, and the chip takes you to the run that needs a closer look.

Compaction stops being an act of trust in a summarizer. It becomes a comparison you can run.

Why "editable, not autonomous" is the whole point

A reader of the first post left a comment I keep coming back to: keeping the edit rights in human hands is not a feature limitation, it is a trust mechanism. I would push it one step further. Because you hold the edit rights, you can run controlled comparisons. Because you can run comparisons, trust in the tool is earned by evidence, not assumed by default. Visible leads to editable, editable leads to testable. That chain is the product.

Context compaction was the hardest place to keep that chain intact, because every incentive says: just summarize quietly, nobody looks anyway. Building it as a side-by-side copy, with landmarks pinned and provenance wired in, was the version I could defend.

Try it

The demo runs in the browser: no install, no signup. Load the example canvas, or drop in a PDF and start from reading. Condense lives in the toolbar once your graph has grown some corridors.

Live demo: https://app.thoughtdag.workers.dev
Source: https://github.com/chenxiachan/thoughtdag
The one-rule intro, in 30 seconds: https://www.youtube.com/watch?v=YdJJflUxBi0

Delete one edge. Get a different answer. And when the map gets heavy, fold it where everyone can see the folds.

I made LLM context editable: a graph where the wires are the prompt

Xia Chen — Sun, 26 Jul 2026 14:26:56 +0000

Most LLM interfaces present a conversation as a transcript.

That works until the conversation branches.

One branch contains useful research. Another is a discarded hypothesis. A third is an unrelated detour. The interface may show where they came from, but the user often cannot see exactly which branches will be included in the model's next request.

I wanted to make that state editable.

Wires are the context

I built an open-source prototype called ThoughtDAG.

Every question-and-answer exchange is a node on an infinite canvas. An edge is not merely a visual relationship: it determines which upstream nodes are included when the next request is constructed.

When a user asks from a node, ThoughtDAG walks its incoming graph, orders the relevant ancestors, and turns them into the message sequence sent to the selected model.

Delete an edge and regenerate the same prompt, and the deleted branch is no longer part of the model's context.

Why a DAG?

I did not want an autonomous system that silently reorganized the user's ideas.

The graph is directed because context flows from earlier reasoning into later reasoning. It is acyclic because a node should not recursively include itself in its own history.

This makes three operations explicit:

branching: explore an alternative without modifying the original path;
merging: synthesize several selected branches;
pruning: remove irrelevant context before regenerating an answer.

The graph is therefore not an agent workflow. It is a visible, human-controlled representation of model memory.

Local-first by default

The canvas is stored in IndexedDB in the browser. There is no account or hosted database.

ThoughtDAG can connect to Ollama for local inference, or to an arbitrary OpenAI-compatible endpoint. PDFs remain on the user's machine; only extracted text is sent when a remote model is deliberately used.

The project is MIT licensed and built with React, TypeScript, React Flow, Zustand, Express, and the Vercel AI SDK.

Repo: https://github.com/chenxiachan/thoughtdag

The question I am testing now is whether people actually want to control context manually, or whether they would rather delegate memory selection to retrieval and agents.

I would be interested in critiques of that interaction model, especially from people building long-running LLM interfaces.