The Context Layer Race: Why Knowledge Graphs Are Becoming the Brain of Enterprise AI

June 2026 will be remembered as the month the knowledge graph went mainstream for AI. In the span of three weeks, four major vendors — AWS, Neo4j, Databricks, and Fluree — each launched products anchored on the same fundamental premise: AI agents cannot reason effectively without a graph-based context layer.

This is not coincidence. It is a market responding to a hard limit that early adopters hit in 2025: vector search finds similar fragments, but it cannot traverse the relationships that connect them.

The Pattern That Emerged

The announcements share a common architecture. Each product combines three retrieval signals into a single pipeline:

1. Lexical search — exact keyword and phrase matching via full-text indexes (BM25)
2. Semantic search — embedding-based similarity via vector indexes
3. Structural search — graph traversal that surfaces connected entities and their relationships

What distinguishes a knowledge graph context layer from a conventional RAG pipeline is the third signal. Pure vector RAG retrieves the top-k most similar chunks. A graph-backed retriever starts with those chunks, then traverses their relationships to collect structured context — products, risk factors, organisational hierarchies, compliance dependencies — that no embedding similarity score can infer.

Vendor Comparison

Dimension	AWS Context	Neo4j Doc Intelligence	FlureeDB	Databricks Genie
Launch date	17 June	1 June	23 June	Early June
Graph model	Auto-mapped	Property graph	Semantic (RDF)	Auto-extracted
Query language	Natural language + SQL	Cypher	SPARQL + GraphQL	Natural language
Vector search	✓	✓	✓	✓
Full-text search	✓	✓	✓	✓
IAM integration	Native (Cedar)	External	External	Unity Catalog
MCP server	✗	✗	Bundled	✗
Self-hosted option	✗	✓	✓	✗

Vendor Product Comparison

Neo4j's Document Intelligence, launched June 1, turns documents into a queryable knowledge graph without requiring graph modelling expertise. Drop in a PDF, describe what you want extracted in plain English, and the system builds a hybrid graph — a lexical layer for passage-level retrieval and provenance, plus an entity layer for structured questions. Both layers live in the same database and can be queried together in a single Cypher statement:

// Neo4j hybrid search: lexical + entity retrieval combined
CALL db.index.fulltext.queryNodes("passage_index", "supply chain vulnerability")
YIELD node AS passage, score AS lexicalScore
CALL {
  WITH passage
  MATCH (passage)-[:MENTIONS]->(e:Entity)
  OPTIONAL MATCH (e)-[:AFFECTS]->(product:Product)
  RETURN collect(DISTINCT product.name) AS affectedProducts
}
RETURN passage.text, passage.document, affectedProducts
ORDER BY lexicalScore DESC
LIMIT 5

This single query finds passages about the vulnerability (lexical search), identifies the entities mentioned, then traverses to affected products — a multi-hop reasoning chain that would require glue code and multiple API calls in a pure vector RAG architecture.

FlureeDB reached general availability on June 23. It is a semantic graph database (W3C RDF) that collapses what is typically a stack of five services — graph store, full-text and vector search, triple-level access policy, cryptographic signing, and a bundled MCP server — into a single binary. Every commit is immutably recorded so any prior state can be reconstructed on demand. Its bundled MCP server is particularly notable: any MCP-compatible agent framework can connect to FlureeDB without custom integration code.

The diversity of approaches is telling. The market has not yet converged on a single graph model — property graphs (Neo4j), RDF triples (Fluree), and inferred metadata graphs (AWS, Databricks) all coexist under the "context layer umbrella. What unites them is the architectural conviction that retrieval must combine lexical, semantic, and structural signals.

Hybrid Search in Practice: Cypher Code Example

Neo4j's neo4j-graphrag Python library (pip install neo4j-graphrag) provides production-tested components for this three-signal pattern. The HybridCypherRetriever combines full-text search, vector similarity, and graph traversal in a single retrieval operation:

from neo4j_graphrag.retrievers import HybridCypherRetriever
from neo4j import GraphDatabase
from neo4j_graphrag.embeddings import OpenAIEmbeddings

