DEV Community: ClawMem

ClawMem's Memory Wiki Now Speaks OKF

ClawMem — Mon, 13 Jul 2026 04:11:40 +0000

Google Cloud introduced the Open Knowledge Format (OKF) as a small, open way to represent knowledge as files that both people and agents can read.

The idea is intentionally plain: put knowledge in Markdown, add a little YAML frontmatter so tools know what each page is, and organize the pages in a directory tree. In OKF terms, that tree is a Knowledge Bundle. Each normal Markdown file is a Concept, and its path becomes its Concept ID.

The bundle structure carries some meaning of its own. Directories group related concepts. An index.md can sit at the root or inside a directory to show what is available there before a reader opens every file. A log.md can sit at the same levels to record date-grouped updates for that part of the bundle. Concepts can also link to each other with ordinary Markdown links, so the bundle can be browsed as a tree and traversed as a lightweight graph.

The spec uses a minimal bundle like this:

my_bundle/
  index.md
  datasets/
    index.md
    sales.md
  tables/
    index.md
    orders.md
    customers.md

A concept page then starts with frontmatter. For example, the spec's tables/orders.md page begins like this:

---
type: BigQuery Table
title: "Orders"
description: "One row per completed customer order."
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders]
timestamp: 2026-05-28T00:00:00Z
---

After that, the body is just Markdown: schema notes, links to related concepts, citations, or whatever context the page needs. That is enough structure for a tool to route, preview, search, and preserve knowledge, without turning the knowledge into a proprietary database dump.

When we read the spec, it felt less like a new direction than a name for something ClawMem had already been building toward.

ClawMem Had Been Building Toward the Same Model

ClawMem is a memory system for agents and teams. It helps them keep long-running project knowledge outside a single chat, task, or agent session, then turn that knowledge into context future agents can reuse.

To make that work, ClawMem separates memory into two layers.

Issues are where atomic memory lives. They are the source records: decisions, preferences, observations, lessons learned, tasks, and the small facts that accumulate while agents and teammates work. If you need to know where a claim came from, the issue is where you trace it back.

The wiki is where context lives. A wiki page is not just another saved message. It is where related memories get compiled into something reusable: a project summary, a workflow, a release process, a decision record, a customer context page, a set of onboarding notes. The page is the thing a future agent should read first, before it starts reconstructing the same answer from scattered fragments.

Under the hood, ClawMem runs on AGS, a GitHub-compatible backend. That gives us a familiar foundation for Markdown, history, and repository-shaped knowledge. But a GitHub-compatible knowledge base is only the starting point. Agent memory needs more than a place to put files; it needs a way for agents to find the right context, understand how pages relate, group knowledge by topic, search by meaning, and trace a summary back to the atomic memories that support it.

So ClawMem extends that AGS foundation with the pieces agent memory needs in practice: a structured wiki tree, wiki labels, TiDB-powered search across wiki pages, page history, links between pages, and references back to the issue memories underneath. The result still feels like a wiki, but it is a wiki built for agents to maintain and teams to inspect.

That is why OKF felt familiar rather than foreign. It describes knowledge as a navigable Markdown corpus, and that is already how ClawMem's wiki behaves.

In OKF, the directory tree is not just a storage layout; it is one of the ways knowledge gets organized. ClawMem's structured wiki tree plays the same role. A project page, workflow page, or decision page has a path, sits inside a section, and can be discovered without loading the entire repository. OKF's index.md gives a directory an entry point for progressive disclosure; ClawMem provides the same orientation through the wiki tree itself, where agents and teammates can browse a section and see the pages it contains before opening them. Because those wiki pages are also indexed in the database, ClawMem can go beyond browsing and support full-text search and vector search across the wiki.

The same pattern shows up in metadata and change history. OKF uses tags for cross-cutting categorization; ClawMem uses wiki labels. OKF can include a scoped log.md so updates remain readable over time; ClawMem already keeps page history that can be summarized into that kind of update trail. OKF links concepts with Markdown links; ClawMem links wiki pages to each other and keeps references back to the issue memories that support the compiled page.

So the alignment is not just that both sides use Markdown. OKF's bundle structure gives a portable form to the same kind of organized, linkable, traceable context that ClawMem had already been building in its wiki.

What Changes With OKF Support

Once OKF appeared, supporting it was the obvious next step. Not because ClawMem needed to become something new, but because the format matched the wiki model ClawMem had already built.

Before OKF support, ClawMem wiki knowledge was already reusable inside ClawMem. A page written by one ClawMem-aware agent could be read by another, whether the team was working with Claude Code, Codex, Hermes, or another agent connected through the same memory layer. Teams could maintain project pages, workflow pages, decisions, and source-backed summaries in one shared memory wiki.

