Context Is the Missing Layer in Enterprise AI.

Most enterprise AI projects don't fail for lack of data. They fail because the data they pull from carries no context. A vector store can retrieve text chunks that look statistically similar to a question. It cannot tell you that the chunks describe the same vendor, or different products from the same vendor, or the same product under two different brand names after an acquisition. The retrieval was correct. The conclusion was wrong.

File-based and API-based data exchange moves data. It does not move knowledge.

Section 1: The diagnosis Gartner is naming

Gartner's June 2025 press release on agentic AI[3] predicts over 40% of agentic AI projects will be cancelled by end of 2027. The cited drivers are escalating costs, unclear value, and inadequate risk controls. The first two are downstream of the third · agentic AI fails reliably when the retrieval substrate underneath it can't produce evidence the buyer can audit.

The Microsoft Research GraphRAG paper[2] documents the architectural fix in a different vocabulary: graph-based retrieval delivers “substantial improvements over a conventional RAG baseline for both the comprehensiveness and diversity of generated answers” on global sensemaking questions at the 1M-token-corpus scale. The mechanism: instead of ranking text chunks by cosine similarity, the system first builds a graph of the nodes in the documents, summarises each group of closely related nodes, and assembles the answer from those summaries.

Section 2: What “context” means as a layer

Context is not a synonym for “more data.” It's a specific shape: typed nodes + named relationships + governance rules. The semantic web standards (RDF, SPARQL, SKOS, OWL, SHACL) have offered this shape for two decades. Two things changed recently:

• LLMs can author the graph. Tools that previously required taxonomists can now bootstrap a domain model from existing data, with humans in the loop for governance decisions.
• LLMs can query the graph. Natural-language questions translate to SPARQL (or graph-DB equivalents) and return cited nodes · not summaries of documents that might mention them.

The combination is what makes graph-grounded retrieval (“Graph RAG”) different from vector retrieval. Graph RAG is what document-grounded RAG should have been from the start · it just couldn't exist until the model layer could author and query the substrate at production cost.

Section 3: Three taxonomies already prove the pattern at scale

Skeptics will ask: does this actually work in production? The answer is yes, and it has been working in production for decades in domains that hold their AI systems to a higher accuracy bar than software companies typically do:

• MeSH · Medical Subject Headings.[4] The controlled vocabulary the US National Library of Medicine has used since 1960 to index PubMed/MEDLINE. PubMed searches, clinical literature reviews, and meta-analysis tooling lean on it: more than 40 million citations indexed against a typed vocabulary of about 30,000 headings.
• EuroVoc.[5] The European Union's multilingual thesaurus across 24 official EU languages. It indexes the legislative and policy corpus of the EU. Because every term exists in every official language, a German regulator and a Portuguese citizen can search the same body of law by the same subjects, each in their own language.
• SNOMED CT.[6] Systematized Nomenclature of Medicine · Clinical Terms. 350,000+ active concepts used in clinical decision support across 80+ countries. When a hospital information system in Brazil and one in Singapore share patient data, SNOMED CT is what makes the records interoperable · not just transferable.

Each of these is a typed graph with a governance body, a versioning discipline, and a fielded query interface. None of them is a vector store. None of them is fashionable, and all of them have run reliably for decades.

The pattern that runs PubMed, EU legislation, and clinical decision support has been waiting twenty years for agentic AI to catch up.

Section 4: What this means for software product data

The software market has no public typed graph of its own. There is no MeSH for SaaS. There is no PubMed Terminal for the question “which CSPM vendors have FedRAMP authorization, ship Salesforce integration, and are mentioned in the last 90 days of analyst coverage in a specific tone.” That question is a four-hop traversal. Vector retrieval can't do it. The 99 universal node types in the PYRAMYD graph were built specifically to make this class of question first-class.

Where the graph layer changes the answer shape

• Retrieval unit · vendor, product, capability, role, country · not text chunks
• Update model · FK constraint propagation · not full re-embedding
• Citation granularity · per record and per field, with source URL and retrieval date · not document-level
• Failure mode · “no path found” instead of hallucinating the join
• Audit surface · recorded provenance on every enriched field (sources, dates, model, and a quality score) · not just a conversation log

Section 5: The regulatory pull just made this urgent

EU AI Act Article 50[7] applies from August 2, 2026. Its marking duty, machine-readable labels on AI-generated content, is the one procurement teams ask about most, and buyers are now asking for per-claim provenance alongside it. Both are mechanically difficult for document-grounded RAG and structurally easy for graph grounding. We covered the procurement-side framing on the Article 50 Ready page.

Article 50's technical requirements weren't designed for any specific architecture. But the natural way to satisfy them is to have a typed substrate that already knows what each cell is, where it came from, and which model authored or transformed it. That's the same shape as a knowledge graph. Regulation is now pulling enterprise AI architectures toward the pattern that biomedical and legal knowledge graphs have run on for two decades.

Section 6: The role that emerges · knowledge steward

The original Graphwise piece names a role that's emerging in the same arc: the knowledge steward. Not a data engineer (who owns the pipes), not a taxonomist (who owns the model in isolation), but a domain expert who decides what goes into the graph, what stays out, what counts as the canonical form of a node, and what governance applies. LLMs let knowledge stewards focus on judgment instead of manual model authoring.

Inside an organization using PYRAMYD, this role can start as a Product Marketing or Product Operations lead who realizes the graph is the new substrate for every team's questions. The job description shifts from “maintain a battlecard library” to “govern the substrate that every team queries.” That's a strictly more leveraged seat than the one it replaces.

Section 7: What we built (and what you can use)

PYRAMYD runs on the Product Graph, our software-specific implementation of this pattern. 99 universal node types, 250K+ products, 2,546 categories, 2.4M+ reviews, 2,000+ catalogued signal sources, 403 of them with a refresh schedule (all counted on 8 Oct 2026). APEX is the agentic layer on top: it answers from that typed graph and lists the records it used, with a link back to each original source where one exists, so you can check any claim yourself.

For organizations already building on Graphwise (enterprise documents) or Neo4j / Stardog (general-purpose graphs), PYRAMYD complements rather than competes: it connects your product to the market, competitors, customers, and deals around it, and puts agents to work on that evidence, inside the architecture you're already adopting. Claude Desktop, Cursor, Zed, ChatGPT, and Microsoft 365 Copilot can already connect with a personal access token to ask about competitors, signals, and battlecards; access to the rest of the graph from those tools is on the way.

Section 8: Reading list

The four sources we'd hand to a procurement team or an architecture review board on this topic:

• The original Graphwise / CDO Matters piece this post extends[1] · the most accessible framing of the “context as a layer” thesis
• The Microsoft Research GraphRAG paper[2] · the canonical academic reference for the architectural difference
• The Gartner agentic AI press release[3] · the market-shift framing procurement teams will already be planning around
• The EU AI Act Article 50 official text[7] · the transparency rules for AI systems used in the EU

We won't pretend we invented this pattern. We didn't. We built the software-market version of a knowledge-graph architecture that biomedicine, EU legislation, and clinical decision support have run on for decades. The fact that agentic AI now needs the same substrate is the thing that's new.