driver = GraphDatabase.driver("neo4j://localhost:7687", auth=("neo4j", "password"))
retriever = HybridCypherRetriever(
    driver=driver,
    embedding_property="embedding",
    fulltext_index="fulltext_chunks",
    vector_index="vector_chunks",
    retrieval_query="""
// Step 1: Start with the most relevant fragments from hybrid top-k
WITH node AS chunk, score AS hybridScore

// Step 2: Traverse relationships to gather structured context
OPTIONAL MATCH (chunk)-[:MENTIONS]->(entity:Entity)
OPTIONAL MATCH (entity)-[:RELATED_TO]->(related:Entity)
OPTIONAL MATCH (chunk)-[:FROM_DOCUMENT]->(doc:Document)

// Step 3: Collect all context into a single payload
RETURN
    chunk.text AS chunk_text,
    doc.title AS source_document,
    collect(DISTINCT {entity: entity.name,
                      relationship: type(chunk),
                      related_to: related.name}) AS graph_context,
    hybridScore AS relevance_score
ORDER BY hybridScore DESC
LIMIT 7
    """,
)

retrieval_result = retriever.search(
    query_text="What products are affected by the EU supplier vulnerability?",
    top_k=5,
)

print(retrieval_result)
# Output includes: chunk_text from BM25+vector fusion,
# graph_context with entity-relationship triples,
# and source_document provenance

The key design choice is the retrieval_query parameter, a Cypher template that runs after the initial hybrid retrieval. This is where graph traversal happens: starting from the top-k vector+lexical results, the query expands into entity relationships, collecting structured context the LLM would never infer from text alone. The HybridCypherRetriever handles Weighted Reciprocal Rank Fusion (WRRF) internally — merging the BM25 and vector score lists with configurable weights.

What This Query Returns That Pure Vector Cannot

A pure vector RAG pipeline fed with the question "What products are affected by the EU supplier vulnerability?" might return chunks mentioning "supplier", "vulnerability", and "EU region". It would not connect those facts because no single chunk contains all three concepts.

The graph-backed query finds chunks mentioning the vulnerability (via BM25), identifies the supplier entity linked to those chunks (via :MENTIONS), traverses to the supplier's products (via :SUPPLIES), filters by region (via node property region: "EU"), and returns the product list. All in one operation. The relationships are not probabilistic — they are edges in the graph.

At a Glance: The Four Launches

Product	Vendor	Launch Date	Core Differentiator	Retrieval Signals	Licensing
Document Intelligence	Neo4j	June 1	Zero-shot graph extraction from documents without schema design	Full-text, vector, graph traversal	Included with Enterprise / Cloud
AWS Context	Amazon	June 17	IAM-governed discovery across existing data estate with no data movement required	Semantic, graph-level reasoning	Managed service, pay-per-query
FlureeDB GA	Fluree	June 23	All-in-one binary: graph store, full-text and vector search, triple-level access policy, cryptographic signing, bundled MCP server	SPARQL, full-text, vector	Open-core (AGPL)
Genie Ontology	Databricks	Late June (preview)	Automatic business ontology from dashboards, queries, and lineage metadata	Semantic, provenance-weighted	Included with Databricks AI

Why Now: The Vector Ceiling

The underlying driver is well understood by anyone who has deployed RAG in production at scale. Vector search is remarkably good at finding text that means the same thing. It is remarkably bad at connecting entities that matter together.

Consider the following head-to-head comparison from production benchmarks:

Query Type	Vector RAG Accuracy	Graph-Backed RAG Accuracy	Delta
Single-hop factual lookup	86%	84%	-2% (noise)
Cross-document entity linking	54%	79%	+25%
Hierarchical query (org structure)	41%	88%	+47%
Supply chain multi-hop	38%	76%	+38%
Temporal event sequence	49%	71%	+22%
Compliance cross-reference	52%	83%	+31%

Source: Aggregated from GraphRAG-Bench (ICLR 2026), Agent.ceo production metrics, and neo4j-graphrag evaluation suite. Figures are on held-out enterprise QA datasets.

The pattern is clear: vector RAG holds its own on simple lookups, where graph traversal adds latency without retrieval benefit. The moment query complexity crosses into multi-hop, hierarchical, or cross-entity territory, the graph's advantage becomes decisive. A hybrid architecture that routes simple queries to vector-only and complex queries to graph-backed retrieval would capture the best of both worlds.

A query like "What products are affected by the supply chain vulnerability in our EU region supplier?" requires the retriever to:

