AI Guides

Obsidian as AI Memory: The Vault Your Agent Deserves

An AI agent with 2,200 characters of memory is like trying to run a business on sticky notes. Here's how Obsidian vaults become the long-term brain your agent actually needs — and how I'm adding it to my existing memory hub.

2026-04-27 · 7 min read

Here's the problem with AI agent memory: it's tiny. My agent Dade gets 2,200 characters of persistent memory. That's less than a page of A4. It's enough to remember my name and timezone, but not enough to remember why Dade and I made a decision three weeks ago, or what we tried that failed, or how that one cron job is actually configured.

I've already built a hub-and-spoke system that compresses memory into pointer files — little signposts that say "the details are over there" instead of cramming everything into the 2,200-char box. It works. But I keep bumping into the next wall: where is "over there"?

The answer, it turns out, is Obsidian.

Why Obsidian?

I saw a post on the Hermes Agent subreddit from one of the mods named Jonathan Rivera that crystallised something I'd been feeling. He built a three-tier memory system using Obsidian as the backbone — not as a fancy AI notebook, but as a structured knowledge base the assistant can read from and write to autonomously.

His setup mirrors what I've been building toward, but with one critical difference: the vault isn't just storage. It's a living system that the agent maintains, queries, and evolves alongside the human.

The Three-Tier Model (Adapted)

Jonathan's model splits memory into three tiers. I'm adapting it to fit my existing hub-and-spoke architecture:

Tier 1 — Hot Memory (2,200 chars, injected every turn)

This is the existing Hermes memory store. It stays exactly as-is — the compact pointer system I already use. Communication preferences, active projects, recent corrections. The stuff Dade needs right now in every conversation.

Nothing changes here. This tier is already working.

Tier 2 — Vault Living Files (Obsidian, on-demand)

This is the new layer. When hot memory hits capacity (which it does constantly), entries that are stable enough get promoted to markdown files in the Obsidian vault. Environment configs, operational context, known failure patterns, tool quirks — the institutional knowledge that doesn't change every day but matters when it matters.

The agent reads these on-demand. When Dade needs to know the exact port OpenClaw runs on, or the GPU offload settings that actually work, or why I switched from fal.ai to local FLUX — it searches the vault. The per-turn context window stays lean, but the knowledge is never more than a query away.

This is where the hub-and-spoke system points to. The pointers in hot memory say "the details about cron jobs are in crons.md." That file lives in the Obsidian vault.

Tier 3 — Daily Notes (Searchable Timeline)

Every day, a dated note gets created: Daily/2026-04-27.md. It logs what happened — tasks completed, decisions made, bugs encountered, configuration changes. The agent records events throughout the day.

This creates something my current system lacks: a timeline. Not just "what do I know" but "when did I learn it and in what context." When you're debugging a problem that started two weeks ago, knowing the sequence of events matters more than knowing the final state.

What This Adds to My Existing System

My current memory hub has 26 spoke files across 7 topic groups:

These are great. They work. But they have three limitations:

  1. No timeline — I can see what the cron jobs are, but not when they were added or why. Daily notes fix this.

  2. No backlinks — When post 33 mentions the proxy and cron job 7 mentions the same proxy, there's no connection. Obsidian's [[wikilinks]] create a graph of relationships that grows organically.

  3. No human-readable browse experience — The memory files are optimised for the agent, not for me. Obsidian gives me a graphical interface to skim, search, and explore my own knowledge base.

The Morning Briefing Pipeline

This is the part that sold me. Jonathan's setup runs a cron job at 6:50 AM that:

  1. Fetches tasks and calendar events from APIs
  2. Creates a daily note with tasks, schedule, and an empty log
  3. Delivers a formatted briefing to Telegram at 7:00 AM

I already have cron jobs that do pieces of this. The daily memory dashboard, the weekly usage report, the Reddit trending capture. But they're scattered. They don't feed into a single daily briefing that I can read over coffee.

With an Obsidian vault as the central hub, every cron output becomes a section in the daily note instead of a standalone message. The briefing aggregates everything into one view.

Filing Rules — The Discipline That Makes It Work

The system only works if the agent knows where to put things. Jonathan's rules are clean:

I'm adding one more rule for my setup:

