Every AI agent starts the same way: smart, fast, and completely ignorant of your domain.
You can prompt-engineer your way around this — stuff context into system prompts, paste in documentation, hope the agent doesn't hallucinate the parts you forgot to include. It works, up to a point. Then you hit the context window. Or the agent hallucinates a schema field that doesn't exist. Or you need to update the knowledge and realize it's scattered across a dozen system prompts.
We built something different. We call it KB — the Knowledge Base — and it's the component that turns a generic agent into a domain expert.
What KB Actually Is
KB is a knowledge graph backed by Neo4j, exposed as an MCP server at kb.agent.ceo/mcp.
Rendering diagram…
The agent doesn't read files. It doesn't get a blob of text in its context. It queries the knowledge graph through structured MCP tools — the same way a developer queries a database.
The 26 Tools
When you connect kb.agent.ceo/mcp to an agent, it gets 26 tools. The important ones:
wiki_graph_vector_search(query)— semantic search across all ingested knowledge. Returns relevant pages ranked by embedding similarity.wiki_get_page(path)— read a specific knowledge page with full content and graph relations.wiki_graph_neighbors(path)— traverse the knowledge graph. Given an entity, return everything connected to it.wiki_list(wiki)— browse all pages in a knowledge namespace.kb_ingest_source(source_id, org_id)— ingest a new source (S3 bucket, git repo) into the knowledge graph.
The agent decides when to use these tools and what to search for. It's not retrieval-augmented generation in the classic sense — there's no pre-retrieval step stuffing chunks into context. The agent queries on demand, follows graph edges when it needs to explore, and builds its understanding dynamically.
The ERP Provider Case: Domain Know-How at Query Time
Our first production use of KB is with an ERP provider, a design partner building on top of the OFBiz ERP system.
OFBiz is a massive open-source ERP with hundreds of XML schema files defining entities, relationships, and business logic. No agent knows this schema by default. No LLM has memorized the difference between ProductStore, ProductStoreGroup, and ProductStoreGroupMember — or the 362 other entity types in a typical OFBiz deployment.
We ingested the OFBiz XML schema into KB:
365 entity types
2,820 nodes in Neo4j
3,629 relationships
Now the ERP provider's agent can do this:
User: "Show me all entities related to product pricing"
Agent: [calls wiki_graph_vector_search("product pricing")]
→ Returns: ProductPrice, ProductPriceRule, ProductPriceCond, ProductPromo...
Agent: [calls wiki_graph_neighbors("ProductPrice")]
→ Returns: connected entities, their fields, relationships to order items...
Agent: "The ProductPrice entity stores base prices with currency and
price type. It connects to ProductPriceCond for conditional
pricing rules and to OrderItem for applied prices..."
No hallucination. No guessing. The agent is reading from a graph that was built from the actual schema files.
Two Source Types
KB supports two ingestion modes, configured per organization:
type: kb — Knowledge ingested into Neo4j. The agent queries it via MCP tools. Best for structured domain knowledge: schemas, API docs, process documents, architectural decisions.
type: context — Files synced to /home/appuser/context/<name>/ at pod startup. The agent reads them directly from disk. Best for raw files the agent needs verbatim: XML schemas it needs to parse, CSV data, reference documents.
type: both — Does both. The agent gets the graph query interface and direct file access.
For the ERP provider: the ERP schema goes into KB (type: kb) for semantic search, and the raw XML files sync to /home/appuser/context/erp-schema/ for cases where the agent needs to read the actual XML.
How to Wire KB Into Your Agent
KB ships as an MCP server. To connect it, add this to your agent's settings.json:
{
"mcpServers": {
"wiki-kb": {
"type": "sse",
"url": "https://kb.agent.ceo/mcp",
"headers": {
"Authorization": "Bearer YOUR_ORG_API_TOKEN"
}
}
}
}
Get your org API token from the agent.ceo dashboard under Settings → API Tokens.
Once connected, the agent has all 26 KB tools available. It will automatically use them when it needs domain knowledge — you don't need to prompt it to use them explicitly.
What This Changes
The standard pattern for giving agents domain knowledge is: put it in the system prompt. This breaks at scale. System prompts bloat. Knowledge goes stale. You can't update one agent's knowledge without updating all of them.
KB separates knowledge from agents. The knowledge graph lives in one place. Any agent — in any organization, with any role — can query it. When the ERP schema changes, you re-ingest. Every agent that queries KB gets the update automatically.
This is how domain expertise should work in a multi-agent organization: stored once, queried on demand, versioned and auditable.
KB is live at kb.agent.ceo/mcp. If you're building agents that need to operate in a specific domain — ERP, legal, financial, scientific — reach out. We're onboarding design partners now.