OpenClaw Engram v9: What Changed

OpenClaw Engram is now on v9, and I wanted to go back through the GitHub repo to see what actually changed.

Not the marketing version. The real version.

Because memory projects are easy to oversell.

The short version

v9 feels more serious.

The earlier versions already covered the basic case: persistent memory, structured extraction, local markdown storage, and retrieval. That was useful. But the v9 line pushes the project into a different category.

It starts looking less like “a plugin that stores memory” and more like “a system that’s trying to govern memory quality over time.”

That’s the part I think is worth paying attention to.

The most visible change: more search backend options

The current repo adds support for multiple search backends, including:

• QMD
• LanceDB
• Meilisearch
• Orama
• remote and noop modes for special cases

This matters because retrieval is where a lot of memory systems win or lose.

Different teams want different tradeoffs. Some want an embedded local path. Some want a server-backed search service. Some want the simplest possible setup. v9 gives more room there than the earlier versions did.

Better retrieval discipline

The other big thing in v9 is the amount of work going into recall quality.

A few examples from the current repo and changelog:

• verified recall
• trust zones
• risky-promotion corroboration
• provenance trust scoring
• work-product recall
• causal trajectory memory
• harmonic retrieval
• abstraction nodes and cue anchors
• rule promotion and verified rules

Some of those features are gated. Some are foundational slices. Some are clearly still expanding.

But taken together, they point in the same direction: memory shouldn’t just be stored. It should be ranked, checked, and surfaced with more discipline.

Benchmarking and evaluation

This is one of my favorite parts of the current v9 direction.

The repo now includes benchmark and evaluation harness work, baseline snapshots, delta reporting, shadow recall recording, and CI benchmark gates.

That’s useful because it shifts memory quality away from vibe-based evaluation.

If a recall change makes things worse, I want a system that can tell me that. Memory needs more of that kind of thinking.

Local LLM support is getting better too

The v9 line also keeps pushing on local model support.

The changelog shows a lot of work around:

• local extraction compatibility
• fallback behavior
• fast-tier suppression for thinking-heavy local models
• embedding request compatibility
• dual-tier local LLM routing

That matters if you’re running local infrastructure and don’t want the memory layer to be fragile just because your model endpoint behaves differently from the hosted default path.

Search is only part of it

When people hear “memory plugin,” they often think search first.

Search matters, but the current repo has grown beyond that.

The v9 line also includes work around:

• commitment ledgers and commitment lifecycle handling
• work product ledgers
• utility telemetry and learning
• policy runtime controls
• objective-state snapshots
• session integrity and repair flows
• shared context and cross-signal work

That’s why I said v9 feels more serious.

It’s starting to behave like memory infrastructure instead of a helper layer.

What still matters most to me

Even with all of those additions, the core reasons I care about Engram haven’t changed.

I still want memory to be:

• local-first
• inspectable
• structured
• retrievable
• durable over time

The newer v9 work adds quality controls and broader memory surfaces, but those core values still matter more than anything else.

If a memory system gets more capable and less understandable at the same time, I don’t think that’s a good trade.

My read on the roadmap inside the repo

The repo is pretty active, and not every feature carries the same weight yet.

So I think it’s fair to separate the v9 story into two buckets.

What clearly matters now

• multiple search backends
• stronger retrieval and recall controls
• better local LLM compatibility
• operator tooling and CLI growth
• benchmarking and evaluation work

What feels like active expansion

• more sophisticated trust and verification layers
• memory quality learning loops
• richer abstraction and causal recall models
• broader memory operating system ideas

That split is healthy. It means the project has useful current functionality without pretending every newer idea is already mature.

Why this matters for OpenClaw users

Most OpenClaw users aren’t looking for theoretical memory research.

They want an agent that stops forgetting, carries context across time, and behaves more consistently.

v9 matters because it moves Engram closer to supporting that in a way that’s measurable and operator-friendly.

Not perfect. But more serious.

Bottom line

If you looked at OpenClaw Engram earlier and haven’t checked back in a while, v9 is worth another look.

The project now has broader search support, better retrieval controls, more operator tooling, and a much stronger emphasis on evaluation and memory quality.

That’s the right direction.

Related reading

If you want the surrounding context, I’d pair this with:

• I built a memory system for AI agents because they keep forgetting everything for the original why.
• OpenClaw memory problems users keep running into for the recent frustration patterns.
• How to make OpenClaw remember for the practical fix.
• What I’d look for in the best OpenClaw memory plugin for the comparison frame.

If you’re building on OpenClaw and memory is still the weak link, this release line is worth paying attention to.