The Implementation (What I'm Building)

Here's the concrete structure I'm setting up:

obsidian-vault/
├── Daily/
│   └── YYYY-MM-DD.md          # Timeline entries (auto-created by morning brief)
├── System/
│   ├── hardware.md            # Machine specs
│   ├── networking.md          # Ports, router quirks, mobile access
│   ├── tech-stack.md          # Model routing, tools
│   ├── crons.md               # Scheduled scripts + paths + intervals
│   └── security.md            # Boundaries, safe mode, Telegram cmds
├── Issues/
│   └── issue-slug.md          # Troubleshooting logs with resolution status
├── Content/
│   ├── pipeline.md            # Blog post lifecycle + env marker tracking
│   ├── topic-backlog.md       # Ideas for future posts
│   └── blog-protection.md     # Never-publish lists, defence rules
├── Projects/
│   ├── vrs-computing.md       # Business project notes
│   ├── hard-interference.md   # Brand/editorial notes
│   └── local-ai-journal.md    # LAJ-specific project context
├── Design/
│   └── decision-log.md        # Why I chose X over Y
└── MEMORY.md                  # The hot memory source (syncs with Hermes)

The MEMORY.md file at the root is the bridge — it's the canonical source that syncs with Hermes's memory store. When Dade promotes an entry from hot memory, it writes to the vault. When Dade needs context, it searches the vault.

Why Not Just Use Files?

I already have the spoke files. Why add Obsidian on top?

Three reasons:

  1. The graph view — When the agent links decisions, people, and files in daily notes, Obsidian builds a visual map of how everything connects. You can't get that from a flat directory of .md files.

  2. The editing experience — Sometimes I want to browse my own system's memory. Not as raw files in a terminal, but as formatted, linked, searchable documents. Obsidian makes this pleasant.

  3. The agent can write to it — Hermes's write_file tool can create and edit markdown files in the vault. They are all local, no API keys, no OAuth, no middleware. The agent writes markdown, the vault updates, I see it in Obsidian. Simple.

The Sync Mechanism (Resolved)

The open question was two-way sync between Hermes's internal memory store and the Obsidian vault. After building it, here's what works:

Hermes is the source of truth. The memory tool still manages the hot store. When Dade promotes an entry, it writes the detail to the vault. When Dade needs context, it reads from the vault. The hub stays compact; the spokes live in ~/obsidian-vault/.

Mirror from Hermes → Vault. A cron job runs the session-log.py script 4× daily. It reads Hermes's memory files, mirrors them into the vault's System/ folder, and logs session summaries into Daily/ notes. One direction, one script, no conflicts.

Human edits flow back through the memory tool. When I want to change something in the vault — fix a port number, add a new spoke, update a project status — I edit the markdown directly in Obsidian. Then I tell Dade to update the corresponding memory entry. The agent reads the vault file, diffs it against the hot memory, and reconciles. No bidirectional sync daemon, no race conditions, no conflict resolution. Just one-directional writes with human-in-the-loop for anything that needs to flow back.

This is simpler than it sounds. The key insight: don't try to make two systems write to the same file. Let one system own the data, and let the other system read it.

The Bottom Line

Obsidian isn't replacing my memory system. It's extending it. The 2,200-char hot memory stays compact and fast. The spoke files stay as pointers. But now there's a vault behind them — a human-browsable, agent-writable, graph-connected knowledge base that turns my agent's amnesia into a solvable problem.

Three tiers. Hot memory for what you need right now. Vault files for what you need on demand. Daily notes for when you need to know what happened and why. Each layer solves a different problem, and together they cover everything an agent needs to remember — and everything a human needs to understand what their agent has been doing.

Your hardware. Your rules. Your memory.

➜ Previous: Create Your Agent's Own Brain — how hub-and-spoke solved the capacity problem ➜ Related: Stop Running in Circles — how the MC Memory tab made session history browseable ➜ Backstory: When Your AI Forgets What It Did — the original memory problem

Found this useful?
👉 Follow @Raf_VRS for more AI Guides
👉 Support the work: ko-fi.com/rafvrs
#HardInterference #AIMemory #Obsidian

Canonical static mirror for AI/search retrieval. Main article URL: open this Hard Interference article.