After OKF support, the boundary changes. The same wiki layer now has a standard exchange shape. Knowledge from other OKF-producing tools can come into ClawMem as wiki context, and ClawMem knowledge can leave as an OKF bundle for another catalog, wiki, Git workflow, agent, or retrieval system to consume. The point is not just export; it is that ClawMem now participates in an emerging protocol for portable knowledge instead of asking every outside tool to understand a ClawMem-specific format.

That shows up in the product in three places.

Writing. OKF becomes part of the write path. For agents that understand ClawMem and write to the wiki through ClawMem's normal wiki path, including writes through the ClawMem plugin, new or updated pages now use an OKF-compatible shape by default: Markdown body, YAML frontmatter with a type, title and description where useful, tags, timestamps, related links, resource fields, citations, and ClawMem-specific source metadata. Console recognizes that shape, renders the page as a normal wiki page, and keeps the OKF metadata visible when you want to inspect it.

Importing. OKF can come in. Bring in an OKF-style Markdown file or bundle, and ClawMem can turn it into wiki knowledge without flattening it into a generic note. Files become pages. Folders become the wiki tree. Tags become labels. Frontmatter stays with the page, while the Markdown body renders as the page itself. Console can mark the page as OKF, show the metadata in a frontmatter panel, and still let the page read like any other wiki page.

Exporting. ClawMem knowledge can go out. Any wiki repository in Console can leave as an OKF bundle, whether the pages originally started as OKF or not. Pages that already have OKF frontmatter pass through naturally. Existing ClawMem wiki pages are converted during export: the tree becomes folders, labels become tags, internal wiki links become bundle-relative Markdown links, history becomes optional log.md context, and source metadata is preserved in producer-defined fields so the exported page still knows where it came from.

Open a wiki repository in Console, export it, and you get a ZIP of Markdown files that stands on its own:

clawmem-wiki-okf.zip
  index.md
  log.md
  projects/
    clawmem.md
  workflows/
    release-process.md
  topics/
    agent-memory.md

Inside are links, tags, a generated index, optional log context, and source metadata that traces where each page came from. Open it without ClawMem and it still reads like knowledge. Put it in a Git repo, hand it to another agent, feed it into another OKF consumer, or keep it as an archive your team can inspect later.

Raw conversation logs still matter for audit and provenance, but they are rarely the best handoff format. The wiki layer is the part teams actually reuse: workflows, project state, decisions, explanations, and the pages a future agent should read first. OKF gives that layer a shape that travels, and the bigger benefit is ecosystem leverage: as more tools learn to produce or consume OKF, ClawMem knowledge can meet them through the same standard interface.

Try It

If you already use ClawMem, OKF export is available from wiki repositories in Console, and new wiki pages can be written in OKF-compatible form by default. You can also import OKF-style knowledge and keep improving it inside the same wiki workflow.

As agents maintain project pages, workflow pages, and decision pages, that knowledge can now be read inside ClawMem and carried outside it as a standard OKF bundle.

Comparing AI Agent Memory Systems: Mem0, Zep, Letta, and ClawMem

ClawMem — Thu, 04 Jun 2026 09:03:24 +0000

Why does memory still matter in 2026? The question is no longer whether agents should have memory. They should.

But as teams deploy more agents across more workflows, memory stops being a single-assistant recall feature. It becomes a coordination problem, a correctness problem, and eventually an infrastructure problem across a wider team of agents and humans.

The problem memory systems actually need to solve

Imagine three agents helping a software company run customer operations: a support agent, a deployment agent, and an ops agent.

The support agent learns a rule after an escalation:

Singapore enterprise tenants can only receive schema changes during weekend maintenance windows, and approvals route to Mika.

Two weeks later, the deployment agent is preparing a rollout. It needs to know which accounts require special maintenance windows, but this rule lives only in the support agent’s memory. It does not know to ask.

At almost the same time, the ops team updates the approver from Mika to Ren, and folds this policy into a broader internal category for restricted deployment accounts.

Now the memory problem has three layers:

The deployment agent is missing a rule it needs.
The support agent holds a version of the rule that is already stale.
If a human updated the policy yesterday, how does any agent know?

The hard question is not whether the model can remember. It is whether agents and humans can collaborate on work from the same up-to-date memory surface, and keep it synchronized as knowledge evolves.

How to pick a system

Different teams have different starting points. The table below maps the most common needs to the strongest fit.

Need	Recommended System	Why
Simple durable memory in one OpenClaw workspace	OpenClaw native memory	File-based, readable, no extra infrastructure.
Shared team knowledge that grows beyond a single agent	ClawMem	Persistence, evolution, shared visibility, and multi-agent collaboration.
Reflection-driven learning and recall	Hindsight	Clean retain → recall → reflect model.
User preference and identity memory	mem0	Strong user, app, and assistant memory scopes.
Stateful agent runtime memory	Letta	Memory is embedded into the runtime itself.
Time-aware fact tracking	Zep / Graphiti	Designed around temporal knowledge.
Quick multi-agent shared memory	Mem9	Simple shared-memory service for multiple agents.
Knowledge graph + vector foundation	Cognee	More like a reusable knowledge engine.
Hosted profiles and RAG memory	Supermemory	Low-friction managed context layer.
Experimental memory operating system	MemOS	Broad vision, still early-stage.

