OpenKnowledge

What it is

A local-first WYSIWYG markdown editor — editing .md feels like Notion — that doubles as the knowledge substrate coding agents read and write. It ships no agent loop of its own. Instead it plugs into Claude Code, Codex, Cursor, and OpenCode as (a) a stdio MCP tool-server, (b) a cross-harness SKILL.md, and (c) a CLI scaffolder that wires all of that up. If Omnigent is the meta-harness that wraps agents from above, OpenKnowledge is its mirror image: the substrate agents mount from the side. Reading both together brackets the whole “build on top of coding agents” design space.

What’s worth studying

OpenKnowledge answers a question Swisscheese also has to answer: once an agent produces work, how do you make that work reviewable, attributable, and curatable over time? Five patterns earn the read.

1. Integrate at the protocol the agent already loads. OK never reverse-engineers a harness — it writes the MCP config file each one reads and drops a SKILL.md where each looks for skills. The per-vendor mess (config path, JSON vs. TOML, nesting key, skill dir) is captured as data in one EditorMcpTarget struct, not branching code; adding a harness is appending a 12-line object. It’s the outbound twin of Omnigent’s inject-without-owning. See harness integration and tool-calling-formats.
2. The agent is just another CRDT peer. Agent edits aren’t a diff in a staging panel — they are Yjs writes into the same live document a human is editing, with the agent’s avatar in the presence bar. Review happens after, via a per-agent activity panel with selective rollback (“undo everything this agent did in this file”) and an append-only timeline. A different bet than diff-gating up front, and the right one when N reviewers touch one artifact at once. See agent-as-crdt-peer.
3. The audit trail is the storage format. Every edit — human or agent — becomes a real git commit on a per-writer ref (refs/wip/main/{writerId}) in a shadow repo, with a JSON footer carrying agent_type, agent_session, client_version, and the docs touched. Attribution can’t drift from reality because there’s no separate log to drift. See agent-edits-as-git-commits.
4. The tool result is the agent’s playbook. The workflow MCP tool returns instruction prose, not data — call it with kind: research and you get an 8-step gated procedure; kind: consolidate returns a different one. The method is injected per tool call and versioned server-side. This is markdown-as-skills pushed to its conclusion. See knowledge workflows.
5. Provisional → canonical with a human decision gate. Research articles are typed status: provisional and must hedge; promotion to canonical is refused until a human confirms a decision landed, and leaves an immutable supersedes chain. Curation discipline encoded as a guardrail, not a vibe.

A sixth, smaller lesson: skill as the floor, MCP as the ceiling. The discovery skill is written to work with bare ls/cat/grep — “no MCP server required” — so the integration never hard-fails when the rich tools aren’t loaded.

Drill-down

The full per-doc analysis lives below — these are the original numbered analyses, rendered as styled HTML. Pick a section to study deeper.

• OpenKnowledge — Repository Analysis
• Architecture
• Harness Integration — the bridges
• The MCP Tool Surface
• Knowledge Workflows — the tool that returns a playbook
• Skills — markdown that teaches the agent
• Collaboration & the Agent-as-CRDT-Peer
• Git Sync & Audit-by-Construction
• Desktop Runtime — Electron, the terminal “TUI”, deep links
• Agentic Search — hybrid lexical + semantic, fused with RRF
• LLM Leverage Patterns
• File-to-Responsibility Map