Agent-Native Knowledge Base: How LLM Wiki Turns Every Agent into a Domain Expert
A fresh AI agent knows nothing about your business. It has general intelligence — reasoning, code generation, language — but zero domain knowledge. Ask it about your ERP configuration, your deployment dependencies, or your compliance requirements and it will hallucinate confidently.
This is the domain expertise gap. Every team deploying AI agents hits it. The common fix is RAG: chunk your documents, embed them, retrieve relevant chunks at query time. This works for simple factual lookups. It fails on the questions that require actual expertise.
An expert doesn't just retrieve facts. An expert understands how things connect — which modules depend on which configurations, which changes cascade through which systems, which decisions superseded which earlier decisions. That understanding is structural, not textual.
Agent.ceo's knowledge base — LLM Wiki — bridges this gap. It's a Neo4j-backed knowledge graph with MCP tools that agents use to read, write, traverse, and build domain knowledge over time. The result: agents that start as generalists and become domain experts through accumulated, structured experience.
The Domain Expertise Problem
Consider a manufacturing company running ERP provider ERP. The system has thousands of interconnected modules: procurement feeds inventory, inventory feeds production planning, production planning feeds cost accounting, cost accounting feeds the general ledger.
A new consultant joining this company needs 6-12 months before they can confidently answer cross-module dependency questions. They need to learn not just what each module does, but how changes in one module cascade through others.
Now consider an AI agent pointed at the same ERP system. With standard RAG, the agent can answer "What is the default batch processing timeout?" — a factual lookup. But ask "Which modules are affected if we change the reconciliation schedule?" and the agent fails. The answer requires traversing dependency chains that span dozens of documents written by different authors over years.
The knowledge is there. The relationships between the knowledge are not — at least not in a vector store.
How LLM Wiki Works
LLM Wiki is a knowledge graph, not a document store. The difference matters.
Documents become nodes. Each page in the knowledge base is a node in a Neo4j graph. Pages have types — Entity, Concept, Comparison, Source — and each gets an HNSW vector embedding for semantic search.
Relationships become edges. The graph captures typed connections between pages: DEPENDS_ON, CONFIGURED_BY, FEEDS_INTO, SUPERSEDES, DOCUMENTED_IN, TRIGGERS. These edges encode the structural knowledge that makes expertise possible.
Agents access the graph via MCP tools. Five core tools at wiki.agent.ceo/mcp give agents programmatic access:
- wiki_graph_vector_search — semantic discovery: find relevant starting nodes
- wiki_get_page — read specific pages by path
- wiki_graph_neighbors — traverse the graph from any node, following typed edges
- wiki_ingest_text — create or update pages from text content
- wiki_ingest_url — import and structure content from URLs
The critical insight: agents don't just read the knowledge base. They write to it. Every investigation, every incident resolution, every architectural decision becomes a page that future agents can reference and traverse.
From Generalist to Domain Expert
The transformation happens in three phases.
Phase 1: Ingestion — Building the Graph
Point LLM Wiki at your knowledge sources. A git repository. A cloud storage bucket. A set of URLs. The ingestion pipeline extracts content, generates vector embeddings, and — critically — identifies and creates typed relationships between pages.
For the ERP provider ERP example, this means ingesting 5,000+ pages of module documentation. The ingestion doesn't just store the pages — it maps the dependency graph: procurement → inventory → production planning → cost accounting → general ledger. Each connection is a typed edge that agents can traverse programmatically.
Phase 2: Traversal — Answering Expert-Level Questions
Once the graph exists, agents answer questions that no RAG pipeline can.
Query: "What breaks if we change the inventory valuation method?"
A vector search returns documents mentioning "inventory" and "valuation" — a reading list ranked by embedding similarity.
A graph traversal starts at the inventory-valuation node, follows DEPENDS_ON and FEEDS_INTO edges, and returns the actual dependency chain: inventory valuation → cost accounting → production cost reports → general ledger entries → quarterly financial statements. The agent doesn't guess at connections. It follows them.
Query: "What changed since the last auth service deployment?"
Vector search returns documents containing "auth" and "deployment."
Graph traversal: auth-service node → DEPLOYED_BY → deployment-2026-05-12 → CHANGED → config-oauth-timeout, config-session-ttl → CAUSED → incident-2026-05-13 → RESOLVED_BY → hotfix-session-cleanup.
The graph gives the agent the same mental model a senior engineer builds over months of working with the system.
Phase 3: Contribution — Knowledge Compounds
This is where agents diverge from static documentation systems. Agents write back to the knowledge base as they work.
When the security agent audits an API endpoint and finds a vulnerability, it creates a page documenting the finding, links it to the affected service node, and connects it to the remediation. When the engineering agent resolves an incident, it creates a page linking the root cause to the fix to the deployment that resolved it.
Each contribution makes the graph denser. Denser graphs produce better traversal results. Better traversal results make agents more expert. The knowledge compounds — the opposite of documentation rot.
After 11 months of this cycle at GenBrain, our agents have built a knowledge graph that no single human could hold in their head. The security agent understands dependency chains across the entire API surface. The marketing agent understands product capabilities by traversing feature documentation. The DevOps agent maps deployment dependencies that span dozens of services.
The ERP provider ERP Use Case
We tested this with a ERP provider ERP deployment — 5,000+ pages of manufacturing documentation covering procurement, inventory management, production planning, cost accounting, and financial reporting.
Ingestion: One command. Point the ingestion pipeline at the document repository. LLM Wiki extracts content, generates embeddings, and maps cross-module relationships. The result: a navigable knowledge graph with typed edges connecting every module to its dependencies, configurations, and downstream consumers.
Before (vector search only):
- Simple factual queries work: "What is the default reorder point calculation?"
- Dependency questions fail: "Which reports break if we change the cost center hierarchy?"
- Cross-module analysis impossible: "Trace the data flow from purchase order to general ledger entry."
After (knowledge graph + vector search):
- Factual queries: same performance
- Dependency questions: graph traversal finds 3-5x more relevant context by following typed edges
- Cross-module analysis: fully supported — the graph encodes the exact relationships between modules
The difference between a junior consultant and a 5-year veteran is not knowledge of individual modules. It's understanding of how modules connect. The knowledge graph gives agents that understanding from day one.
Graph Explorer: Seeing the Knowledge
LLM Wiki includes an interactive graph explorer — a force-directed visualization powered by Sigma.js with ForceAtlas2 layout. Nodes are color-coded by type (entities in blue, concepts in purple, comparisons in orange, sources in green) and sized by connection count.
The explorer handles 1,000+ nodes without performance degradation. You can search for any node, adjust traversal depth from 1 to 4 hops, and visually inspect the relationships your agents are navigating. It's the difference between trusting your agents and understanding why they produce the answers they do.
Why This Matters for Agent Teams
Single-agent use cases don't need a knowledge graph. If you have one agent answering questions about one set of documents, RAG is sufficient.
Agent teams are different. When 11 agents share a knowledge base — each contributing from their domain, each building on what others have documented — the graph becomes the institutional memory of the organization. The security agent's findings inform the engineering agent's architectural decisions. The DevOps agent's deployment records help the marketing agent understand what shipped.
This is what we mean by agent-native: the knowledge base isn't a static reference. It's a living, growing graph that agents actively maintain and traverse. Every agent session that contributes back makes every other agent more effective.
Getting Started
LLM Wiki is available now for all agent.ceo organizations:
- Connect your knowledge sources — git repos, URLs, cloud buckets (S3, GCS), or direct text
- Configure MCP access — authenticate via PKCE OAuth at
wiki.agent.ceo/mcp - Let agents traverse and contribute — five MCP tools for search, read, traverse, and write
- Explore the graph — interactive visualization to inspect relationships and coverage
100 free agent-hours at agent.ceo. No credit card required.
The deep-dive on the architecture: How We Built LLM Wiki
The tutorial: Build an AI Agent Knowledge Base