1. Find documents mentioning the vulnerability (vector search)
2. Identify the affected supplier entity (entity resolution)
3. Traverse the supplier-to-product relationship in the graph (graph traversal)
4. Filter by the EU region attribute (metadata filtering)
5. Surface the connected product list (structural retrieval)

Without a graph, this becomes a multi-step orchestration problem that requires glue code, multiple API calls, and careful management of intermediate results. With a graph, it is a single query:

MATCH (s:Supplier {region: "EU"})-[:SUPPLIES]->(p:Product)
WHERE EXISTS {
  MATCH (v:Vulnerability)-[:AFFECTS]->(s)
  WHERE v.description CONTAINS "supply chain"
}
RETURN s.name AS supplier, collect(p.name) AS affectedProducts

Neo4j's hybrid search capabilities formalise this pattern. The database can combine lexical search via full-text indexes, semantic search via vector indexes, and structural search from graph-derived embeddings — all expressed in Cypher without external orchestration. Weighted Reciprocal Rank Fusion (WRRF) merges the ranked lists from each signal, boosting results that rank well in multiple sources.

The following Cypher query demonstrates a hybrid search combining all three signals in a single database call:

// Hybrid search: lexical + semantic + structural
CALL {
  CALL db.index.fulltext.queryNodes('entity_fts', 'supply chain vulnerability EU')
  YIELD node AS result, score
  RETURN result, score, 'lexical' AS source
  LIMIT 20
  UNION
  CALL db.index.vector.queryNodes('entity_embeddings', 20, $queryVector)
  YIELD node AS result, score
  RETURN result, score, 'semantic' AS source
  LIMIT 20
}
WITH result, score, source
OPTIONAL MATCH (result)-[:SUPPLIES|AFFECTS|LOCATED_IN]-(related)
WHERE related.region = 'EU'
WITH result,
     collect(DISTINCT {source: source, score: score}) AS signals,
     collect(DISTINCT related.name) AS connected_entities
ORDER BY reduce(wrrf = 0.0, s IN signals |
         wrrf + s.score / (2.0 * s.score + 1.0)) DESC
RETURN result.name AS entity,
       connected_entities
LIMIT 10

WRRF generalises reciprocal rank fusion by letting each signal carry a tunable weight. In practice, the semantic signal receives a higher weight for open-ended questions, while the lexical signal dominates when precise entity names are involved. The graph traversal acts as a structural multiplier — boosting results with rich connectivity and penalising isolated chunks even when their vector similarity score is high.

Production Realities

The practical experience of organisations running these systems at scale is clarifying. Agent.ceo, a company running an 11-agent Cyborgenic Organisation on Neo4j with 45,000 nodes and 120,000 relationships, reports the following performance characteristics:

Operation	Latency	95th Percentile
Single-hop node traversal	12 ms	18 ms
Three-hop relationship traversal	45 ms	72 ms
Full-text search (BM25)	8 ms	14 ms
Vector similarity search (1536-d)	25 ms	40 ms
Hybrid search (WRRF + graph expansion)	180 ms	290 ms
Daily ingestion (200 events)	4.2 s	6.8 s
Monthly infrastructure cost	$28	—
Graph size	45k nodes / 120k edges	—
Memory budget	4 GB (Community Edition)	—

These numbers matter because they answer the question every engineering leader asks: "Is this production-ready?" The answer, in mid-2026, is unequivocally yes. Neo4j v2026.02 made vector search with in-index filters generally available. The neo4j-graphrag Python library provides production-tested components for hybrid retrieval in agent frameworks. The performance characteristics are well documented at scale.

The monthly cost of $28 is particularly striking. A full production context layer — lexical, semantic, and graph retrieval — running on a Community Edition instance at a fraction of the cost of a dedicated vector database service. The graph database is not an expensive addition; it is the cheap foundation.

Hybrid Search in Practice: A Worked Example

The three-signal architecture — lexical, semantic, and structural — is not abstract. Here is how it translates to a single Neo4j query using the Cypher-based hybrid search pattern described in the neo4j-graphrag documentation.

Consider a customer support agent that needs to answer: "Which of our EU customers are affected by the log4j-style vulnerability in the Apache Commons Text library?"

// Step 1: Full-text search for the vulnerability advisory
CALL db.index.fulltext.queryNodes("advisory_index", "Apache Commons Text vulnerability") YIELD node AS advisory, score AS lexicalScore

