During two weeks, I explored a recurring problem with coding agents: they are powerful in the moment, but a fresh session rarely remembers the work that happened before.
I already kept much of that context in Obsidian — daily notes, RFCs, decisions, presentations, and work logs. The first idea was simple: let an agent retrieve the relevant parts instead of replaying the whole project story by hand.
What changed the project was not merely giving the agent access to my journal. The agents started leaving useful memory behind too.
The shift: agents started journaling too
After a work session, an agent can capture what happened: the task, the decisions, the files involved, the checks that passed, and the open loops. That trace lives separately from my own notes.
Not every trace should become permanent documentation. Stable parts can be distilled later into decisions, concepts, project syntheses, or open questions. Obsidian stops being passive storage and becomes a memory the agent helps maintain.
Obsidian became the shared workbench
I now draft RFCs, implementation plans, diagrams, and exploratory notes with agents directly in Obsidian. The repository stays focused on code and durable project artifacts; the thinking and iteration live where the rest of the project context already exists.
That context is independent from a particular chat. I can start with Claude, continue with Codex, and return in a future session without treating the previous conversation as the only source of truth.
Retrieval, not file access
Agents already know how to read files. But reading files is not the same as querying project memory. With raw access, the agent must know what to open, can read too much, and can still miss the reason behind a decision.
Deep Obsidian MCP lets the agent search lexically or semantically, inspect summaries and deterministic chunks, follow links and backlinks, and only then read the notes that matter. The goal is not more context. It is better retrieval.
MCP alone is not enough
A tool does not create a workflow by itself. An agent can still search too broadly, write in the wrong place, forget to capture its session, or slowly fill the vault with noise.
What worked is a three-part system:
- MCP access: bounded reads and writes, hybrid search, graph traversal, and session capture.
- Agent skills: load context first, judge retrieval quality, work, capture, distill, and maintain.
- Vault architecture: human notes stay human-owned, agent traces stay separate, and durable knowledge has an explicit home.
A local-first architecture with boundaries
Deep Obsidian MCP is a Rust service that runs locally and indexes an Obsidian vault. Human-owned spaces remain untouched by default. Agent work traces live in:
_Agent/Sessions/Durable agent-maintained knowledge lives in:
_Wiki/The server provides bounded reads, deterministic chunks, BM25, semantic and hybrid search, related-note discovery, graph traversal, backlinks, controlled update helpers, session capture, and project-context loading.
Semantic retrieval can use any OpenAI-compatible embeddings endpoint with sqlite-vec. When embeddings are not configured, the server keeps a sparse local fallback. A private local provider such as Ollama also works.
The loop matters more than any single tool
The current workflow is deliberately small:
load → work → capture → distill → maintainBefore work, the agent recovers previous sessions, human notes, project syntheses, decisions, and open questions. After work, it captures a structured trace. Later, stable knowledge is promoted and stale material can be maintained instead of accumulating forever.
The architecture is inspired by the LLM-wiki pattern: memory remains useful because retrieval, capture, distillation, and maintenance form one loop rather than four unrelated tools.
What changed day to day
- less time spent replaying project context at the start of a session
- plans and drafts live in the right place instead of temporary repository files
- past decisions and validation results become recoverable history
- an agent can challenge a direction that the project already rejected and explain why
That last point is the interesting one. Memory changes the relationship: the agent is no longer reacting to an isolated prompt, but working inside a continuity.
Current state
Deep Obsidian MCP is still alpha, but it is already running against my real vault with embedding search active. The notes, sessions, and presentation behind this article were created in the same system the article describes.
The next technical work is larger-vault testing, automatic maintenance, and clearer governance for trusted shared context.
Toward shared project memory
The long-term direction is larger than personal memory. A project’s rationale should not live only in one person’s head, a chat thread, or an old pull request. Team members should be able to contribute governed sessions and durable notes, then let their own agents recover the real history behind the code.
memoryhistory · rationale · open loops
agent
Try it
The practical setup remains intentionally short:
brew install P4UL-M/tap/deep-obsidian-mcp
deep-obsidian-mcp setup-service --vault ~/Vault --mcp --skillsThe setup command installs the local service, configures supported MCP clients, and adds the packaged skills. Use --wizard for an interactive setup, --vault-snippets to hide the agent folders in Obsidian, and a local embeddings provider when the vault must stay entirely private.