Build with AI
Knowledge management as a graph
The question is never just 'find the document.' It's who wrote it, what system it describes, which decision superseded it, and who depends on it now — and those are edges, not fields.
The model
The shape of the problem
Documents mention entities. People author documents and own systems. Decisions reference documents and affect systems. Model each as nodes and the joins you'd otherwise do across four tools become one traversal — search lands on a node, and everything around it is one hop away.
Search that lands in context
Full-text BM25 search runs inside the database, so a keyword query returns nodes you can traverse from immediately: from the matching document to its author, its topics, the systems it describes — one round trip, not a search service plus N lookups.
Answer lineage questions
Which documents are downstream of a deprecated decision? Who owns anything that references this API? These are variable-length traversals — the questions that make wikis give up are the ones graphs are for.
Feed agents the same graph
The MCP server exposes the schema and Cypher to Claude, Cursor and any MCP client, so an assistant answering 'what do we know about X' walks the same graph your people query — with citations, because every fact is a node with provenance.
CALL db.index.fulltext.queryNodes('docs', $q)
YIELD node AS doc, score
MATCH (doc)<-[:AUTHORED]-(person:Person)
OPTIONAL MATCH (doc)-[:DESCRIBES]->(sys:System)
RETURN doc.title, person.name,
collect(DISTINCT sys.name) AS systems, score
ORDER BY score DESC LIMIT 10Questions
Knowledge management, asked directly.
How is this different from a wiki with search?
Search finds a page. The graph knows what the page is connected to — author, system, superseding decision, dependents. The second half is what answers real questions, and it's what wikis don't model.
Do I need to classify everything up front?
No. Start with what's cheap — documents, authors, mention edges from your existing metadata — and add relationship types as questions demand them. Graphs tolerate incremental schemas well.
Can AI assistants use it?
Directly, over MCP. The assistant reads the schema, writes Cypher, and cites the nodes it used. No retrieval pipeline to build first.
Where do the documents live?
Wherever they already do. The graph stores nodes, relationships and enough text to search on — it points at your systems of record rather than replacing them.
How does full-text search rank results?
BM25, maintained on every write, on the fields you index. Search results arrive as (node, score), so ranking and traversal compose in one query.
How do we keep it current?
Load continuously from the sources — object storage, warehouses, Kafka — with MERGE so re-ingestion is idempotent. The graph is as fresh as its feeds.
Related solutions
Manage risk
Fraud detection
Fraud hides in relationships — shared cards, devices and addresses. Model transactions as a graph and expose rings that row-based queries can't reach.
Read moreIncrease revenue
Recommendations
People who bought this also bought — computed live from the purchase graph, not from a nightly batch. Collaborative filtering as a two-hop Cypher traversal.
Read moreManage risk
Identity resolution
The same person exists three times across your systems. Model records and their attributes as a graph and merge duplicates by walking what they share.
Read moreStart now
~98.7%
token efficiency at 2,000 entities — see the footnotes above
Put your first graph up in a minute.
A free instance takes about a minute and no card. Write two MERGE statements, read them back, and you have a living graph — with provenance on every fact.
First-graph path
LiveCreate a free instance
No card. Ready in about a minute.
Connect your driver
bolt+ssc:// URI into the driver you already use.
Write two MERGEs
That's the entire shape of agent memory.
Point an agent at it
One MCP config block. No integration code.