Forrester Just Defined the Context Layer. Memory Is The Hard Part.
How OpenAI and Anthropic built context layers for their own data agents
In June, Anthropic published how they built self-service analytics on Claude. Without the curated Skills layer they built, their agent answered 21% of business questions correctly. With it, the same model was consistently above 95%.
OpenAI arrived at the same place by a different road. Their internal data agent runs on six layers of context: table usage and lineage from OpenMetadata, enrichment pulled from the codebase, human annotations, institutional knowledge, memory that captures corrections so the next person benefits, and runtime context. Memory alone took one question path from 22 minutes to one.
Two of the organizations closest to the frontier of AI wanted the same thing. Let anyone ask a question about the business in plain language, and trust the answer. In both cases the fix was governed context about the business, and in both cases they had to build that layer themselves.
I have been building data systems at scale for a long time, at Hortonworks and then at Uber, so this is the conclusion I would expect. When two organizations with that much model expertise reach it independently, that is a category forming.
Forrester's definition of a context layer
Last week Boris Evelson and Indranil Bandyopadhyay published Forrester's proposed definition of this category in their post, “The Next Evolution Of AI Will Rely On Context Layers.” I think they got it right, and it is good to see this taking shape.
They open with the problem: "Context has become a buzzword, with terms like semantics, ontology, semantic layer, knowledge graph, and context layer being used interchangeably. Enterprises need a clearer definition of what they are trying to build." Then they give one:
A context layer is the next evolution of semantic layers and knowledge graphs, providing the foundation for neurosymbolic AI context engineering and agentic AI applications. It combines business semantics and governance of semantic layers with the ontological modeling of knowledge graphs. The context layer represents all enterprise knowledge across data, metadata, business concepts, policies, and processes through graph-based ontologies and linked context. In addition, it continuously incorporates runtime context such as events, decisions, actions, and outcomes, creating a living model of the enterprise that enables AI reasoning, automation, and decision intelligence.
Two things there deserve credit. Treating this as a category in its own right rather than a feature of something else is the harder call and I think is the more useful one to organizations trying to figure this out. And calling it the next evolution of semantic layers matters, because for a lot of buyers "semantic layer" still means a metric store, a place where revenue gets defined once so two dashboards stop disagreeing. This is worth having, but it is a fraction of what an agent needs to answer a question correctly.
Memory is the hardest part of a context layer to implement
Collate is built on three primitives, and we develop all three in the open, in OpenMetadata.
-
Context defines what data exists, connecting metadata, documents, policies, lineage, quality signals, and access rules.
-
Ontology defines what the data means, through business concepts and typed relationships.
-
Memory preserves approved decisions and corrections, so the next answer starts from what the organization already settled.
The first two are becoming table stakes. A dozen vendors will claim context and ontology by the end of the year, and some of them will be telling the truth.
Memory is where it gets hard, and it is the requirement inside Forrester's definition that I expect most of this market to gloss over, whatever the marketing says. A living model that takes in events, decisions, actions, and outcomes means the system has to get better because people used it. Most implementations are read-only. The agent consumes context, produces an answer, and writes nothing back, so the graph is exactly as smart in month six as it was on day one while the business it describes has moved on.
Across our customers and the OpenMetadata community, we see valuable context still trapped in someone's head, a Slack thread, an incident review, or a one-time correction made during an AI conversation. That last one bothers me most, because the context was created inside the system and then thrown away. If the learning disappears when the conversation ends, the context layer is not truly living.
Session memory helps an agent remember a conversation. Governed memory helps the enterprise remember. A governed memory attaches to the data asset or business concept it describes, inherits that asset's role-based access and governance, maintains an audit trail, and is retrieved only within the permissions of the user the agent represents. For example, when Finance decides that a variance caused by one renewal slipping three weeks should not trigger an alert every morning, that decision has to live next to the lineage and the permissions rather than in the head of the analyst who made it.
OpenAI built that themselves and called it a “learning flywheel.” Anthropic solved the adjacent problem with curated Skills and named data staleness as one of three ways their system fails without it. Both teams had the engineers to build it.
The same loop is now showing up outside the frontier AI labs. Angelita Frozza Sanches, who is head of data at Scout24, presented what her team calls a virtuous AI cycle at Collate Summit in June. In it, people work with an agent, the gaps and corrections that surface go to a human for review, and what gets approved is written back into Collate and served to the next person or agent through MCP. The system gets better because people and AI agents use it and provide feedback for continuous improvement.
Most teams cannot staff that from scratch, and none of them should have to.
So we build governed memory in the open. Organizational Memory is in OpenMetadata 2.0 under Apache 2.0, sitting in the same graph as lineage, ownership, and access rules, alongside Context Center, the Knowledge Graph, and Ontology Explorer. Collate 2.0 adds the automation that generates and applies memories to work as it runs. All of it is built on DCAT, OWL, RDF, SKOS, and PROV-O, so what you create cab be exported and read by other humans or agents easily. Nothing gets copied into our graph either; the metadata carries the meaning and points at data that stays where its owners put it.
Vendors who require ingesting enterprise data into a graph will disagree with that last part, and it is a legitimate design choice with benefits. But it also means every data source you add is a pipeline you own, a copy you must store and secure, and a sync you debug when two nuambers stop matching. That tax compounds.
Two requirements missing from Forrester's context layer definition
Forrester's definition covers what a context layer represents and that it keeps taking in runtime context. It says nothing about whether any of it stays true over time.
Context decays quietly. A business term gets redefined during planning and the ontology never gets updated. Or a source table gets deprecated while the glossary entry still points at it, and somewhere in the organization the person who owned a dozen key definitions has left without handing them to anyone. None of this breaks operations, but it moves the model a little further from the business each time, and the failure mode is a well-formed, confident, wrong answer. Anthropic listed data staleness as one of three ways their system fails, which matches what we see.
If I were writing inclusion criteria for this category, I would add two.
Context lifecycle governance. Ownership, a review cadence, versioning, and a way to retire a definition. Every piece of meaning needs someone accountable for it and a path for it to expire.
Provenance and explainability. Which definition an agent used, who approved it, when it last changed. Anthropic ships provenance footers for exactly this. If you cannot answer those three questions about an answer, you cannot audit it, and an agent nobody can audit will not be allowed near a regulated decision.
One more step follows from this. Policies are already in Forrester's definition as something the context layer represents. Once that layer is feeding agents, it becomes the right place to govern the agents too, because it already knows what each one can reach, where its context came from, and who approved it. That is the thinking behind Collate AI Governance Studio, which enters release preview with 2.0 for design partners and which we announced separately this week.
Three ways to get a context layer without building one from scratch
Everything above describes work that OpenAI, Anthropic, and Scout24 did for themselves. OpenAI and Anthropic built the whole layer from scratch. Scout24 built their loop on top of ours, a smaller job but still real engineering. Both paths need people most organizations do not have, and making that unnecessary is the reason Collate exists.
The third path is to use something already built on the layer. Divisions Maintenance Group, a facility maintenance provider, moved off a siloed AI analytics tool because it had no memory, so their team kept rebuilding the same AI skills every time the questions changed. They brought more than 500 business users onto Collate AI Analytics, where the context improves as people ask questions.
Peeyush Nahar, chief product and technology officer at DMG, described the problem well:
Other AI-driven analytics tools could generate a chart but they couldn't tell you if the chart was right because they had no knowledge of how we define our metrics, where the data came from, or what a quality failure means in our business. Every answer needed a second opinion. With Collate AI Analytics, our analysts don't have to worry about a dashboard being grounded in incorrect or ungoverned data. It encodes how our business works and gives the AI that foundation before the question is even asked. There's no second-guessing.
That is the same loop the labs built, at a company that never had to staff a research team to get it.
Collate 2.0 ships this week on OpenMetadata 2.0 underneath. Context Center holds the documents, articles, and memories, and applies access controls when an agent retrieves them, so an agent sees only what the person it represents is allowed to see. The piece I would point an architect at first is persona-based context curation: a finance persona receives the approved revenue metric and the planning policy, while an engineer investigating the same number receives the schemas, lineage, and quality failures instead.
That curation is not only about relevance. An ungrounded agent bills you twice, once for the tokens it burns exploring and again for every speculative query it fires at your warehouse while it looks around. Narrowing what each persona receives cuts both, and Collate shows you the token cost of a persona's context before you deploy it.
On Spider 2.0, we showed that grounding an agent in this context layer moved execution accuracy from 11% to 76.5%. That is our own testing on a public benchmark. We are running it again against current models, and early results point to context cutting errors by 86%. The full benchmark and methodology from our engineering team will publish shortly.
Your ontology, your metric definitions, and the corrections your people have made over the years are institutional knowledge. They are the one asset in this stack that should outlive every tool you use to build them, including ours. That is why memory, the knowledge graph, and the context APIs are Apache 2.0, not the part we hold back. A context layer you cannot export and read somewhere else is asking you to rent your understanding of your own business, and no definition Forrester writes will make that a good trade.