Most AI knowledge tools make a quiet assumption: the model is the worker, and the human is the caller.
You ask, the system retrieves pages, the LLM synthesises them, you get an answer. Clean pipeline. One direction.
That assumption breaks the moment a reasoning model needs to use the knowledge base as a tool - not to answer a question, but to do work. Search for related pages. Read a contradicted entry. Write a resolution. Commit a lifecycle transition. Then search again based on what it found.
Now the model is the caller. The knowledge layer is the called. Same storage. Opposite direction.
This is the coordination problem that most knowledge tools never have to solve, because they pick one mode and stay there. Building a system that handles both cleanly turns out to be the interesting design challenge.
The Four-Interface Pattern
The clearest way to see the tension is through the four surfaces a well-designed knowledge system needs to support:
CLI : a human (or script) calls the system, which calls an LLM, which returns an answer. Streaming for humans, structured output for pipes. The model is a service.
IDE/App Plugin : same direction, richer context. The plugin renders wikilinks as navigation, exposes a lifecycle dashboard for human decisions. Still: human calls system calls LLM.
Web Chat UI : conversational, multi-turn, natural language operations. "Run lint." "Show me stale pages." The system interprets these and dispatches them. Still: human calls system calls LLM.
MCP : a reasoning model connects to the knowledge layer as a set of tools. It decides what to search, what to read, when to write, which lifecycle state to commit. The system is now memory. The model is now the brain.
The insight is that the first three interfaces share a common structure. The fourth inverts it entirely.
Why the Memory Layer Needs Opinions
Here is where the design gets non-obvious.
When a reasoning model can freely read, write, and transition pages, you need the storage layer to enforce constraints the model might not. A lifecycle transition graph that blocks invalid state changes. An immutable audit trail that records every edit and its stated reason, regardless of whether a human or an agent made it. Provenance tracking that ties every page to its source material.
These aren't features for the human users. They're the constraints that make it safe to connect a reasoning model to the same base a human is actively maintaining.
A model can call write_page then lifecycle_transition. What it cannot do is move a page from stale to contradicted - that transition isn't in the allowed graph. The memory layer enforces this the same way it enforces it for a CLI command. It doesn't care which surface issued the instruction.
The audit trail records triggered_by: mcp and the model's stated reason. Run the lifecycle log the next morning and the full chain is there, whether it was a human clicking in a plugin or an agent running at 2 AM.
The Hint Engine Doesn't Disappear
One question that comes up: if a reasoning model generates its own next steps dynamically, what happens to the deterministic hint engine that suggests follow-up queries?
It serves the human-facing interfaces. No LLM cost, instant suggestions based on current wiki health, contextual to what the user just asked. A reasoning model doesn't need that, it generates its own chains based on what it finds. Two different users, two different workflows, same storage layer.
The coexistence is the point. The four-interface pattern isn't about choosing between human-driven and agent-driven workflows. It's about a knowledge layer that supports both without leaking the distinction into the storage model.
Reference Implementation
The pattern described here is implemented in Synthadoc, an open-source AI knowledge base tool. The video above walks through all four interfaces against a live demo wiki - CLI queries, Obsidian plugin lifecycle management, web chat multi-turn conversation, and connecting Claude Code as a reasoning brain over MCP.
If you're building something similar, the part worth paying attention to isn't the interface count, it's the audit trail and transition graph. Those are what make the memory layer safe to connect to a model that can write, not just read.
Top comments (0)