Knowledge Graphs

A knowledge graph in this catalog is a durable store of nodes, edges, and properties that answers relationship questions: who depends on whom, which case owns which commitment, what path connects a delay to a capital consequence. The query language is usually Cypher / openCypher (or SQL+Cypher hybrids). That is a different contract from Vector DBs, which optimize for similarity in embedding space. Graphs and vectors often sit side by side under Infrastructure: vectors retrieve “looks like”; graphs retrieve “connected to.”

Mechanically the cell cares about adjacency representation, transactional writes of edges, index support for labels/properties, and latency on multi-hop traversals. GraphRAG patterns use the graph as structured context for an LLM — still not a replacement for RAG’s corpus pipeline, and not the same as Memory’s cross-session fact store (though memory products may project into a graph). In a company OS the graph is often the honest home for authority chains, checklist structure that must not collapse, and schedule edges whose slip has financing cost — things a vector neighbor list cannot name.

Operational checks before adopting a pack: Can you assert invariants on edge types (no orphan commitments)? Can agents read a bounded subgraph without dumping the whole database into a prompt? Do backups and ACLs match how the rest of the ledger is governed? If the answer is “we will just embed everything,” you are still in Vector DBs territory.

Three packs currently define the cut:

• Neo4j is the mature property-graph default: Cypher, drivers, Graph Data Science, and GraphRAG tooling. Prefer it when operators need a dedicated graph platform and ecosystem depth.
• Apache AGE keeps graph query inside PostgreSQL (openCypher on Postgres). Prefer it when the company ledger already lives in Postgres and a second graph cluster would be a second system of record.
• FalkorDB targets sparse-adjacency performance for AI / knowledge-graph workloads with OpenCypher — useful when low-latency neighborhood queries for agents are the bottleneck and a thinner Redis-adjacent footprint fits.

When choosing for an agentic OS, ask whether relationships are first-class truth (schedule dependencies, org authority, BOM) or whether cosine neighbors would fake structure. Prefer Apache AGE when relational locality wins; Neo4j when graph ops and ecosystem matter; FalkorDB when sparse-graph latency for LLM context is the measured gap. Do not put causal company structure only in a vector index and hope ANN reconstructs it.

Navigate out deliberately: Vector DBs for embedding ANN; RAG when the job is document grounding; Memory when the job is long-lived episodes and profiles. Stay here when typed traversal is the missing substrate. Feature maps already point at company-model concerns such as Persistent company model ≠ agent memory and 01-company-model-memory-os — the graph is how those features become queryable structure.