Xandrov StudioAtlas of shipped systems
← The territory/ IV. Tools & Infrastructure/ № 14 — Session Graph
Dossier № 14 / 19 — Tools & Infrastructure — Internal tooling · Meta

Session Review Graph

The lab’s memory of its own work.

File
№ 14 / 19
Territory
Tools & Infrastructure
Classification
Internal tooling · Meta
Status
Running in production
§ 01 Context

AI coding sessions generate enormous amounts of decision history, transcripts, and agent metadata. Without a system to preserve and index it, this context typically vanishes — sessions get deleted, connections between projects and work evaporate, and the reasoning behind months of decisions becomes irretrievable.

This system was built to capture that history persistently and make it navigable. Every session and subagent run on the developer's machine is mirrored into a permanent local archive, indexed by project, session, and agent, then rendered as a searchable, zoomable interactive graph.

§ 02 The problem

The core challenge is that session transcripts are ephemeral by nature — they live in a cloud service and disappear when deleted. Projects and sessions have no explicit connection visible anywhere. Agent runs inside sessions lack any persistent index. Without cross-referencing, it is impossible to trace which agents worked on which projects, when, or what decisions were made.

Additionally, the volume is substantial: a typical machine accumulates sessions faster than a developer can manually organize them. The archive needs to be built on the source material itself, preserving everything including transcripts that have already been deleted upstream.

§ 03 The approach

A Node harvester runs on a schedule and mirrors the session transcript data byte-for-byte into a local archive, preserving even files that have been deleted at the source. It indexes all sessions by their project, timestamp, and associated agent runs, recording counts and first-prompt snippets for each.

The harvester emits a single self-contained graph.html file — no server, no dependencies — that renders the entire archive as an interactive graph. The visualization is zoomable and searchable. Every five minutes, a scheduled task regenerates the graph; a session-start hook injects a compact archive digest into each new session for quick reference.

The stack consists of a Node harvester for incremental mirroring, the self-contained graph.html output, a scheduled task runner, and incremental sync logic keyed to file modification time.

The lab's memory of its own work.

§ 04 Decisions that mattered
D1
Incremental sync, not full re-harvest
The harvester syncs only by file size and modification time. This keeps a five-minute run cycle cheap — no database queries or API polling overhead.
D2
Archive survives source deletion
Sessions deleted from the upstream service remain intact in the local archive. The preservation is byte-for-byte, so nothing is lost even if the source disappears.
D3
Structure and code published, transcripts withheld
The system ships as architecture, implementation, and example data but deliberately excludes the private transcript store. Users own their archives entirely.
D4
Single-file graph.html, no server
The entire archive renders into one static HTML file with embedded data and interactivity. Zoomable, searchable, and runnable offline — no web server or build step required.
D5
Session-start hook injects archive digest
Each new session automatically receives a compact summary of the archive, so developers can see the project and agent context without switching to another tool.
§ 05 Where it stands

The system is running in production on the lab's own machine, archiving over 80 sessions and roughly 1,500 agent runs. The index includes counts, timestamps, and first-prompt snippets for each session and agent, organized by project. The archive has become a searchable reference for the lab's own work — this studio redesign, for instance, was researched and traced through it.

Node harvesterSelf-contained graph.htmlScheduled taskIncremental sync
§ 06 — Sanitization record

The system is published as structure and code only. The private transcript database is deliberately withheld — users own their archives entirely, and sensitive decision histories, client data, and deleted content remain local. No credentials, scraped output, or session content are included in the public distribution.

Have a system like this worth building?

Fixed scope, quoted after one working session, first output inside two weeks. Read by a person within one working day.