How I use Obsidian as operating memory

I use Obsidian less as a place to store notes and more as a place to keep work context usable.

The difference is practical. A saved note is only useful if I can recover why it mattered, what decision it supports, what project it belongs to, and what should happen next. Otherwise the vault becomes another archive I trust in theory but rarely use under pressure.

My goal is simple: reduce the amount of context I have to reload manually when I return to a project, brief an agent, open an issue, review a pull request, or turn a rough idea into a public note.

What Obsidian gives me

The value is not the graph view or the feeling of having a perfect second brain. The value is that Markdown files give me a durable, local, searchable operating layer.

The benefits I care about are concrete:

• Continuity: project decisions, constraints, and open questions survive beyond a chat session.
• Retrieval: I can pull back the context behind a decision instead of reconstructing it from memory.
• Separation: private notes, project briefs, public drafts, and execution tasks do not have to live in the same place.
• Portability: the vault is plain Markdown, so it can be read by Obsidian, scripts, agents, GitHub workflows, or future tools.
• Reviewability: important ideas can move from note to issue to PR before anything becomes public.
• Compounding: when a note is written with enough context, it becomes reusable input for future work instead of a one-time thought dump.

That is why I do not treat every note as equally important. Some notes are just capture. Some become briefs. Some become GitHub issues. A smaller number survive review and become published writing.

How my vault is organized

My vault follows a modified PARA structure. It is not meant to be elegant. It is meant to make the next action easier to find.

• 00 - Inbox/ is for unprocessed notes, raw captures, and material that still needs classification.
• 01 - Daily/ keeps chronological notes, journal entries, meeting notes, and planning notes.
• 02 - Areas/ holds ongoing responsibilities such as career, finance, people, personal admin, and strategy.
• 03 - Projects/ is where active project context lives. IrishTalents, the personal site, and other current work get their own folders with specs, notes, kanban, and assets.
• 04 - Resources/ keeps reference material: prompts, books, courses, articles, clippings, language notes, and reusable inputs.
• 05 - Knowledge/ is the longer-term knowledge base for concepts, technical notes, business ideas, product thinking, and evergreen material.
• 06 - Archives/ holds completed projects and older imported material.
• 07 - Assets/ stores images, files, drawings, and support material that should not live inside a note body.
• 99 - System/ contains templates, agent instructions, scripts, dashboards, and operational metadata.

This structure gives agents and humans the same map. When Hermes needs context, it can inspect the vault with predictable assumptions: projects live under 03 - Projects/, prompts under 04 - Resources/Prompts/, system rules under 99 - System/, and unprocessed material under 00 - Inbox/.

The cron layer

The important change is that the vault is not only something I open manually.

I have recurring Hermes jobs that read from the vault, the repo, and GitHub Projects, then produce reviewable outputs. Some examples:

• a personal-site journal worker that turns approved GitHub issues into draft posts, visual assets, LinkedIn copy, validation results, and PRs;
• a weekly backlog curator that looks for useful personal-site content opportunities;
• a weekly Obsidian context curator that reviews project notes and keeps operating context from going stale;
• research and digest jobs that save useful inputs back into the vault for later review.

That does not make the system autonomous in the final sense. The cron jobs move work forward, but they should not decide what my public voice is, what is private, or what deserves to be published.

The loop is:

1. Capture rough context in Obsidian.
2. Organize it into the right folder or project area.
3. Turn actionable work into GitHub issues with constraints and acceptance criteria.
4. Let Hermes pick up the issue on a schedule.
5. Review the branch, diff, article draft, image, and sharing copy before anything is published.

Obsidian holds the slower thinking. GitHub Projects holds state. Hermes moves through the execution layer. The repo and PR keep the output honest.

Why this is better than a note archive

A note archive can feel productive while still hiding the real problem: nothing tells you what should happen next.

The practical test I use is this: can this note help me take the next step?

That next step might be:

• make a decision;
• write a brief;
• open an issue;
• validate a claim;
• brief an agent;
• review a PR;
• discard an idea;
• publish something after review.

If the note cannot support any of those, it may still be useful, but it should not pretend to be operational memory.

What stays human

The more I connect Obsidian to agents, the more important the boundaries become.

I do not want an agent wandering through private notes and deciding what belongs in public. I do not want rough strategy flattened into generic content. I do not want a beautiful image or polished paragraph to bypass judgment.

So the human layer stays explicit:

• I choose which notes are relevant.
• I decide which issues are ready.
• I set the risk boundary for public content.
• I review whether the result sounds like me.
• I decide what gets merged, published, or discarded.

That is the version of “AI brain” that makes sense to me: not a replacement mind, but a memory-backed operating layer.

The goal is not to remember everything.

The goal is to make the right context available when it is time to act.