What the comparison actually measures

Retrieval benchmarks miss most of what teams actually care about in production. The practical questions are:

Can this remember the right thing when it is needed?
Can we correct it when it is wrong or stale?
Can multiple agents and humans share it safely?
Can people see what agents have learned and act on it?
How hard is it to move if our stack changes?
The profiles below address each system on those dimensions.

System profiles

OpenClaw native memory

Best for: a single OpenClaw agent that needs durable, readable memory without added infrastructure.

Memory is stored as local files, searchable via hybrid retrieval. The dreaming mechanism promotes and consolidates memories over time, which means memory improves rather than just accumulates. Highly portable as plain files, though tightly coupled to OpenClaw. Limited native support for sharing across agents or making memory visible to humans outside the workspace.

Start here if you want the lowest-friction path to durable single-agent memory.

Trade-off: limited native support for sharing memory across multiple agents or making it visible to a broader team outside the workspace.

ClawMem

Best for: teams that want one memory system that can begin with a single agent and later grow into structured, shared knowledge across agents and humans.

Memory is structured with labels (type, kind, topic) that are part of the durable schema, not cosmetic metadata. This matters for three reasons: it improves recall precision, it gives humans a browsable structure for auditing and cleanup, and it gives the system a clean foundation for updating and retiring stale facts rather than letting them pile up.

The workflow itself (mirrored conversations, candidate extraction, reconcile, update-in-place, stale retirement, and dedup) is what prevents the scenario described above from becoming a real problem. When the approver changes from Mika to Ren, a reconcile pass can find and update every version of that fact across agents, rather than letting three agents diverge silently.

Shared memory is native, not bolted on. One agent can start using ClawMem today; the same memory surface can later be shared with other agents and humans without switching to a different model. The Console graph makes memories and their connections visible to the team.

Trade-off: medium host coupling today, which limits portability compared to fully file-based or cloud-agnostic approaches.

mem0

Best for: user preference memory and assistant continuity across products and sessions.

mem0 provides well-scoped memory primitives at the user, agent, app, and run levels. Managed updates and expiration handle the lifecycle. It is a strong fit when the goal is helping assistants remember who they are talking to and what that person prefers.

Compared with ClawMem or Hindsight, it starts from personalization rather than shared institutional knowledge.

Trade-off: less naturally suited to team-level or cross-agent knowledge sharing.

Hindsight

Best for: reflection-heavy institutional memory where retrieval quality is the central concern.

Hindsight organizes memory around a retain -> recall -> reflect loop, with multi-strategy retrieval and learned recall improving over time. It is strongest when the main problem is surfacing the right knowledge at the right moment and improving through reflection.

That makes it a compelling answer for learned recall, but a different answer from systems that treat memory as a shared workspace.

Trade-off: less centered on coordinating knowledge across agents or making memory visible to humans in day-to-day collaboration.

Letta

Best for: stateful agents where memory is part of the agent runtime itself, not a separate service.

Memory lives inside the agent model as a runtime-managed hierarchy. Updates and persistence are handled at the runtime layer, and the runtime UI makes memory state inspectable. This is compelling if your architecture philosophy is that agents should own their own state.

Compared with mem0, it is less about user continuity and more about persistent agent state.

Trade-off: more constrained if you need memory to be portable or shared across independent agents and teams.

Zep / Graphiti

Graph-based storage with time-aware updates and invalidation makes these systems especially strong when the central problem is facts that expire, conflict, or depend on when they are true. In the scenario above, knowing when a policy changed and which version was valid at a given time is exactly the kind of problem Zep and Graphiti handle well.

Compared with Letta, the emphasis is less on runtime-managed state and more on time-aware knowledge.

Trade-off: less focused on human visibility or cross-team collaboration, and graph-heavy approaches can add more machinery than many teams need.

Mem9

Best for: getting multiple agents onto a shared memory pool quickly.

Mem9 is a shared-memory service built for multi-agent access by design. An admin surface provides visibility, and the pool handles concurrent reads and writes. The strongest choice when the immediate need is coordination across agents rather than evolution of memory over time.

Trade-off: a shared pool does not automatically give you the same long-term structure, cleanup discipline, or memory maintenance surface as more explicitly organized systems.

Cognee

Best for: teams that want a broader knowledge engine under their memory workflows.

Cognee combines graph and vector retrieval in a loop that supports remember, recall, forget, and improve. It feels more like a reusable knowledge layer than a narrow memory add-on, which is useful when memory is only one part of a larger knowledge-management architecture.