// Step 2: Vector similarity search for semantically related documents
CALL db.index.vector.queryNodes(
  "chunk_embeddings",
  5,
  llm.embedding("Apache Commons Text remote code execution advisory")
) YIELD node AS chunk, score AS semanticScore

// Step 3: Graph traversal to connect advisory → library → products → customers
MATCH (advisory)-[:AFFECTS]->(lib:Library {name: "commons-text"})
MATCH (lib)<-[:DEPENDS_ON]-(prod:Product)
MATCH (prod)<-[:SUBSCRIPTION]-(cust:Customer)
WHERE cust.region = "EU"
RETURN DISTINCT
  advisory.cve AS CVE,
  lib.name AS Library,
  prod.name AS Product,
  cust.name AS Customer,
  cust.region AS Region,
  lexicalScore,
  semanticScore

The query combines all three signals in one round trip. Weighted Reciprocal Rank Fusion (WRRF) merges the lexical and semantic scores, while the graph traversal enforces structural relationships that neither search mode can infer. The result is a ranked, verified, and fully traceable answer set.

For Python-based agent frameworks, the HybridCypherRetriever from the neo4j-graphrag library wraps this pattern into a single callable:

from neo4j_graphrag.retrievers import HybridCypherRetriever

retriever = HybridCypherRetriever(
    driver=driver,
    vector_index="chunk_embeddings",
    fulltext_index="advisory_index",
    retrieval_query="""
        MATCH (node)-[:AFFECTS]->(lib:Library)
        MATCH (lib)<-[:DEPENDS_ON]-(prod:Product)
        MATCH (prod)<-[:SUBSCRIPTION]-(cust:Customer)
        WHERE cust.region = "EU"
        RETURN cust.name AS customer, prod.name AS product,
               lib.name AS library, node.cve AS cve
    """
)
result = retriever.search(
    query_text="Apache Commons Text remote code execution advisory",
    top_k=5
)

This is the production pattern used by the neo4j-graphrag library. Lexical search provides recall for exact terms, vector search captures semantic variants, and Cypher traversal enforces structural accuracy. No external orchestration, no multi-step glue code, no probabilistic guesses about which products depend on which libraries.

Hybrid Retrieval in Practice

The neo4j-graphrag Python library provides production-tested components that abstract multi-signal retrieval into a single retriever class. The following example configures a HybridCypherRetriever that combines vector search, full-text search, and graph expansion:

from neo4j import GraphDatabase
from neo4j_graphrag.retrievers import HybridCypherRetriever
from neo4j_graphrag.embeddings import OpenAIEmbeddings

driver = GraphDatabase.driver(
    "neo4j://localhost:7687",
    auth=("neo4j", os.environ["NEO4J_PASSWORD"])
)

retriever = HybridCypherRetriever(
    driver=driver,
    embedder=OpenAIEmbeddings(model="text-embedding-3-small"),
    fulltext_index="entity_fts",
    vector_index="entity_embeddings",
    retrieval_query="""
        WITH node AS chunk, score
        OPTIONAL MATCH (chunk)-[:REFERENCES]->(e:Entity)
        OPTIONAL MATCH (e)-[:RELATES_TO]->(related)
        RETURN chunk.text AS text,
               score,
               collect(DISTINCT {entity: e.name, related: related.name}) AS context,
               chunk.source AS source
        ORDER BY score DESC
        LIMIT 5
    """
)

result = retriever.search(
    query_text="What products are affected by the EU supply chain vulnerability?",
    top_k=5,
    weights={"vector": 0.5, "fulltext": 0.3}
)

For parameterised graph traversals, VectorCypherRetriever provides the same pattern with raw Cypher control:

from neo4j_graphrag.retrievers import VectorCypherRetriever

retriever = VectorCypherRetriever(
    driver=driver,
    embedder=OpenAIEmbeddings(model="text-embedding-3-small"),
    index_name="entity_embeddings",
    retrieval_query="""
        WITH node AS chunk, score
        OPTIONAL MATCH (chunk)-[:MENTIONS]->(e:Entity)
        WHERE e.confidence > 0.7
        WITH chunk, score, collect(e.name) AS entities
        OPTIONAL MATCH (e)-[:RELATED_TO]->(r:Entity)
        WHERE r.region = $query_params.region
        RETURN chunk.text AS text,
               score,
               entities + collect(r.name) AS full_context
        ORDER BY score DESC
        LIMIT 5
    """
)

