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

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:

1. what the agent actually recorded;
2. what the user wants to keep, reorganize, or connect;
3. 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:

1. Which other local agent session format should be supported next?
2. 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.