A semantic layer defines the business terms and metrics that agents use to query structured data. A context graph holds how those terms relate, the company's rules and exceptions, their owners, and which rule takes precedence when two apply. Agent memory records what an agent learned while working, which usually means what people told it, and it cannot settle conflicting memories by authority.
What is the difference between a semantic layer, a context graph, and agent memory?
You cannot tell the three apart by the database underneath. In one memory architecture that a memory vendor's researchers posted to arXiv in 2025, memory is itself a graph built from conversation messages.
What separates them is where the content comes from. Data teams author a semantic layer, while rule owners and modelers build a context graph from systems, documents, and decisions. Agents write their own memory as they work, so the useful question for a buyer is what a layer holds and who writes it.
| Layer | What it holds | Who writes it | Question it answers | What it misses |
|---|---|---|---|---|
| Semantic layer | Datasets, joins, and metric definitions over structured sources | Data teams | What does "active contractor" mean, and which tables hold customer data? | Documents, owners, effective dates, and exceptions |
| Context graph | Rules, exceptions, and owners, linked to each other and to their sources | Rule owners and the teams that model their rules | Which rules apply to this request, who owns each one, and which governs? | Anything nobody has written down or approved |
| Agent memory | Facts and preferences extracted from an agent's past sessions | Agents, from their own work | What happened the last time a request like this came in? | Anything never said to the agent, and authority between conflicting items |
Treat them as layers with separate jobs, and fund first the one that covers the knowledge your agents get wrong most often.
Where a company keeps what it knows
Agents reach a company's knowledge differently depending on where it sits.
- Structured knowledge lives in tables, metrics, and systems of record. Examples are the HR system and the identity and access management (IAM) system, which controls who can open which data.
- Unstructured knowledge lives in documents, tickets, chats, and standard operating procedures. A policy PDF and a wiki page are both unstructured.
- Institutional knowledge covers decisions, exceptions, who owns what, and how work actually gets done. Much of it sits in an email thread, a meeting outcome, or one person's judgment.
The last kind is the hardest for an agent to reach, because it rarely sits in a system the agent can query.
Example of an access request
A data engineer placed by an outside contracting firm asks for read access to the customer data warehouse.
The access agent has to decide whether this contractor gets it.
Here is the relevant information impacting this request.
| Kind of knowledge | Where it lives | What it says |
|---|---|---|
| Structured | HR system | The engineer is a contractor, placed by the contracting firm, based in the EU, with an end date in June. |
| Structured | IAM system | One group grants read access to the customer tables, and the engineer is not in it. |
| Unstructured | Data-handling policy, a PDF | Contractors may read customer data only with a named employee sponsor. |
| Unstructured | Security standard, on the wiki | The security team reviews every new grant of warehouse access. |
| Institutional | Outcome of last year's audit | EU-based contractors also need the privacy officer's sign-off. |
| Institutional | An email from the chief information security officer (CISO) | The contracting firm's people are pre-approved for warehouse read access until March. |
Neither institutional item lives in a system. The privacy officer applies the audit rule by reading access tickets, and the pre-approval exists only in the CISO's email to the security team.
A careful access administrator would say yes once the engineer has a named sponsor and the privacy officer's sign-off. The CISO's pre-approval waives the security review until March, because that review belongs to the CISO. It does not waive the privacy sign-off, which the privacy officer owns.
The semantic layer handles the structured data
The HR and IAM rows hold most of the plain facts in this request. A semantic layer can define what counts as an active contractor and which tables count as customer data. It can then join the HR record to the IAM groups.
From that join, the agent learns the engineer is a current EU-based contractor, due to leave in June, who sits outside the customer-data group. This is the work the Apache Ossie specification (formerly Open Semantic Interchange) was written for. It describes a semantic model as datasets, relationships, and metrics, with each metric a formula in SQL.
Forrester describes semantic layer platforms in similar terms, as providing governed metric definitions and runtime policy enforcement.
The documents themselves are out of reach, because a dataset's source in the specification is a table, a view, or a query. So the sponsor requirement and the security review never arrive through this layer.
The audit rule could go in only as text. Someone could type "EU contractors need privacy sign-off" into the optional ai_context field, which gives the model a hint. Nothing in the specification records who owns that hint, when it took effect, or which exceptions apply to it.
The specification is also young. It marks itself a draft and warns readers not to depend on the current version in production.
Memory knows what the agent was told
Suppose a security analyst told the agent in September that the contracting firm's people are pre-approved. Memory keeps that remark, so the next time one of the firm's people asks, the agent already has it. If the agent handled an earlier request from the firm, memory can also say how that one went.
That covers the things people say out loud, which is only one slice of unstructured knowledge. The research behind this type of memory is mostly about chat memory. LongMemEval, an independent academic benchmark, tests long-term memory with 500 questions over chat histories, including whether an assistant tracks updated facts.
The rest of this request is harder for memory. It keeps the March end date only if someone mentioned it. It has no record of the audit rule either, because the privacy officer applies that rule in tickets the agent never reads.
Memory holds no systems of record, so the HR status and the IAM groups still come from elsewhere on every request. The memory architecture mentioned earlier builds its graph from conversation messages. Its authors note that existing benchmarks do not test memory combined with structured business data.
When two remembered items disagree, that architecture has a language model judge the contradiction and keeps the newer item. The paper says the system "consistently prioritizes new information." We covered why recency fails for business rules in our post on agent memory.
A context graph needs someone to write the rules down
So far, nothing has reached the audit rule or the CISO's pre-approval. In a context graph, the engineer links to the contracting firm, and the firm links to the CISO's pre-approval. The engineer's EU location links to the audit rule, which carries the audit finding as its source and the privacy officer as its owner.
The documents come in by reference, and so do the systems of record, which the graph points to rather than copies. The sponsor requirement becomes a rule that links back to its page in the policy PDF. The security standard on the wiki stays a linked page until someone models it as a rule.
The standards are good at describing a rule once it exists. The W3C provenance vocabulary, PROV-O, can state who a statement is attributed to, what it revised, and when it was invalidated. But the W3C's RDF primer says nothing about extracting facts from documents, so turning a policy PDF into rules is a separate step.
Gartner frames context graphs around this kind of knowledge. Its February 2026 emerging-tech note, in its abstract, describes context graphs as solving AI's "institutional memory" problem.
Graph databases handle the links well, but a graph cannot know the audit rule exists until someone writes it down. Who writes the rules is still open across the category.
Some tools generate rules from ingested query history, which does not say who approves them. A graph built only by observing past work carries its own risk. An essay in Semantically Speaking warns that such graphs inherit "institutional ambiguity," because repeated exceptions start to look like policy.
A graph that watched last year's grants would see the firm's people approved without a security review. It might then record that as a rule for all contractors.
When the pre-approval and the audit rule disagree
The CISO's email says the firm's people are pre-approved for warehouse access. The audit rule says EU-based contractors need the privacy officer's sign-off. Read literally, the pre-approval covers this engineer, while the audit rule says the engineer still needs a signature.
One rule has to govern, and the record of which one does is precedence.
A semantic layer could hold both rules as free-text hints, with nothing to rank them by. An agent working from memory has the analyst's September remark and nothing about the audit, so it approves the request on the remark alone. Even if memory held both, that architecture keeps the newer item, and the remark is newer than the audit.
The standards leave the choice open as well. PROV-O can record that one rule revised another, but not that the revision governs a given request. The Ossie specification has no owner or effective-date field to rank two rules by.
A context graph can settle the case if someone recorded how the two rules relate. Here the pre-approval is linked to the security standard, and the link waives the review for this firm until March. That waiver reaches only the security review, because that review is the one the CISO owns.
The audit rule belongs to the privacy officer, and the pre-approval has no link to it, so it still applies to an EU-based engineer. Access goes through once the sponsor and the privacy officer sign.
A rule that governs access should carry its owner, its source, its scope, and its end date, wherever it is stored.
Analysts are converging on a term but not on the order of work
Forrester treats the layers as a sequence. Its June 2026 post advises building the semantic layer first and moving toward a knowledge graph later. Most organizations, it says, are "not yet ready" for a graph, and a simpler data graph can serve as a middle step.
Gartner's umbrella term is "context layer." It has published research titled "Define a Context Layer to Mitigate Agentic AI Flaws" and a playbook for establishing an enterprise context layer. From the abstracts and press summaries, we cannot tell whether its context layer records which rule governs.
The order should follow the knowledge your agents get wrong. Forrester's order fits agents that fail on metric definitions. In the access request, the failures sit in the audit rule and the pre-approval, and a semantic layer would not reach either.
VentureBeat ran one of its pulse surveys in July 2026, with 101 respondents and no sponsor named. Of those, 68% had traced a confident but wrong agent answer to missing or inconsistent business context in the past six months. Only 32% ran a governed context layer in production.
Among those running or building a governed context layer, 50% reported recurring agent failures, against 21% of those without one. The article does not explain the gap, and more agents in production or better detection could each produce it. Only 91 respondents answered the failure question, so we read the split as a reason to ask questions rather than as a finding.
Four checks before you buy
These checks show which kinds of knowledge your agents depend on, and whether a product reaches them.
- Trace one decision across the three kinds. Pick a decision your agents make often, such as granting data access. List every source a person checks to make it, and mark each one structured, unstructured, or institutional.
- Ask where the institutional rules go. Give each vendor your version of the audit rule and ask where it would live. Then ask who would write it and who would approve it. "In a free-text field" and "the agent will learn it" both leave the rule without an owner.
- Ask the conflict question. Put this to your team and to every vendor: "Two of your rules both apply to this access request and they disagree. What does your system return?" Then ask who decided which rule wins.
- Check your end dates. Find three exceptions your teams granted this year. For each one, check whether any system records when it ends and who can extend it.
Where Trail fits
Those checks apply to us as well, so here is how Trail handles the access request and what it asks of your team.
Trail is the company brain for AI, and its context graph is the layer your agents run on. It holds rules, exceptions, dependencies, and the reasoning behind them as a graph any agent can follow, including which rule governs when two apply.
In the terms of this guide, Trail is the context graph. It works beside the semantic layer and memory you already run, and any agent or model can read it through MCP, REST, or GraphQL.
In that graph, rules and exceptions are the nodes, while dependencies and overrides are the edges that link them. The audit rule becomes a node owned by the privacy officer and linked to the audit finding. The CISO's pre-approval is a node whose edge waives the security review for the firm's people until March.
When the engineer's request arrives, Trail returns the privacy sign-off and the sponsor requirement as the rules that govern. It cites the audit finding, the policy PDF, and the CISO's email, and explains that the pre-approval covers only the review the CISO owns. The decision is logged with the rules applied and their sources, so a reviewer can see why access was granted without asking anyone.
In March the pre-approval's edge lapses, and the security review applies to the firm's people again.
None of that works until someone authors the rules, which takes more effort than inferring them from past work. To start, you point Trail at the policy, SOP, or agreement that decides the work. Each rule traces back to the text it came from, and each one needs an owner and a place in the precedence order.
Owners carry ongoing work too, because the rule owner sets precedence before two conflicting rules go live. When a conflict turns up that nobody has ruled on, Trail asks the owner instead of leaving the choice to the model.
Trail is self-learning, so the rules stay current as approvals and exceptions from live runs feed back. A person is brought in when two rules conflict, a case falls outside what it knows, or a learning would change how decisions get made.
Frequently asked questions
Is a context graph the same as a knowledge graph?
No, though the two are built from the same parts. "Knowledge graph" is the broader term for entities and their relationships, which W3C standards such as RDF describe. We use "context graph" for a graph of rules, exceptions, and owners, with links that say which rule applies when.
Do you need a semantic layer before a context graph?
Not always. Forrester recommends that order, which fits teams whose agents mostly get metric definitions wrong. In our view, a team whose agents fail on exceptions and approvals should start there and add a semantic layer later.
Does a graph make agents more accurate than a semantic layer?
The often-quoted 16.7% rising to 54.2% comes from a 2023 arXiv technical report by a data catalog vendor's researchers, and it was not peer reviewed. It compared GPT-4 given a bare database schema with GPT-4 given a hand-built model of the business concepts, on 43 questions over a synthetic 13-table insurance schema. That supports adding business context, but no public study we found compares a graph with a semantic layer directly.
Can agent memory replace a context graph?
Not for rules, because memory learns only what someone told the agent. In the memory design described above, newer items win over older ones, with no notion of who had the authority to decide. Memory is still worth keeping for what agents learn from their own work, beside a graph that records the rules.
Does adding a context layer reduce agent failures?
We found no public evidence that it does. In VentureBeat's July 2026 survey, respondents running or building a governed context layer reported recurring failures more often, 50% against 21%. The sample was 101 respondents and the article does not explain the gap, so we would not read it as proof either way.
Who should own institutional knowledge?
Each institutional rule should have one named owner, usually the person who resolves it today. In our example, the privacy officer owns the audit rule and the CISO owns the pre-approval. When a design has no place for the owner, nobody is asked when two rules conflict, and the model decides.