result = retriever.search(
    query_text="Supply chain risk assessment",
    query_params={"region": "EU"},
    top_k=5
)

These patterns are in production use at organisations such as Agent.ceo, where the combination of HybridCypherRetriever with tuned WRRF weights and VectorCypherRetriever for parameterised expansions handles the full range of agent queries — from free-form semantic questions to structured multi-hop traversals — against a single Neo4j instance.

What This Means for Architects

The architectural implication is that the context layer is becoming a contested category. Every major data platform — AWS (Context), Databricks (Genie Ontology), Snowflake (Horizon Context), Microsoft (Fabric IQ), Redis (Redis Context), Pinecone (Nexus) — now has a graph- or ontology-based offering for AI agents. The differentiation is no longer about whether to use a graph, but whose graph infrastructure integrates most seamlessly with your existing data estate.

For teams building on open-source infrastructure, the path is clear: Neo4j Community Edition with its vector index, full-text index, and Cypher-based hybrid search provides a production-grade context layer at minimal cost. The HybridCypherRetriever and VectorCypherRetriever patterns from neo4j-graphrag give you graph-enriched retrieval out of the box. Your agent queries a single database that handles lexical, semantic, and structural search together, without any external orchestration:

from neo4j_graphrag.retrievers import HybridCypherRetriever

retriever = HybridCypherRetriever(
    driver=driver,
    fulltext_index="passage_index",
    vector_index="passage_embeddings",
    retrieval_query="""
        MATCH (passage)-[:MENTIONS]->(e:Entity)
        OPTIONAL MATCH (e)-[:RELATES_TO]->(related)
        RETURN passage.text, collect(DISTINCT e.name) AS entities,
               collect(DISTINCT related.name) AS related
    """
)
results = retriever.search(query_text="supply chain vulnerability")

The integration surface is widening rapidly. Neo4j recently released providers for the Microsoft Agent Framework, giving MAF-native agents access to connected context and persistent memory through graph traversal. The same pattern — a retriever that finds relevant chunks via vector similarity, then expands through relationships — is applicable whether your agent framework is MAF, LangChain, CrewAI, or a custom implementation.

Architectural Decision Guide

Scenario	Recommended Approach	Rationale
Simple FAQ bot (single-hop)	Vector-only RAG	Graph adds cost without benefit
Enterprise knowledge base	HybridCypherRetriever	Multi-hop queries are common
Compliance/audit assistant	RDF triple store (Fluree)	Immutability + provenance
AWS-native data estate	AWS Context	No data movement, IAM-native
Cross-platform agent framework	Neo4j + neo4j-graphrag	Framework-agnostic, cheapest
High-throughput real-time	VectorCypherRetriever (no full-text)	Fastest graph-backed path

The Trajectory

The rate of change in this space is accelerating. Neo4j shipped vector search with filters, native Cypher syntax for vector search, and Document Intelligence all within six months. FlureeDB went from preview to GA with an embedded MCP server. AWS Context launched as a fully managed service that learns from agent usage patterns without manual re-curation.

The direction of travel is unmistakable: the database that stores your data will also store the relationships between it, and AI agents will query both simultaneously as a single operation. Vector search becomes one signal among several, not the entire retrieval pipeline. The graph is not an enhancement to RAG. It is becoming RAG's foundation.

For practitioners, the takeaway is practical: if your production RAG pipeline today only does vector search, start planning your hybrid search architecture. The infrastructure is mature, the tooling is production-ready, and your competitors who treat graph traversal as a first-class retrieval signal will answer questions your system cannot even understand.

See Also

• GraphRAG Reality Check — When graph-based retrieval underperforms vanilla RAG and how to fix it
• Introduction to GraphRAG — Foundations of graph-augmented retrieval for large language models
• Knowledge Graphs Are the Antidote to AI Hallucination Liability — How the Munich liability ruling makes graph grounding a legal requirement
• Graph-Powered OSINT — Knowledge graphs applied to intelligence analysis with Neo4j GDS algorithms
• Neo4j Database Adapters Compared — Driver selection across Python, JavaScript, Java, Go, .NET, Rust, and PHP