IWE — Summary

IWE (written in Rust) turns a directory of Markdown files into a queryable knowledge graph for both human editors and AI agents. It ships four binaries: iwe (CLI), iwes (LSP server for editors), iwec (MCP server for AI agents), and liwe (core library). The Markdown graph is structured through "inclusion links" (a link on its own line means "this topic includes that subtopic") and "cross-references" (inline wikilinks). A note can belong to multiple topics simultaneously.

IWE has no built-in AI — it is purely infrastructure: a Rust-backed LSP + MCP server that lets both VS Code/Neovim/Zed and Claude/Cursor/Windsurf navigate the same Markdown files. The MCP server (iwec) exposes tools for find, retrieve, tree, squash, create, update, delete, rename, extract, inline, and normalize operations. The system processes 20,000 files in under one second.

Compared to seeds, IWE is closest to basic-memory (knowledge graph backed by Markdown files, MCP access for AI, human-editable). The distinction: IWE structures relationships exclusively through Markdown inclusion links (parent-child hierarchy), while basic-memory uses observation syntax (- [category] text) and typed wikilinks (- depends_on [[Entity]]). IWE also ships a full LSP server for IDE integration that basic-memory lacks.

IWE — Overview

Origin

Dmytro Halichenko. Apache-2.0 license. Rust. Version 0.1.8. Active development (last commit 2026-05-25). Available on crates.io as iwe, iwes, iwec.

Philosophy

From README:

"IWE turns a directory of markdown files into a knowledge graph — a connected structure you browse from your editor and your AI queries from the command line. Same files, same links, two interfaces. No cloud, no database, no lock-in. Version everything with git."

"IWE itself has no built-in AI — it works alongside Claude, Codex, Gemini, and any tool that speaks the Model Context Protocol."

Core tenets:

1. Plain markdown, full ownership — notes are .md files; version with git
2. A graph, not a folder tree — links + inclusion hierarchy over directory structure
3. Same files, two interfaces — human (editor + LSP) and AI (CLI + MCP) access the same Markdown
4. Multiple parents — a "Meditation" note can belong to both "Health" and "Productivity" without duplication

Two Link Types

• Inclusion links — a link on its own line: "this topic includes that subtopic." Forms a navigable tree.
• Cross-references — regular inline [[links]]: topic web of relationships.

Both types stored in .md files with no special metadata. IWE infers structure from link placement alone.

Performance Claim

"Fast. Built in Rust, processes 20,000 files in under a second."

IWE — Architecture

Distribution

• Homebrew: brew tap iwe-org/iwe && brew install iwe
• Cargo: cargo install iwe iwes iwec
• Crates.io: iwe, iwes, iwec

Four Binaries

MCP Server Tools (iwec)

From crates/iwec/src/lib.rs: iwe_find, iwe_retrieve, iwe_tree, iwe_stats, iwe_squash, iwe_create, iwe_update, iwe_delete, iwe_rename, iwe_extract, iwe_inline, iwe_normalize, explore

Directory Structure

crates/
├── liwe/    # Core Rust library
├── iwe/     # CLI binary
├── iwes/    # LSP server
└── iwec/    # MCP server (rmcp)
docs/        # Documentation

State Files

• ~/notes/ (configurable) — all Markdown files
• .iwe marker file — identifies workspace root
• config.toml — workspace configuration
• No database; graph is computed from live Markdown files on demand

Required Runtime

None — statically linked Rust binary.

Target AI Tools

Claude Desktop, Claude Code, Cursor, Windsurf, Codex, and any MCP client (via iwec). Editor support via LSP: VS Code (extension), Neovim, Zed, Helix.

Related Repos

• iwe-org/vscode-iwe — VS Code extension
• iwe-org/iwe.nvim — Neovim plugin
• iwe-org/zed-iwe — Zed extension
• iwe-org/skills — agentic AI skills for knowledge graph management

IWE — Components

MCP Tools (13, via iwec)

CLI Subcommands (iwe)

init, new, retrieve, find, count, normalize, tree, squash, export, schema, stats, rename, delete, extract, inline, update, attach, completions

LSP Features (iwes)

• Search (by title or content)
• Go-to-definition / find references (backlinks)
• Hover preview (see link content inline)
• Auto-complete (link suggestions)
• Inlay hints (parent refs, link counts)
• Extract (pull section → new note)
• Inline (embed note content → parent)
• Rename (files + all links update)
• Format (normalize document)
• Transform (pipe text through external commands)
• Templates (daily notes, etc.)
• Outline conversion (headers ↔ lists)

Hooks

None.

Skills, Commands, Subagents

None in this repo. The companion repo iwe-org/skills ships agentic AI skills for IWE knowledge graph management (separate repo, not analyzed here).

Scripts

None.

IWE — Uniqueness

Differs From Seeds

Closest seed: basic-memory — both use Markdown files as the source of truth with a knowledge graph accessible to AI agents via MCP. Key deltas: (1) IWE structures relationships through link placement only (inclusion = own line; cross-reference = inline), while basic-memory uses explicit observation syntax (- [category] text) and typed relation directives (- depends_on [[Entity]]). (2) IWE ships a full LSP server (iwes) for VS Code/Neovim/Zed/Helix; basic-memory has no LSP. (3) IWE is written in Rust (fast, zero-dep binary); basic-memory is Python (requires uv). (4) IWE has no database whatsoever — graph is computed from live files; basic-memory maintains a SQLite index. (5) IWE supports multiple parents for a single note without file duplication — basic-memory notes can be in one directory. Against ccmemory: IWE stores domain knowledge written by humans; ccmemory captures AI conversation history. They are complementary, not competing.

Positioning

"The knowledge graph that works equally well for humans and AI — same Markdown files, same links, two interfaces (LSP for editors, MCP for agents)." IWE is unique in this batch for its dual-interface design (human editors + AI agents on identical files simultaneously).

Observable Failure Modes

1. No semantic search — base install has no embeddings; iwe_find is fuzzy text search only. Different-wording queries fail to retrieve.
2. No hooks — IWE has no Claude Code lifecycle integration; agents must explicitly call MCP tools; no automatic context injection at session start.
3. No session memory — IWE stores what you write, not what Claude said; conversation history must be captured by another system.
4. Graph computation on demand — very large note repositories (100k+ files) may have slower iwe_retrieve --depth operations despite the Rust speed claim (20k files/sec for indexing; retrieval complexity depends on graph depth).
5. No AI-specific capture — there is no mechanism for Claude to automatically write insights back to the knowledge graph; it must explicitly call iwe_create or iwe_update.