OpenKnowledge vs Obsidian for a team Claude can read

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

This is an evaluation checklist, not a tested feature comparison. We have not established a reproducible head-to-head trial of OpenKnowledge and Obsidian.

So here is the honest version: what Obsidian actually gives an engineering team working with Claude Code, and the criteria to apply to any alternative you are weighing against it.

What Obsidian gets right for agent work

The vault is a directory of plain markdown files on your disk. That single property does most of the work. Point a coding agent at the folder and it reads your architecture notes, incident write-ups, and decision records with no connector, no API key, and no export step.

Concretely, this is what makes a session useful: you keep notes/decisions/ in the vault, and when you ask why the payments service retries three times, the answer comes from your own write-up rather than from a guess. Check whether the agent resolves your actual wiki links, aliases and duplicate note names; plain file access alone does not reproduce Obsidian’s link resolution.

The weak spots are real. Multi-person editing depends on whatever sync you bolt on, and merge conflicts in markdown are ugly. Plugin quality varies and a broken one can wedge the app. There is no permission model inside a vault, so sensitive notes need filesystem permissions or an isolated environment that the agent cannot read; a separate vault by itself is not an access boundary.

The criteria that decide it

• Plain files or a database? If the content lives behind an API, every agent workflow needs a connector, and connectors break.
• Can you grep it? If yes, an agent can search it cheaply and deterministically.
• Does it version with git? Decision records are worth far more with history attached.
• Is the export lossless? Test this before you commit, not after two years of notes.
• Does it survive the vendor? Markdown on disk does. Most other formats do not.

Score whichever tools you are considering against those five. If OpenKnowledge is on your shortlist, that list is the evaluation, and you can run it in an afternoon with a trial account.

The part nobody chooses correctly

Tool choice matters less than the writing habit. Test retrieval on maintained decision records rather than counting notes. Ask why a retry policy exists, where its supporting incident is recorded, and whether a renamed note still resolves after export.

Whichever tool wins, keep the engineering knowledge that agents need close to the repository. A short docs/decisions/ directory inside the codebase beats a perfectly organised external wiki, when the agent can discover it and changes receive review. Proximity alone does not load every file into context or prevent stale notes.