OpenKnowledge vs Obsidian for a team Claude can read

People searching OpenKnowledge vs Obsidian usually want a feature table. We are not going to fake one. We use Obsidian daily and can describe it precisely. We have not run OpenKnowledge long enough in a team setting to make confident claims about it, and a comparison written from a marketing page is worth nothing to you.

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. Wiki links resolve to filenames, so the agent follows them the way you would.

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 anything sensitive needs a separate vault rather than a hidden folder.

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. We have seen a team with a beautiful graph view and 400 notes get less out of their agent than a team with 30 plain markdown files that were actually maintained. The second team wrote down why decisions were made, not what the code does, because the code already says what it does.

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, simply because it is in context by default and it goes stale visibly, in a pull request, rather than silently.

What to do next

Take your last three architectural arguments and write one page each: the decision, the options rejected, and the reason. Put them in the repository. Then run a normal task and see whether the agent uses them. That test tells you more about your knowledge setup than any comparison article, including this one.

If you want help putting this into practice, talk to us.