Agent-Native Knowledge Base — LLM Wiki on Agent.ceo
Andrej Karpathy described the LLM Wiki pattern: a knowledge base that LLMs don't just read — they write to, organize, and build over time. The wiki becomes the persistent memory that models lack natively.
Agent.ceo implements this pattern for AI agent teams. Not a chatbot with retrieval-augmented generation. A Neo4j knowledge graph with typed relationships that agents query, traverse, and contribute to through MCP tools. The result is organizational memory that compounds across every agent session.
The Problem: Agent Amnesia
Every AI agent session starts cold. The agent has no memory of what happened yesterday — no context from prior investigations, no awareness of what other agents discovered, no institutional knowledge. It re-derives everything from scratch.
The standard fix is RAG: embed documents into vectors, retrieve by cosine similarity at query time. This works for simple factual lookups. It fails when the answer requires understanding relationships between entities — which modules depend on which, what changed after a deployment, how configs cascade through interconnected systems.
The gap isn't retrieval. It's structure. RAG gives agents a reading list. A knowledge graph gives them understanding.
How It Works
Agent.ceo's knowledge base — LLM Wiki — has three layers:
1. Neo4j Knowledge Graph
Every piece of organizational knowledge is a node. Relationships between nodes are typed: DEPENDS_ON, CONFIGURED_BY, FEEDS_INTO, TRIGGERS, SUPERSEDES. When an agent needs to understand impact, it traverses edges — not keyword matches.
An HNSW vector index runs alongside the graph. Agents find starting points via semantic search, then follow structural relationships to build complete understanding.
2. MCP Tools (26 total)
Agents interact with the knowledge base through Model Context Protocol tools:
wiki_graph_vector_search— semantic search for discoverywiki_get_page— read a specific page by pathwiki_graph_neighbors— traverse typed edges from any nodewiki_ingest_text— create or update pages from textwiki_ingest_url— import and structure content from URLs
These are the core five. The full set of 26 includes tools for content scoring, relationship management, bulk ingestion from git repos and cloud storage, and freshness tracking.
The key design decision: agents don't just consume the knowledge base. They contribute to it. When the security agent finds a vulnerability, it creates a page and links it to affected services. When the engineering agent resolves an incident, it documents root cause and connects it to the fix. Knowledge compounds with every session.
3. PKCE OAuth Authentication
Every MCP tool call is authenticated. External tools like Claude Code connect via PKCE OAuth 2.0 — no API keys, no shared secrets. Per-agent identity scoping ensures the security agent reads security-relevant pages and the marketing agent reads marketing-relevant pages. MFA on every API call, not just login.
ERP provider: 365 Entities, 2,820 Nodes
We validated the architecture with our first design partner. ERP provider is an enterprise ERP system used in manufacturing — hundreds of interconnected modules where changes in one area cascade through the entire system.
We ingested 5,000+ pages of ERP provider ERP documentation into a single knowledge graph: 365 entity types, 2,820 nodes with typed relationships mapping every module dependency.
The results:
| Query Type | Vector Search | Graph Traversal |
|---|---|---|
| Simple factual ("What is entity X?") | Works well | Same result |
| Dependency ("What depends on X?") | Partial — misses indirect deps | 3-5x more context |
| Cross-module impact ("What breaks if we change X?") | Cannot follow typed edges | Full cascade chain |
The dependency and impact questions are where expertise lives. A junior ERP consultant takes days on these. A senior consultant takes hours. An agent with graph access takes seconds.
For VC/PE firms managing manufacturing portfolios, this compresses the expertise gap in due diligence, configuration audits, and integration planning.
Why Graph, Not Just Vectors
Vector search answers "what is similar to this?" Graph traversal answers "what is connected to this, and how?"
Similarity is useful for discovery. Structure is necessary for reasoning. When an agent needs to determine the impact of changing an inventory valuation method, it needs to follow the dependency chain through production planning, cost accounting, and the general ledger. That chain exists in the graph as typed edges. It doesn't exist in a vector space.
The combination — vector for discovery, graph for reasoning — is what makes agents into domain experts rather than document retrievers.
Try It
The knowledge base is live at kb.agent.ceo/mcp. Connect any MCP-capable tool via PKCE OAuth. 100 free agent-hours, no credit card: agent.ceo.