Caura-MemClaw is Open Source.
Governed shared memory for agent fleets, yours to run.

Today we’re releasing the entire Caura-MemClaw engine under Apache 2.0, on GitHub at caura-ai/caura-memclaw. Not a thin client SDK with the interesting bits behind a paywall — the whole thing. The storage layer, the search path, the contradiction detector, the supersession chain, the audit trail, the twelve MCP tools, the OpenClaw plugin, the schema migrations, the tests. The same code we run in production behind memclaw.net.

If you’ve been waiting to read it, fork it, run it on-prem, run it air-gapped, or pull it apart to build something stranger — the door is open.

Why open-source the whole engine?

Governed memory is infrastructure. It sits between your agents, your customers’ data, and your model providers. When the agent writes “Acme moved to monthly billing as of April,” that fact propagates through searches your fleet runs for weeks. When the contradiction detector marks an older row outdated, that’s a decision — one that changes what every other agent sees next.

You can’t responsibly run that on a black box. Three things forced this:

• Reading the code is the only way to trust it. Compliance teams, security teams, and platform engineers all asked the same question: show me what gets written, what gets indexed, and who can read what. The answer to that question is never “trust us.” It’s a repository.
• On-prem was already a first-class deployment target. Air-gapped customers were running Caura-MemClaw inside their VPCs from day one. Shipping a tarball with a license check was a thin pretense over what they actually needed: the source.
• The hard problems deserve to be inspected. Hybrid retrieval, multi-tenant isolation, the entity graph that gets extracted on every write, the trust-level model, the temporal resolution rules. We spent a year getting these right. The shape we’d defend in a review is the shape that’s now in the repo.

We also think this category — governed shared memory for multi-agent fleets — gets bigger when more people can build on it, not when one company owns the only implementation. Single-agent memory is a solved space with a dozen good vendors. Fleet memory is the lane that’s still being defined, and defining it is more interesting than fencing it.

What’s in the box

The repository is one cohesive stack, organised as four services and one plugin:

On top of those services, you get the twelve MCP tools that make the engine usable from Claude Code, Cursor, Codex, and any other MCP host:

memclaw_write       memclaw_recall      memclaw_list
memclaw_manage      memclaw_doc         memclaw_entity_get
memclaw_tune        memclaw_insights    memclaw_evolve
memclaw_stats       memclaw_keystones   memclaw_keystones_set

Skill sharing rides on the same surface — memclaw_doc op=write collection="skills" replaces what used to be two dedicated tools. One primitive, every structured record. (More on that in Memory Isn’t Records.)

Plus the data plane: PostgreSQL with pgvector for hybrid search, Redis for hot-path caching, and an optional self-hosted embedder profile (TEI + BAAI/bge-m3) so a hardened deployment can run with zero outbound API calls.

Five minutes to a running stack

Clone, configure, and bring it up. The default Docker Compose pulls multi-arch images from ghcr.io on first run; everything after that is local.

# 1. Clone
git clone https://github.com/caura-ai/caura-memclaw.git
cd caura-memclaw

# 2. Pick an embedding/LLM provider (or use the dummy provider for smoke tests)
cp .env.example .env
# minimal: set OPENAI_API_KEY in .env

# 3. Bring it up
docker compose up -d

# 4. Verify
curl http://localhost:8000/api/v1/health
# {"status":"ok","database":"connected",...}

Want to write your first memory immediately, no API key, no signup? The OSS stack starts in standalone mode by default:

# Write a memory
curl -X POST http://localhost:8000/api/v1/memories \
  -H "Content-Type: application/json" \
  -d '{"content":"The platform team uses ADRs in /docs/adr"}'

# Recall by meaning
curl -X POST http://localhost:8000/api/v1/memories/recall \
  -H "Content-Type: application/json" \
  -d '{"query":"where do we document architecture decisions?"}'

Or skip the curl and point Claude Code, Cursor, or Codex at the local MCP endpoint — the MCP section in the README has a one-liner skill installer that wires up an agent in under a minute.

Want zero cloud calls?

Bring up the stack with the local-embedder profile and Caura-MemClaw will never reach out to OpenAI, Anthropic, Gemini, or anyone else:

docker compose --profile embed-local up -d

Combined with IS_STANDALONE=true and the dummy extraction provider, the entire stack is fully self-contained — suitable for regulated, on-prem, or air-gapped deployments.

OSS vs. hosted — what’s the difference?

Honest split. The OSS engine is everything you need to run governed shared memory for one organisation:

• The full memory pipeline (write, recall, list, manage, contradiction, supersession, decay).
• The 12 MCP tools and the REST surface.
• Multi-agent and fleet-scoped isolation inside that organisation.
• Trust levels (restricted, standard, cross_fleet, admin) and per-agent / per-fleet visibility.
• The audit trail, the entity graph, the structured-document store (memclaw_doc).
• Apache 2.0. Fork it, embed it, run it, ship it.

The hosted product at memclaw.net is the same engine plus the platform layer that makes it multi-organisation: Auth0/SAML SSO, billing, the multi-tenant gateway, hosted upgrades, support, longer-retention audit. We run the database, we keep it patched, and we’re on the hook when something breaks at 3 AM.

If you’re an individual developer, a small team, or a regulated enterprise that wants the engine inside its own perimeter — self-host. If you want the engine without operating it — we’re here. Both run the same code.

What we’re building next, in public

A few of the things on the roadmap that are open for discussion in GitHub issues and on Discord right now:

• More LLM/embedding provider plugins. Local inference paths, Bedrock, Vertex, and provider-mixing strategies for cost-sensitive deployments.
• Additional storage backends. The current path is Postgres + pgvector; we want first-class adapters for AlloyDB and for managed pgvector services where the operational profile is different.
• Reproducible benchmark harness. The numbers from our LoCoMo / LongMemEval run belong in CI — one command to reproduce, one badge on the README.
• More skills. memclaw_doc collection="skills" turned skill sharing into a primitive (see Memory Isn’t Records). Now we want the catalog to be community-owned.

If any of these interest you, the contributing guide is at CONTRIBUTING.md and we hang out in Discord. Issues, design docs, code, and just kicking the tires on a fork are all welcome.

Where to start

1. Star the repo. github.com/caura-ai/caura-memclaw — helps the project, tells us what to invest in.
2. Run the quick start. docker compose up -d, write a memory, recall it. Five minutes.
3. Wire it into an agent. Claude Code, Cursor, and Codex all work today — the MCP skill installer is in the README.
4. Bring it on-prem. Multi-arch images, optional local embedder, no required outbound calls. The deployment section covers topology, image pinning, and air-gapped operation.
5. Open an issue or a PR. Roadmap, bugs, design questions — everything visible.

Caura-MemClaw started as the answer to a single question: what would it take for ten agents to learn from each other instead of repeating each other’s mistakes? The answer turned out to be a real piece of infrastructure — pipelines, governance, retrieval, audit, the full stack. That stack is now public.

Build something with it. Tell us what you broke.

Caura-MemClaw is built by Caura.ai — governed memory for the hyper-agent generation. Free tier on the hosted product, no credit card. Get started · GitHub · Discord.