IWE and OpenAI: How to Turn Markdown Notes into a Knowledge Graph for AI Agents

On IWE, they demonstrated how to convert a set of markdown notes into a full-fledged knowledge graph for people and AI agents. On top of it, the authors built an agentic RAG, connected OpenAI function calling, and taught the model to find answers not through flat files, but through connections between documents.

Graph Instead of Folder

At the heart of the example is IWE, a local Rust tool for working with notes through CLI and LSP. Its idea is simple: each markdown page becomes a node in the graph, and wiki-links and regular markdown links become directed edges between nodes. Because of this, notes can not only be read, but also traversed as a connected structure, where each document has context, neighbors, and hierarchy.

The author of the tutorial first collects a small knowledge base for a developer: architecture, authentication, database, API, frontend, deployment, caching, and performance notes. Then from these files, a KnowledgeGraph object is built with parsing of headings, tags, and links. On top of it, basic IWE operations are implemented to show that the graph is suitable not only for storage, but also for navigation and analytics.

• find — finds relevant notes by query
• retrieve — pulls a document together with related context
• tree — shows hierarchy and section map
• squash — merges several related documents into one
• export dot — prepares graph visualization through Graphviz

Where OpenAI Connects

The next layer is AI transformations of documents. In the article, for this they build an ai_transform function that sends a note to an OpenAI model and applies one of five scenarios: rewrite, summarize, expand, extract_todos, or generate_links. That is, the same knowledge base starts not only to store structure, but also to automatically rewrite, compress, expand, and link its nodes.

In the demo, this looks practical, not academic. The system briefly summarizes a note about authentication, suggests new wiki-links for it, and extracts a list of tasks from a note about performance. An important point is that AI works not in a separate sandbox and not over an export to a vector database, but directly on top of the same graph that the developer uses in the editor.

Agent Traverses the Graph

The most interesting part is the agentic RAG on top of the knowledge graph. For the agent, four tools are described: iwe_find, iwe_retrieve, iwe_tree, and iwe_stats. Through OpenAI function calling, the model itself decides when to search for an entry point, when to read a linked document, when to look at the section tree, and when to request overall statistics about the database. Then a search-retrieve-synthesize loop runs until the agent collects the answer.

In the examples, the agent answers questions about the dependencies of the authentication system, the deployment pipeline, and the overall project architecture. After that, the author goes even further: AI finds gaps in the graph, generates a new note about an error handling strategy, adds it to the database, and updates the visualization. The final test is a multi-hop question about load growth from 1000 to 5000 RPS, where the model needs to connect the database, caching, tokens, and infrastructure, rather than paraphrase a single file.

What It Means

This case well shows where practical RAG for developers is moving. Instead of another layer on top of vector search, IWE proposes using your personal knowledge base as shared memory for a person and an agent: with explicit links, graph traversal, local storage, and managed AI actions. For teams, this is an important signal: value increasingly lies not in the model itself, but in how well you organize and make context accessible.