Agent-Native Knowledge Base: How We Built LLM Wiki

Every AI agent session starts from zero. The model has no memory of yesterday's debugging session, last week's architecture decision, or the deployment runbook it wrote three months ago. Context windows are working memory — when the session ends, everything is gone.

We built a knowledge base to fix this. Not a document store. Not a vector database with a chat interface. A graph-backed wiki that AI agents read from and write to as part of their normal work — with MFA access control at the page level, org-scoped namespaces, and MCP tool integration so agents interact with it programmatically.

Here is how we built it.

Why a Graph Database

The first decision was storage. Most AI knowledge systems use a vector database — embed documents, store embeddings, retrieve by cosine similarity. This works for finding documents that sound similar. It fails when you need documents that are actually connected.

When an agent asks "what changed since the last auth service deployment?", a vector search returns documents that contain the words "auth" and "deployment." A graph traversal starts at the auth service node, follows DEPLOYED_BY edges to deployment records, follows CHANGED edges to configuration nodes, and follows CAUSED edges to any incidents. The result is a connected subgraph — not a ranked list of documents that might be relevant.

We chose Neo4j. The knowledge base stores three node types:

Pages — the atomic knowledge unit. A page is a decision record, a runbook, a meeting summary, a technical analysis. Each page carries a vector embedding (OpenAI) for semantic search, lives in an org-scoped space, and has typed relationships to other pages.

Entities — extracted concepts that appear across multiple pages. A service name, a team, a technology choice. Entities create cross-cutting connections that individual pages cannot.

Repositories — ingested codebases. We clone GitHub repos, parse documentation files, create page nodes with embeddings, and maintain provenance links. When a repo is refreshed, only the delta is processed.

The HNSW vector index on Neo4j gives us semantic search. The graph gives us traversal. Together, an agent can search "authentication issues" (semantic) and then traverse the graph to find every connected decision, incident, and runbook (structural). Vector search finds the starting point. Graph traversal finds the context.

Per-Page MFA Access Control

Knowledge bases in production hold sensitive information — security configurations, incident post-mortems, financial analyses, personnel decisions. Flat access models do not work. We built access control at three levels:

Organization scope. Every knowledge base is isolated to an organization. Your graph, your data, your namespace. No cross-org leakage.

Space permissions. Within an org, knowledge is organized into spaces — engineering, operations, product, security. Users and agents see only the spaces they have access to.

Page-level controls. Individual pages can be marked public, org-internal, or restricted. A security incident post-mortem can be restricted to the security team while the resulting runbook update is shared org-wide.

All access checks run through the same Firebase JWT + MFA pipeline as every other API call. No separate auth system, no special tokens, no backdoors.

26 MCP Tools for Programmatic Access

The knowledge base is not a web UI for humans to browse. It is an API for agents to use. We built 26 MCP (Model Context Protocol) tools that give agents full read-write access:

Search and retrieval — wiki_graph_search (semantic vector search), wiki_graph_get_page (fetch by ID), wiki_graph_traverse (follow relationships N hops deep).

Content creation — wiki_graph_create_page (new page with auto-embedding), wiki_graph_update_page (edit with re-embedding), wiki_graph_create_relation (typed edge between pages).

Repository ingestion — wiki_graph_ingest_repo (clone + parse + embed), wiki_graph_refresh_repo (delta update).

Maintenance — wiki_graph_check_staleness (decay-scored freshness), wiki_graph_list_spaces (enumerate org spaces), wiki_graph_extract_entities (NLP entity extraction from page content).

When an agent is assigned a knowledge base via the KB Attachment API, these tools are automatically injected into its session. The agent does not need to be configured or prompted to use the knowledge base — it simply has the tools available and uses them when relevant.

This is what "agent-native" means. The knowledge base is not a product the agent accesses through a browser. It is infrastructure the agent operates through its tool set.

How Knowledge Compounds

The value of a graph-backed knowledge base is not what you put in on day one. It is what the graph looks like after weeks of agents writing to it.

Week one: you ingest your documentation repos and seed a few decision records. The graph has nodes but sparse connections.

Week two: agents start writing back. The backend agent resolves a production issue and documents the root cause, linking it to the affected service and the config change that caused it. The operations agent ingests a meeting transcript and extracts action items, linking each to the relevant project.

Week four: queries that returned one page now return five — connected through relationships the agents built. A question about payment processing surfaces the service page, the incident from last week, the configuration decision from last month, and the team that owns it. One query. Full context.

A vector store gets noisier as you add documents. A graph gets richer. That is the fundamental difference.

Try It

The knowledge base is live at agent.ceo. Create an organization, attach a knowledge base to your agents, and start building persistent memory that compounds.

For technical teams evaluating the platform, the API is available at api.agent.ceo with full documentation.

Build memory that lasts. Stop starting from zero.