Hermes Agent Has a Living Map for Memory and Skills - Brooklyn's Shareable Visualization

Brooklyn posted a "living map" for Hermes Agent on June 30 - an animated, shareable visualization of every memory entry and skill an agent has accumulated. The tweet hit 85 likes, 39 bookmarks, 10 replies, and 3,741 impressions within hours, and the replies are all the same shape: "is there a repo?" The technical substance is not just the visualization itself. It is the underlying observation that the agent's accumulated state is now a real, inspectable artifact - and that the data sources for that artifact are scattered across at least five different files and one SQLite database.

What the tweet actually shows

The video walks through an agent's accumulated state in chronological order. New memories light up as they are written. New skills bloom as they are created. The agent's full history is compressed into a single replayable artifact that you can hand to someone else. "Copy yours into a code, paste a friend's to explore theirs" is the social mechanic: the visualization is the share format, and the underlying data export is the export format.

This is the first time someone in the ecosystem has packaged an agent's growth as a shareable artifact instead of a private dashboard. The 39 bookmarks (vs. 85 likes) signal the audience is operators who want to inspect their own agents, not just casual viewers.

What the map is actually mapping

The visualization has to draw from somewhere. The Hermes memory and skill surface in v0.16.0 spans five distinct on-disk sources:[^1]

The two built-in memory files are deliberately tiny. They are the agent's "sticky notes," injected as a frozen snapshot at session start to preserve prompt caching. Skills are markdown files in the skills directory. Sessions live in SQLite. None of these five surfaces export a unified view - until now.

Why this is interesting technically

The community had already built three visualization projects aimed at the same problem. None took off the way this tweet did.

AIhubmix/hermes-dashboard (visualization as a "four-layer self-evolution tree") maps the same five sources but renders them as a botanical metaphor: skills as canopy leaves, memory as trunk, sessions as roots, trajectories as seeds. It is a D3.js + Framer Motion tree with a Click any node traceback. Causal edges are inferred by timestamp proximity. The implementation is a 14-endpoint REST dashboard with a separate Python reader. It runs locally, not as a share.

southy404/hermes-mindscape takes a different shape: an Obsidian-style cognitive graph. It uses Hermes hooks to capture tool calls, reasoning snapshots, decisions, and memory writes, then renders them as typed nodes (manual, memory, reasoning, tool-call, decision, session, error) with semantic links. WebSocket updates keep the dashboard live. It is the most ambitious of the three - a real-time inspector - but it is a plugin that requires installation.

stainlu/hermes-labyrinth goes read-only. It is a static GitHub-Pages-runnable observability surface that turns each session into a "journey" with "crossings" (prompts, tool calls, results, failures, model switches, subagents, approvals, memory hits, redactions, context compression, cron runs). Current release v0.1.3. Secret redaction is applied at the journey-summary level, with the Hermes core redactor as the source of truth. It is the cleanest safety story of the three, since it never writes.

The pattern across all three: they are dashboards, installed locally, focused on the operator inspecting their own agent. Brooklyn's tweet inverts the model. The artifact is the share. The receiver does not need to install anything - they paste a code.

The data export problem underneath

If the tweet is real (the underlying visualization reads from actual agent state), someone had to solve the data export problem. Reading from five sources with different schemas and writing a single replayable artifact is not trivial:

• MEMORY.md and USER.md are flat markdown with ##-delimited entries. The agent's memory tool writes them via add / replace / remove actions. There is no write log.
• Skills are markdown files in ~/.hermes/skills/*/SKILL.md. The Autonomous Curator (since v0.12) moves them between active, stale, and archived states based on usage. The state lives in a metadata store, not in the files themselves.
• Sessions are rows in state.db with FTS5 indices. Each session has a start time, end time, and message log. Cross-session search goes through session_search.
• Trajectories are JSONL append-only logs, used for training-data generation. They capture every tool call with its result.

For a replayable visualization, the exporter needs a unified timeline. That means walking the disk for file write times (memory files, skill files), querying SQLite for session boundaries, and reading the JSONL for trajectory events. There is no API that returns "everything the agent knows in chronological order" - you have to assemble it.

The "copy yours into a code, paste a friend's to explore theirs" mechanic in the tweet suggests the export format is a serializable bundle (probably a base64-encoded JSON or a code-pasteable file) that contains the unified timeline plus the visualization payload. That format is the missing piece: a portable representation of an agent's accumulated state that does not depend on Hermes' internal file layout.

What this enables

Three concrete follow-ons that the existing dashboard pattern does not support:

Onboarding new agents. Hand an existing agent's map to a new agent. "Here is what a six-month-old Hermes deployment looks like. Notice the skill clustering, the memory growth curve, the session cadence." The new agent sees what mature state looks like before it has any state of its own.

• Sharing configurations. "47 skills, 28 memory entries, a session rhythm. Here is the map." The receiver inspects the shape, not the contents.

• Comparing across agents. Diff two agents' growth patterns. The dashboard pattern does not support this.

What is still missing

The tweet does not name a public repo. The 10 replies are uniformly requests for one. Without a public release, the visualization is currently a demo on a single agent.

The second gap: the data export is read-only. The map does not let you replay a memory write or replay a skill creation. Both Mindscape and Labyrinth support clicking through to detail. Brooklyn's map appears to be a viewing surface, not an inspector.

The third gap is the share format. If it is base64-encoded JSON, it is a black box. If it is a structured archive of the memory directory plus a session dump, it is auditable. The choice affects whether receivers can verify what they are looking at.

The "Press play to watch it unfold" framing is the cleanest summary. The agent's growth has always been there - scattered across five sources, hidden inside opaque file paths, invisible without a dashboard. Brooklyn's tweet is the first time someone has turned that growth into an artifact you can hand to someone else.

[^1]: Nous Research. "Memory - Hermes Agent." Hermes Agent Docs. Persistent MEMORY.md / USER.md files plus 8 external memory provider plugins. [^2]: Nous Research. "Skills - Hermes Agent." Hermes Agent Docs. SKILL.md format, agentskills.io standard. [^3]: AIhubmix. "hermes-dashboard." GitHub. Four-layer self-evolution tree visualization. [^4]: southy404. "hermes-mindscape." GitHub. Live cognitive graph plugin. [^5]: stainlu. "hermes-labyrinth." GitHub. Read-only observability plugin. [^6]: Brooklyn! on X. 85 likes, 4 retweets, 39 bookmarks, 3,741 impressions. Posted 2026-06-30 08:32 UTC.