What Each Article Actually Argues🔗
The Enterprise Knowledge Layer
Argues that enterprise AI fails when agents each rebuild "meaning" privately, causing semantic duplication and drift. Proposes the EKL: a governed substrate of ontology (technical, domain, process, policy, organization layers), enterprise data (queried in place via the Ontology-Based Semantic Layer, or materialized in the full EKL), and memory (decision traces that compound over time). Concludes: "Intelligence is a commodity. Knowledge is the moat."
How agent-rdf-memory Aligns With the Agent Engineering Stack
Maps Brij Kishore Pandey's 11-layer Agent Engineering Stack (Model, Context, Memory, Tools, Skills, Orchestration, Identity, Policy & Guardrails, Observability, Evaluation, Runtime) onto the concrete files of the agent-rdf-memory repository, scoring 7 layers Fully Implemented, 3 Partially Covered, and 1 (Model) Out of Scope — with every GitHub link verified against the live repository tree before publication.
11 Dimensions, Side by Side🔗
Each dimension is drawn only from what the two source articles actually state, not inferred capability.
Enterprise AI fails when meaning is duplicated across agent prompts and MCP servers. Fix: lighter agents over a smarter shared substrate — "organizational knowledge as queryable as data and as actionable as code."
A coding agent behaves inconsistently across sessions and models unless its own operating knowledge — identity, preferences, prior sessions — is written down once as SPARQL queryable or filesystem searchable RDF. In essence, agent-rdf-memory is simply an RDF-based harness informed by ontologies (homegrown and/or shared), held in loosely-coupled form and built entirely on open standards.
Property graph (Neo4j): labeled nodes and relationships with key-value properties, queried in Cypher.
RDF triples using a variety of notations and syntaxes (Turtle, JSON-LD, RDF/XML, N-Triples, etc.): subject-predicate-object statements using W3C standards (RDF, RDFS, OWL, SKOS) and schema.org vocabulary, queried in SPARQL.
Hybrid: LLM-assisted bottom-up discovery from schemas, query logs, and glossaries, reconciled top-down by human ratification; names industry standards (FIBO, SNOMED) as optional alignment examples customers often reach for, not ontologies the platform itself formally imports.
Ontology-driven throughout, not merely rule-driven: ontology.ttl formally imports shared ontologies (OPAL, PROV-O, the Event Ontology) alongside homegrown classes, and a typed entities/ registry gives every entity a canonical type for deterministic resolution and reconciliation. preferences.ttl separately grows the behavioral-rule layer incrementally, one HowToStep at a time, from user corrections.
Decision-trace memory: every EKL interaction leaves a trace of which of several valid paths worked, so "the ontology holds what's possible; memory holds what's proven," and the next run starts further along.
Three explicit tiers: episodic memory in dated sessions/ files, semantic memory in entities/, and long-term behavioral memory in preferences.ttl — governed by its own session-governance sub-HowTo.
A dedicated policy ontology and organization ontology, federated like data mesh: domain teams own their own definitions, a platform team owns the shared substrate, and access rules are enforced computationally at query time.
preferences.ttl is itself the policy layer, manifesting a Knowledge Graph deployed using Linked Data principles (i.e., a Semantic Web): 140+ HowToSteps, many implemented as hard blocking gates that fail closed, with a public/private file split (preferences.private.ttl, gitignored) enforcing the data boundary.
Agents query the EKL continuously at request time — never cache or carry a static copy, since the layer is both larger than any context window and constantly changing.
SPARQL-routed context selection over a Virtuoso endpoint: prompt-intent classification picks a relevance budget, not a full dump, following a mandatory 9-step session-start retrieval protocol with a graceful file-read fallback.
Not separately modeled beyond the organization ontology's roles, responsibilities, and ownership — no cryptographic agent- or user-identity mechanism is described in the article.
core.ttl carries both agent and user identity as first-class RDF resources; a verified-identity sub-HowTo runs openssl certificate-modulus checks against WebID-linked credential bundles for whoami-class requests.
Modular: the Ontology-Based Semantic Layer (OBSL) keeps master/transactional data external and queried in place; the full EKL can additionally materialize frequently-needed slices as domain data products inside the layer.
Fully materialized: every session, preference, and entity is written as an RDF document that provides operational context — there is no external-data mode, since the agent's harness, via preferences.ttl, is what is being modeled.
You engineer the EKL on top of a commercial graph platform (Neo4j): the vendor sells the substrate and reusable methodology, but the enterprise's own meaning is always bespoke, populated by its own team.
As showcased by the public git repository of plain-text RDF-Turtle and Markdown files, model-agnostic by design: any LLM or agent harness (Claude, GPT, DeepSeek, GLM, Grok) can read and extend the same contract without a hosted service.
Enterprise-wide: customers, subscriptions, compliance processes, org structure — knowledge about the business the agent acts on behalf of.
Agent-scoped by default — the agent's own behavioral contract, session history, and skill library — but not limited to it: business-domain entities are equally modelable, with entity types drawn from homegrown and/or shared ontologies giving the system deterministic entity resolution and reconciliation. The same objective the EKL pursues from the enterprise inward, agent-rdf-memory pursues from the agent's own operating substrate outward.
Enterprise meaning stays inside a governed graph substrate the enterprise itself operates; agents query it at request time instead of having business definitions, policy, and process knowledge baked as static context into every prompt sent to a frontier model. This keeps sensitive institutional knowledge from leaking outward — though the substrate is still coupled to the Neo4j platform as its engine.
Simply an RDF-based harness informed by ontologies (homegrown and/or shared), held in loosely-coupled, plain-text, open-standard documents under the operator's own repository. Because it is not bound to any single model vendor — Claude, GPT, DeepSeek, GLM, and Grok can all read and extend the identical contract — an agent's identity, preferences, and history never need to reside inside, or be re-sent as opaque context to, a frontier model provider's own systems.
Convergence Thesis🔗
Despite opposite data models and opposite scopes — enterprise business vs. agent self-conduct — both artifacts land on the same argument: intelligence is now a commodity available to everyone at the same API price, so the only durable advantage left is a faithful, governed record of what an organization, or an agent, actually knows and has learned, kept under its own control rather than leaked into a frontier model it does not own. Neo4j states this directly: "Intelligence is a commodity. Knowledge is the moat." — defended inside a platform-coupled graph substrate. agent-rdf-memory defends the identical moat with the opposite coupling strategy: a loosely-coupled, ontology-informed RDF harness, built entirely on open standards, that refuses to let any behavioral rule live only in a chat transcript that evaporates the moment the session ends — or only inside one vendor's model.
How This Comparison Was Produced🔗
Retrieve both source articles in full
Fetched the Neo4j blog post directly, and located the OpenLink post's actual body inside its embedded post-content iframe rather than the weblog listing page.
Extract each article's core argument and terms
Identified Neo4j's EKL definitional layers (technical, domain, policy, organization ontology; OBSL vs. full EKL) and OpenLink's 11-layer Agent Engineering Stack scorecard as the load-bearing structure of each source.
Reuse the existing agent-rdf-memory companion entity, not re-mint it
Bound a prefix to the already-published agent-rdf-memory-stack-alignment-inline-links.html companion RDF and referenced its repository resource directly, per the cross-document local-term-reuse rule.
Reuse the canonical ComparisonDimension term via its origin prefix
Bound the cdx: prefix to ComparisonDimension's canonical corpus origin document rather than re-minting a local class, per the ontology cross-reference gate.
Build an eleven-dimension comparison table
Selected eleven axes — including knowledge control vs. frontier-model leakage — and classified each as convergent or divergent based on what each source article actually states, not inferred capability.
Generate the RDF, HTML, and Markdown companions
Transformed the comparison into RDF-Turtle via document-to-kg-skill, rendered it as this HTML infographic via rdf-infographic-skill, and wrote the Markdown companion.
Frequently Asked Questions🔗
What is Neo4j's Enterprise Knowledge Layer (EKL)?
A shared, governed substrate — built on a property graph — where an enterprise's ontology, enterprise data, and decision-trace memory live, accessible continuously to every agent, tool, and application rather than being rebuilt inside each one.
What is agent-rdf-memory?
A queryable behavioral contract in RDF — representable as RDF-Turtle, JSON-LD, RDF/XML, or other open-standard document types — for AI coding agents: a hub-and-spoke preferences.ttl with 140+ HowToStep entries, companion howto/*.ttl specification files, episodic sessions/, and a typed entities/ registry, retrieved via a mandatory 9-step session-start protocol combining SPARQL query and filesystem search.
What do both approaches agree on?
That the reasoning model itself is not the bottleneck. Frontier LLMs are commoditized and rented by the token; the durable advantage is a governed, queryable record of meaning that agents draw on instead of re-deriving or duplicating it per session or per agent.
How do the two differ in data model?
EKL is built on Neo4j's property graph and queried in Cypher. agent-rdf-memory is RDF triples using a variety of notations and syntaxes (Turtle, JSON-LD, RDF/XML, etc.), using W3C standards (RDFS, OWL, SKOS) and schema.org terms. For instance, it can be queried in SPARQL over an endpoint — such as what a Virtuoso instance provides, whether run locally, on-premise, or hosted across various clouds (AWS, Azure, GCP).
How is the ontology built in each approach?
EKL uses a hybrid method: LLMs propose mappings bottom-up from real schemas and glossaries, and humans ratify what's authoritative. The article names two industry standards, FIBO and SNOMED, as optional alignment examples customers often reach for — it does not describe the EKL platform itself formally importing them. agent-rdf-memory is ontology-driven throughout: its own ontology.ttl formally imports shared ontologies (OPAL, PROV-O, the Event Ontology) alongside homegrown classes, and a typed entities/ registry gives every entity a canonical type for deterministic resolution and reconciliation. preferences.ttl separately grows the behavioral-rule layer incrementally, one HowToStep at a time, from user corrections.
How does each approach handle agent memory and traceability?
EKL captures a decision trace on every interaction so the ontology holds what's possible while memory holds what's proven. agent-rdf-memory separates memory into three explicit tiers: episodic session files, semantic entity files, and long-term behavioral rules in preferences.ttl.
How does governance work in each?
EKL federates governance the way data mesh federates data: domain teams own their own definitions, a platform team owns the shared substrate, and a policy ontology enforces access computationally at query time. agent-rdf-memory's preferences.ttl is itself the policy layer, manifesting a Knowledge Graph deployed using Linked Data principles (i.e., a Semantic Web), implemented as hard, fail-closed compliance gates plus a public/private file split.
What query language does each use?
Cypher against Neo4j for the EKL. SPARQL against a Virtuoso endpoint for agent-rdf-memory, selected via prompt-intent classification as a bounded relevance budget rather than a full context dump.
Does either approach address agent identity directly?
Only agent-rdf-memory does, explicitly. Its core.ttl models both agent and user identity as RDF resources, with a verified-identity sub-HowTo that runs openssl certificate-modulus checks for whoami-class requests. The EKL article does not describe a comparable identity mechanism.
Is either approach vendor-dependent?
EKL is engineered on top of a commercial graph platform (Neo4j) — "you don't buy it, you engineer it" — but the substrate itself is a vendor product. agent-rdf-memory is a plain-text git repository, model-agnostic by design.
Which has the bigger scope — enterprise data or agent conduct?
EKL is enterprise-wide in scope: customers, processes, compliance, org structure. agent-rdf-memory is agent-scoped by default — it models how the agent itself should behave — but is not limited to that: its ontology-driven design (homegrown and/or shared ontologies typing every entity) extends equally to business-domain entities, giving it deterministic entity resolution and reconciliation as a byproduct.
Can the two approaches be combined?
In principle yes: an agent could consult an enterprise-scale EKL (property graph) for business grounding while using an agent-rdf-memory-style RDF contract (SPARQL) for its own operating identity, preferences, and session history — the two operate at different layers and neither precludes the other.
What is the real, shared perspective behind both approaches?
Both are offering a perspective on AI agent harnessing that lets an enterprise, or an agent operator, retain control over its own knowledge rather than leaking it to a frontier model — as static prompt context, as duplicated MCP-server logic, or simply by having no record of it outside a vendor's chat transcript. EKL keeps that control inside a governed, enterprise-operated graph platform. agent-rdf-memory keeps it even more directly: it is simply an RDF-based harness informed by ontologies (homegrown and/or shared), held in loosely-coupled form and built entirely on open standards, so the knowledge never has to live inside, or be re-derived by, any single frontier model.
Key Terms🔗
KG Explorer — Comparison Ontology & Instances🔗
The same graph described by the companion RDF, rendered live: the two source articles, the two KnowledgeSubstrateApproach instances, and the 10 ComparisonDimension instances linking them. Drag nodes, click to open a Linked Data description, switch to Advanced + Full to see literal comparison text.