Trade-off: can feel heavier than what teams want if they are just looking for a practical memory workspace.

Supermemory

Best for: teams that prioritize speed of integration over customization.

Supermemory is a hosted context layer with profiles, connectors, and RAG in one package. Managed by the platform, with a dashboard for visibility, its main advantage is low adoption friction.

Trade-off: vendor pricing and a more vendor-shaped product surface are the trade-offs for that convenience.

MemOS

Best for: teams doing research-oriented work on memory as a systems abstraction.

MemOS frames memory as an operating-system-like layer, with shared cubes, feedback-driven refinement, and cross-layer scope. It expands the vocabulary of what memory systems can aspire to, which makes it worth watching even if it is not the default production choice yet.

Trade-off: still more research-oriented than most teams want for a straightforward production memory decision.

Full comparison

System	Primary Fit	Memory Scope	Update & Evolution	Visualization	Collaboration	Portability
OpenClaw Native	Single-agent continuity	One agent, one workspace	Dreaming-based consolidation	Readable local files	Limited	High (files), OpenClaw-coupled
ClawMem	Single-to-team memory growth	Single agent → multi-agent → multi-team	In-place updates, retire, reconcile, dedup	Console graph	Native shared spaces, access control	Portable surface, medium host coupling
Hindsight	Reflection-heavy institutional memory	Personal + institutional	Retain, recall, reflect	Limited	Indirect	Good
mem0	Personalization memory	User, agent, app, run	Managed updates, expiration	Limited	App-layer	Good
Letta	Runtime-native agent memory	Agent-state centric	Runtime-managed	Runtime UI	Via runtime orchestration	Runtime-shaped
Zep / Graphiti	Temporal knowledge	Evolving factual knowledge	Time-aware invalidation	Graph view	Indirect	Good, graph-heavy
Mem9	Shared multi-agent memory pool	Multiple agents	Server-side pool updates	Admin surface	Native shared pool	Moderate
Cognee	Graph + vector knowledge engine	Broad institutional	Remember, recall, forget, improve	Limited	Indirect	Good
Supermemory	Hosted context layer	Personal + product context	Managed by platform	Dashboard	Indirect	Moderate
MemOS	Research memory OS model	Broad, cross-layer	Feedback-driven refinement	Research-oriented	Shared cubes	Experimental

Where ClawMem stands apart

After comparing the field, ClawMem’s difference is not simply that it also has long-term memory. The more meaningful difference is how it connects persistent memory, memory evolution, shared visibility, and collaboration on one durable surface.

It works for one agent, and keeps working when memory becomes shared

Many systems feel strongest either at single-agent memory or at shared memory. ClawMem is stronger across both stages.

For a single agent, it already supports structured durable memory that can evolve over time instead of turning into a pile of disconnected notes. But that same memory model does not break once more agents or humans enter the loop. The same durable surface can support self-improving memory for one agent, multi-agent coordination, and broader team collaboration without forcing a switch to a separate system.

The label mechanism gives memory visible structure

One of ClawMem’s most important design choices is its label-first structure.

In ClawMem, labels are not cosmetic metadata. They are part of the durable memory schema. A memory is not just a text blob. It can carry visible structures such as:

type: memory
kind:*
topic:*
That matters because labels help in three ways:
better recall precision, because memory can be narrowed by kind, topic, and durable surface
better organization, because humans can browse and clean up memory using the same visible structure
better evolution, because when facts change, the system has a cleaner structure for updating, merging, and retiring stale memory
That makes memory feel less like accumulated residue and more like maintainable knowledge.

Team sharing and collaboration feel native

ClawMem treats shared memory as a native part of the memory system, not a manual handoff between assistants. A memory space can stay private to one agent, be shared with a specific agent team or project group, or become an organization-level space used across teams.

The hierarchy is explicit. Organizations define the top-level collaboration boundary. Teams are the practical sharing unit inside that boundary. Members and agents can then be given the right level of access to each memory space, with clear read, write, or admin permissions and visible invitation states, so one space can stay team-only while another can be shared more broadly across the organization.

That makes sharing across agents, teams, and organizations feel native. A support agent can capture a customer pattern once, a research agent can extend it later, and an operations agent can reuse the same durable memory space instead of recreating the same knowledge in separate workflows. The result is a clearer collaboration model where private memory, team memory, and organization memory can coexist.

Final take

OpenClaw native memory already makes single-agent memory real. Dreaming makes it better. Any honest comparison should start there.

But as agent usage deepens, teams increasingly have more agents doing more work. At that point, memory stops being only about whether one assistant can remember. It becomes about whether memory can stay structured, visible, shareable, and up to date across a larger workflow.

ClawMem helps memory stay structured, shared, and evolving as it grows from one agent into team knowledge.