RAG vs a context engine

Retrieval-augmented generation (RAG) is a technique that retrieves passages relevant to a query from an index and adds them to a language model's prompt, so the answer draws on documents the model was not trained on. A context engine is a governed knowledge layer: it curates company knowledge into identifiable, evidence-backed units and records which units each run used.

What is RAG and where does it work?

RAG was introduced in a 2020 paper by Patrick Lewis and colleagues, which combined a pretrained generator with "a dense vector index of Wikipedia" accessed by a neural retriever. Today's common pattern is the same idea at enterprise scale: split documents into chunks, embed them, store the vectors, and at query time retrieve the most similar chunks and place them in the prompt.

It works well where a relevant passage is a good answer. Search over a large document estate. An IT help desk that points to the right article. A research assistant that summarizes what the contracts say about termination. In each case the person reading the answer can follow the link, judge the source, and decide. RAG is cheap to start, works with any model, and improves with better chunking, hybrid keyword and vector search, and reranking.

Where does RAG break down in enterprise use?

RAG strains when agents act on what they retrieve, and when someone later has to explain why. The limits are structural, and a better embedding model does not remove them.

The chunk is the wrong unit. Chunks are sized for the embedder. A 500-token chunk of a finance policy can hold a dozen separate rules. If one is stale, the citation still points at the whole chunk, and nobody can say which sentence the model relied on.

There is no provenance chain. "Document X, chunk 14" says where the text sat. It does not say which version of the document, whether a newer document replaced it, or who approved it. The original RAG paper itself listed providing provenance for a model's decisions as an open research problem.

Nothing is classified. A regulated accounting policy, a sales rep's note, and an outdated draft sit in the same index with the same weight. The system cannot treat them differently because it does not know they are different.

There is no change control. When the capitalization threshold moves from 5,000 USD to 2,500 USD, the old handbook stays in the index until someone removes it. Re-indexing replaces text; it does not record that one rule superseded another.

It cannot prove what was used. A log of retrieved chunks shows what the retriever returned. It does not show what actually entered the prompt, what the model cited, or whether the model cited something it was never given.

None of this matters much for a search box. It matters a great deal when an agent drafts a journal entry or routes an approval based on a rule it retrieved.

What does a context engine add?

A context engine treats knowledge as governed data rather than as an index of text. Five properties distinguish it.

Typed, atomic units. Each unit is one claim that can be true or false on its own, such as "Purchases under 2,500 USD are expensed in the period incurred." It carries a knowledge type (a definition, an observed fact, a prescribed rule, a procedure).

Evidence and identity. Each claim carries the passage that supports it, with source and location, and an identity computed as a content hash of claim and evidence. Two systems can refer to the same claim by the same name, and a citation becomes an exact reference.

Classification that governs change. Some knowledge never changes automatically. Some needs a person to approve a change. Some is checked for conflicts. Some updates itself from data. The classification decides which.

A graph. Units link to each other (one refines another, one describes another, units belong to the same set), so retrieval can walk related knowledge instead of relying only on text similarity.

Accounting per run. Every run records which units were retrieved, which were injected into the prompt, and which the model cited. Retrieved contains injected, which contains cited. Because citations are content-addressed, the exact knowledge behind any output can be produced later.

The curation loop ties these together: changes are proposed (from a document, a connector, an agent, or a person), gated by classification, applied by superseding the old unit rather than overwriting it, and scored from how units perform in use.

How do RAG and a context engine compare?

How does a context engine relate to GraphRAG, knowledge graphs, and semantic layers?

These are related ideas that solve different parts of the problem, and a context engine can work alongside any of them.

GraphRAG

Microsoft Research describes GraphRAG as "a structured, hierarchical approach to Retrieval Augmented Generation." It extracts a knowledge graph from raw text, builds a community hierarchy, and generates summaries, then answers questions through global search over community summaries or local search around specific entities. GraphRAG improves what retrieval can answer, especially questions about a whole corpus. It is still a retrieval method: the graph is generated from text, and it does not by itself classify knowledge, gate changes, or account for what a run used.

Enterprise knowledge graphs

Knowledge graphs model entities and relationships explicitly. Glean's Knowledge Graph, for example, organizes indexed enterprise information around content, people, and activity. That shape is well suited to search and discovery across what a company has written. Its unit is the document, the person, and the interaction, rather than the atomic claim with evidence.

Semantic layers and ontologies

A semantic layer defines business metrics once. The dbt Semantic Layer centralizes metric definitions such as revenue so every downstream tool computes them the same way. Ontologies extend this to business concepts: the Fabric IQ ontology (in preview) defines entity types, relationships, metrics, and natural-language rules bound to OneLake data, and Databricks announced Genie Ontology in June 2026, which it says learns an ontology from data and human-annotated business semantics. These layers govern the numbers and the shape of the business. A context engine governs the written knowledge that interprets them: the policy, the threshold, the exception, the procedure. An agent often needs both.

Vendor context layers

Several vendors now describe a context layer for agents. Celonis's Context Model, launched in May 2026, is described as "a dynamic, real-time digital twin of operations" built from process data and business knowledge. Where the relevant knowledge lives in event logs, that is a strong foundation. Each of these products solves the problem it set out to solve. When evaluating any context layer, including Pyrana's, ask what the unit is, whether it carries verbatim evidence and a stable identity, how a change is approved, and whether a run's retrieved, injected, and cited knowledge can be produced on request.

When should you use RAG and when a context engine?

Use RAG when people read the answer and judge the source themselves, when the corpus is large and loosely structured, and when being slightly out of date is tolerable. Use a context engine when agents take actions based on company rules, when rules change and old versions must stop applying, when different kinds of knowledge need different change controls, and when an auditor, regulator, or controller may ask which rule an agent applied.

The two are not exclusive. A context engine typically includes semantic search over source passages as one retrieval mode, and many enterprises keep a RAG-based search experience for employees while agents that act on policy draw from curated units.

How Pyrana's context engine works

Pyrana's context engine is cortIQ (formerly the Context Engine). It holds company knowledge as Context Units: a claim, its evidence passage with source and location, a knowledge type (axiomatic, empirical, prescribed, or procedural), a classification (absolute, regulated, contextual, tribal, or derived), an evidence grade, a quality score, and an identity that is a content hash of claim and evidence. Units link in a knowledge graph. Absolute units never change automatically; regulated units wait for a person; tribal units are conflict-checked; derived units update themselves. Changes supersede, never overwrite.

Agents retrieve through three modes: Knowledge (a set-anchored graph walk, weighted by quality), Facts (units flagged as facts), and Search (semantic search over source passages). Standing sets preload before the first turn, and mid-run an agent can call context search, pause, retrieve, and resume. Engine-side agents help: a query agent plans the graph walk and repairs its own queries, and a learning agent scores what was retrieved and used and flags units that never help for review. Nothing is deleted automatically.

Every run is accounted for as retrieved, injected, and cited, so the business context behind any output is provable. Feedback from chat, frontend feedback lanes, and evaluations flows back into curation. cortIQ sits under every Pyrana application, which means the second application starts with what the first one taught it. For the design in depth, see cortIQ, Workflows aren't enough: why knowledge is the moat, and the Context Unit blueprint.