TL;DR. OpenMetadata, the most widely deployed open-source metadata platform at roughly 15,000 GitHub stars, shipped its second 2.0 release candidate on August 13, 2026, and the release line arrives under a new identity: the project now describes itself as "The Open Context Layer for Data and AI" rather than a data catalog. The pieces behind the rename are real and recent: MCP services and a knowledge graph landed in 1.13.0 in June, stored memories now sit in the metadata graph beside lineage and quality signals, and the commercial layer from Collate adds a Context Center and compounding agent memory. The rebrand marks a category converging from two directions at once: catalogs are adding memory while agent-memory vendors add governance, and both now claim the same phrase. What neither side has settled is the part that matters for trust: a lineage edge derived from a pipeline and a memory written by an agent are different kinds of knowledge, and putting them in one graph does not make them equally reliable.
On August 13, 2026, OpenMetadata published 2.0.0-rc2, the second release candidate on the line that will replace 1.13. The release notes are operationally boring on purpose: do not run it in production, use it in dev and test, report migration issues. The interesting change sits above the release notes. The project that effectively defined the open-source data catalog category now describes itself as "The Open Context Layer for Data and AI", and its homepage leads with "#1 Open Source Context Layer". The word catalog is receding from the tin while the software inside is still, recognizably, the catalog.
Renames in infrastructure are usually marketing. This one is worth a closer read: the pieces behind it shipped before the words changed, and OpenMetadata is not alone in reaching for the phrase. The agent-memory vendors are converging on the same ground from the opposite direction, and when two adjacent categories rename themselves onto the same square, the square is worth understanding.
The rename has receipts
The 2.0 positioning did not appear with the RC. It assembled over about ten weeks.
Release 1.13.0 landed on June 8 carrying the two structural pieces: MCP Services, which turn the platform into a set of tools any LLM can call, and a knowledge graph with RDF support, which restructures the metadata store into something an agent can traverse rather than a set of pages a person browses. Two days later, Collate, the commercial company founded by OpenMetadata's creators, announced Collate 2.0: a semantic context graph at the core, an AI Studio for agent workflows, and a Context Center that ingests documents from tools like Confluence and shared drives and ties them to data assets, with articles and memories inheriting the domain metadata and access controls of the assets they attach to. General availability followed in July. The open-source release candidates came after: rc1 on July 30, rc2 on August 13, while 1.13.3 from July 31 remains the latest stable release.
The README states the thesis in one line: "AI does not need another raw database connector. AI needs context + memory." And the list of what the platform now connects into its graph is worth quoting in full, because two items in it would not have appeared in any catalog's feature list three years ago: technical metadata, quality signals, lineage, ownership, usage, policies, glossaries, classifications, metrics, domains, data contracts, data products, and then, in the same sentence, conversations and memories.
The AI SDK makes the agent-facing surface concrete. It exposes the platform over MCP as semantic search, lineage traversal, glossary access, and metadata mutations, and it adds Context Memories: hybrid vector and keyword search over reusable knowledge, user preferences, runbooks, FAQs, attached to specific data assets and retrieved during agent execution. Collate's launch material claims semantic context of this kind improves data-agent accuracy by up to seven times; that is a vendor benchmark, and worth treating as one until it is reproduced independently.
Why a catalog wants to be a context layer
The unkind version of the story is that the catalog category needed a new name. Catalog adoption has a well-known failure mode: the platform gets deployed, gets populated, and then depends on humans remembering to consult it. A human analyst opens the catalog a few times a week, when they are stuck.
Agents change the economics of that install base. An agent answering questions against a database can consult metadata on every single query, without fatigue and without needing to be reminded. The context a production agent needs, which columns are canonical, which joins are real, what a metric means, is exactly the material a well-run catalog already holds. For the first time, the catalog has a consumer whose query volume justifies the maintenance cost. Repositioning the product around that consumer is rational, and OpenMetadata has more of the underlying substance to point at than most of the vendors who will follow it.
The move looks even more deliberate against what is happening one category over. The agent-memory vendors have spent 2026 adding exactly the properties catalogs are known for. TencentDB Agent Memory, which reports crossing 20,000 GitHub stars within 90 days of release, shipped team-scoped memory on the same day as rc2: shared memory assets with owner, version, and permission governance. We wrote about that trajectory in shared agent memory needs intrinsic access control: memory stores are acquiring ACLs, ownership, and audit, which is to say they are acquiring catalog features. Catalogs are adding memory; memory stores are adding governance. Both camps now describe the destination with the same phrase.
Two categories, one destination. The catalog side arrives with derived metadata and adds memory; the memory side arrives with runtime writes and adds governance.
The line 2.0 erases, and why it mattered
Our guide to the memory-versus-context boundary drew a distinction that this convergence deliberately blurs. Context describes the data estate: derived from real systems, reviewable by the people who own the data, re-derivable when someone doubts it. Memory records what an agent experienced: written at runtime, by the agent, about its own interactions. The two go stale differently, fail differently, and warrant different levels of trust.
OpenMetadata 2.0 puts both kinds of entry in one knowledge graph. A lineage edge computed from a pipeline sits beside a memory an agent wrote last Tuesday; an agent traversing the graph receives them with the same authority. But the lineage edge is a measurement: doubted, it can be recomputed from the pipeline that produced it. The memory is testimony: doubted, there is nothing to recompute, only a record that some agent, with context now lost, once concluded something.
Testimony has failure modes that catalog infrastructure was never built to handle. Staleness is the sharpest one: a stored claim like "this table was verified clean" is true about a moment, and silently stops being true when the thing it checked drifts. Recent research is starting to treat this as the central problem; EA-Graph, posted this month, anchors a coding agent's verification claims to the exact content that was checked, so the claim visibly expires when the content changes rather than rotting in place. Provenance is the second: who wrote this memory, from what evidence, with what permissions. The memory-poisoning literature this summer showed persistent stores are attractive targets precisely because entries outlive the session that created them.
There is a precedent for this shape of problem. When we read the Apache Ossie spec, the finding was that definitions travel and trust does not: the interchange format carries what a metric means and has no place for who verified it, when, or against what. The context-layer convergence is opening the same gap one layer up. Memories carry meaning. The machinery that would let a consumer decide how much to believe a memory, its age, its author, its evidence, whether what it describes has since changed, is the part neither the catalogs nor the memory vendors have shipped. The graph unifies the storage before anyone has unified the trust model.
The license seam
One structural detail is easy to miss. OpenMetadata's core is Apache 2.0, as it has always been. The AI SDK, the component that packages the context layer for agent frameworks, ships under the Collate Community License 1.0, a source-available license, not an open-source one. Nothing about that is unusual as commercial strategy, and Collate funds most of the project's development. But for anyone whose evaluation checklist says "open-source context layer", it is a map worth having: the catalog is open, and the seam between open and commercial runs exactly along the new agent-facing surface. Where a category is being renamed, checking which parts of the new name are covered by the old license is due diligence, not cynicism.
Evaluating during the RC window
If OpenMetadata is on your shortlist this quarter, the software is mid-migration while the category is mid-rename, and the two transitions ask different questions.
For the software transition, the guidance is the maintainers' own: release candidates are for dev and test, migration changes are still landing between candidates, and production stays on 1.13.3. Run the RC against a copy of your metadata store and report what breaks; that is what the window is for.
The category transition is where evaluation criteria actually change. A catalog evaluation asks about connectors, lineage coverage, and search. A context-layer evaluation should add questions the catalog tradition never asked. Which entries in the graph are derived from systems, and which are testimony written by an agent? Can an agent consuming the graph over MCP tell them apart at query time? Who may write memories, with what scoping, and how does a correction propagate to agents that already read the wrong version? What expires a memory: time, an explicit revocation, or drift in the thing it describes? None of these have standard answers yet, which is exactly why they belong in an evaluation now.
Where Datapace sits
Datapace's short version of this whole story is four words: catalogs describe; Datapace governs. The convergence this post describes is real and, in our view, correctly aimed: agents do need context plus memory, and the catalog estate is genuinely the right substrate for the derived half. OpenMetadata's connector ecosystem is part of how Datapace intends to see beyond Postgres, so its context-layer turn reads to us as complementary rather than competitive.
Datapace is building the layer that the convergence has not reached: the context layer between your databases and your AI, with resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. The trust questions this post raises about memories, who wrote a claim, from what evidence, and whether it still holds, are the questions our context model is designed around. If you are working through what an agent-facing context layer should look like for your estate, book a call.
Sources
- OpenMetadata, Release 2.0.0-rc2, August 13, 2026, and releases index (1.13.0, June 8; 1.13.3, July 31; 2.0.0-rc1, July 30).
- OpenMetadata, project README ("The Open Context Layer for Data and AI"; "AI does not need another raw database connector. AI needs context + memory").
- Collate, "Collate 2.0 Fixes AI's Biggest Enterprise Data Problem", June 10, 2026; syndicated via GlobeNewswire.
- OpenMetadata and Collate, AI SDK repository (MCP tools, Dynamic Agents, Context Memories; Collate Community License 1.0).
- Futurum Group, "Collate Turns OpenMetadata Into a Persistent Semantic Memory Layer for Enterprise AI Agents".
- Tencent Cloud, "TencentDB Agent Memory ships Team Memory", August 13, 2026.
- EA-Graph: artifact-anchored verification memory for coding agents, arXiv:2608.04278, August 2026.