Caura

Fleet memory for AI agents — governed, shared, self-improving.

MemClaw is becoming Caura — same product, one name. Tool names (memclaw_*), packages, env vars and URLs keep working unchanged.

Quick Start · Features · Performance · MCP · API Reference · Plugin Docs · Contributing · Discord

---

Caura (formerly MemClaw) — the shared governed memory layer for AI agent fleets

Caura — known until now as MemClaw — is open-source memory for multi-tenant, multi-agent AI fleets. Your agents store what they learn, find what the fleet knows, and get smarter with every interaction — learning from each other instead of repeating mistakes.

Agents write plain text. Caura turns it into searchable, governed, self-improving memory.

One loop, three pillars: write, recall, compound — every interaction makes the next one smarter.

Built for fleets, not single agents. Public agent-memory benchmarks (LoCoMo, LongMemEval) measure one agent, one user, one long conversation — the single-chatbot shape. The deployment shape we see in production is the opposite: dozens or thousands of agents working on behalf of a company, sharing what they learn under governance. Caura is architected around that shape from day one — scoped memory, cross-agent outcome propagation, fleet-wide trust tiers — and competes on the axes that compound with agent count: latency, token efficiency, and governance. See [Performance](#performance) for the numbers, or read the benchmarks write-up.

> In production at eToro (NASDAQ: ETOR): 300+ AI agents on one governed > memory — 26,500+ memories, 1,372 shared skills, 23 ms p50 search. > Architecture deep-dive →

---

Quick Start

Try it locally — no API key, no signup

The fastest way to see Caura work. Standalone mode runs single-tenant with auth bypassed — write and recall a memory in four commands. (It boots with dummy embeddings so there's nothing to configure; add an AI provider key for semantic search — see [Self-Hosted](#self-hosted-open-source) below.)

git clone https://github.com/caura-ai/caura.git
cd caura-memclaw
cp .env.example .env && echo "IS_STANDALONE=true" >> .env   # single-tenant, no API key
docker compose up -d                                        # Postgres + pgvector + Redis + API (~30s)

# Write a memory — no API key needed
curl -X POST http://localhost:8000/api/v1/memories \
  -H "X-API-Key: standalone" -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "content": "Our auth service uses JWT with 15-minute expiry."}'

# Search for it
curl -X POST http://localhost:8000/api/v1/search \
  -H "X-API-Key: standalone" -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "query": "authentication token lifetime"}'

The write response comes back enriched with an LLM-inferred memory_type, title, summary, tags, status, and weight — all from a single content field.

Ready for semantic recall, multi-tenant, a managed host, or an OpenClaw fleet? Pick a path below.

---

Three paths — pick the one that matches your setup:

| Path | When | Time to first memory | |---|---|---| | Managed platform | Quickest. We host the DB + scaling. | ~2 min | | Self-hosted (Docker) | Privacy / on-prem / air-gapped. | ~5 min | | OpenClaw plugin | You already run an OpenClaw fleet — install Caura as a plugin against any of the above. | ~3 min |

Managed Platform

Get up and running in minutes — no infrastructure, automatic updates, usage analytics, and enterprise-grade security included.

1. Sign up free on memclaw.net
2. Grab your API key from the dashboard
3. Connect via MCP or REST:

{
  "mcpServers": {
    "memclaw": {
      "url": "https://memclaw.net/mcp",
      "headers": { "X-API-Key": "mc_your_api_key_here" }
    }
  }
}

> Production / team use: the quickstart key above is a tenant-scoped credential — fine for personal use, but a fleet of agents should bind each one to its own agent-scoped credential for trust gating, fleet membership, and per-agent keystones. Provision agent-scoped credentials atomically via [POST /api/v1/admin/agent-keys/provision](docs/integration-without-plugin.md), or through the dashboard at /settings/organization/api-credentials. Both kinds use the mc_ prefix on the wire — scope is bound at mint time on the credential itself. The MCP server accepts the credential on either X-API-Key: mc_… or Authorization: Bearer mc_…. (Pre-existing mca_… and mci_… keys continue to authenticate via back-compat.) > > Using a tenant-scoped credential? Pass an explicit agent_id on every MCP tool call — the gateway refuses the reserved default (mcp-agent) on the tenant-scoped path.

Self-Hosted (Open Source)

The fastest path is Docker Compose — one command brings up Postgres + pgvector + Redis + the API.

> Prefer not to use Docker? Skip to [Manual deployment (Python + Postgres)](#manual-deployment) below for the bare-Python path. > > No cloud API key, no external calls? v2.0+ supports a self-hosted local embedder (BAAI/bge-m3 via HuggingFace TEI) — see [docs/local-embedder.md](docs/local-embedder.md). The setup below walks through the OpenAI default; the local-embedder doc walks through the alternative.

Prerequisites

• Docker Engine 24+ (Linux) or Docker Desktop (macOS / Windows). Confirm with docker --version.
• Docker Compose v2 (built into modern Docker). Confirm with docker compose version.
• Git for cloning.
• ~2 GB free disk for images + Postgres data volume.

1. Clone and configure

git clone https://github.com/caura-ai/caura.git
cd caura-memclaw
cp .env.example .env

Set your AI provider in .env — minimal setup with OpenAI:

EMBEDDING_PROVIDER=openai
ENTITY_EXTRACTION_PROVIDER=openai
USE_LLM_FOR_MEMORY_CREATION=true
OPENAI_API_KEY=sk-...

> Without any AI keys the stack still starts — dummy providers return non-semantic embeddings, useful for testing the API surface.

> 💡 Want zero cloud API calls? v2.0+ ships a self-hosted embedder > profile (BAAI/bge-m3 on a HuggingFace TEI > sidecar). Bring up the stack with docker compose --profile embed-local up -d > and set the four OPENAI_EMBEDDING_* envs from .env.example — see > [docs/local-embedder.md](docs/local-embedder.md) for the full setup. > Combined with IS_STANDALONE=true (below) this is a fully self-contained > deployment with no external API calls.

Other providers (Gemini, Anthropic, OpenRouter, self-hosted)

| Provider | .env settings | Required key | |---|---|---| | OpenAI (default) | EMBEDDING_PROVIDER=openaiENTITY_EXTRACTION_PROVIDER=openai | OPENAI_API_KEY | | Google Gemini | EMBEDDING_PROVIDER=openaiENTITY_EXTRACTION_PROVIDER=gemini | GEMINI_API_KEY + OPENAI_API_KEY | | Anthropic | EMBEDDING_PROVIDER=openaiENTITY_EXTRACTION_PROVIDER=anthropic | ANTHROPIC_API_KEY + OPENAI_API_KEY | | OpenRouter | EMBEDDING_PROVIDER=openaiENTITY_EXTRACTION_PROVIDER=openrouter | OPENROUTER_API_KEY + OPENAI_API_KEY | | Self-hosted (TEI / bge-m3) | --profile embed-local + OPENAI_EMBEDDING_BASE_URL=http://tei:80/v1+ OPENAI_EMBEDDING_MODEL=BAAI/bge-m3+ OPENAI_EMBEDDING_SEND_DIMENSIONS=false | none — runs locally |

Anthropic, Gemini, and OpenRouter don't offer embedding APIs here — pair them with OpenAI (or with TEI) for embeddings. You can mix providers freely. Gemini uses the Google AI Studio key-auth Developer API (no GCP project/ADC required). The self-hosted TEI row keeps EMBEDDING_PROVIDER=openai because TEI speaks the same OpenAI-compatible API; see [docs/local-embedder.md](docs/local-embedder.md) for hardware sizing, GPU setup, and model swapping.

2. Start the stack

docker compose up -d

By default this pulls the multi-arch images from ghcr.io (linux/amd64 + linux/arm64) on first run — takes ~30 seconds. Subsequent up commands re-use the cached image (no registry round-trip, works offline). To pin a specific version, set MEMCLAW_VERSION=v1.2.3 in your .env. To build from local source instead (e.g. when iterating on a fork), run docker compose up --build --no-pull.

To upgrade to a newer image at the same tag (e.g. :latest after we cut a new release), run docker compose pull && docker compose up -d. Without an explicit pull, the local cache wins — there's no silent version drift.

> Offline / air-gapped operation: depending on whether the image is already cached locally: > - Image cached, no network: docker compose up -d works as-is — pull_policy: missing doesn't try to pull when the image is present. Use docker compose up --no-pull if you want to be explicit. > - No local image, no network: docker compose up --build --no-pull (build from source, don't try to pull). > - Strict no-network guarantee (e.g. an air-gapped pipeline that should never reach ghcr.io): drop a docker-compose.override.yml setting pull_policy: never for both services — Compose then fails fast if the image is absent rather than attempting a pull.

| Service | URL | |---|---| | Core API (REST + MCP) | http://localhost:8000 | | Core Storage API | http://localhost:8002 | | PostgreSQL (pgvector) | localhost:5432 | | Redis | localhost:6379 |

What the stack contains — and what it doesn't

docker compose up starts exactly four containers:

| Container | Role | |---|---| | db | PostgreSQL 16 + pgvector | | redis | Cache and rate limiting | | core-storage-api | Storage service (SQL + vector search) | | core-api | REST + MCP surface; embedding and enrichment run in-process (deployment_mode=inline, the default) |

A fifth service, tei (the local embedder), is defined in the compose file but only starts with --profile embed-local. Components you may see referenced elsewhere in this repo — core-worker, the platform-tier services, the Google Pub/Sub event bus — run only in managed/enterprise deployments. The OSS stack uses the in-process event bus, and inline mode embeds and enriches inside core-api itself, so no worker service is needed.

3. Verify

curl http://localhost:8000/api/v1/health
# {"status":"ok","storage":"connected","redis":"connected","event_bus":"ok"}

4. Write and search

# Write a memory (standalone mode — no API key needed)
curl -X POST http://localhost:8000/api/v1/memories \
  -H "X-API-Key: standalone" \
  -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "content": "Our auth service uses JWT with 15-minute expiry."}'

# Search for it
curl -X POST http://localhost:8000/api/v1/search \
  -H "X-API-Key: standalone" \
  -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "query": "authentication token lifetime"}'

The write response carries an LLM-inferred memory_type, title, summary, tags, status, and a weight (the importance score) — all derived from a single content field. On the default fast-write path, enrichment is applied asynchronously: the immediate response is marked enrichment_pending and the inferred fields populate within moments.

POST /search returns matches under an items array, each entry the full memory plus a similarity score:

{
  "items": [
    {
      "id": "…",
      "agent_id": "mcp-agent",
      "memory_type": "fact",
      "title": "Auth service uses JWT with 15-minute expiry",
      "similarity": 0.47,
      "visibility": "scope_team",
      "status": "active"
    }
  ]
}

Embedding is asynchronous too, so a just-written memory may not surface in semantic search right after the write returns. The write response says so: metadata.embedding_pending: true means the row was stored without an embedding and a background backfill is scheduled. Until it lands the memory is already reachable by keyword and in the non-semantic GET /memories list — it just doesn't compete on semantic similarity yet. Budget ~15–20s in production; a slower backfill (staging, or a saturated worker) can take minutes, so treat the flag as the signal rather than assuming a fixed delay.

If a caller has to search for what it just wrote, pass write_mode: "strong" on the write. That embeds inline — the response comes back with no embedding_pending and the memory is immediately searchable. The trade is an embedding provider call on the request path, which is precisely what fast mode's sub-2s p99 visibility target exists to avoid, so it's worth choosing per write rather than switching on globally. (A deployment configured to embed inline, the default for a local OSS install, never sets the flag at all.)

---

⭐ If Caura just worked for you, star the repo — it's how other fleet builders find us, and it shapes how much time we can invest in the OSS edition.

---

Auth modes

OSS supports three auth paths. Pick one and add it to your .env, then docker compose up -d to restart.

Standalone — single-tenant (tenant_id="default"), simplest for local / self-install:

IS_STANDALONE=true

No API key required for REST. MCP still expects a non-empty X-API-Key header — any value works.

> Pair Standalone mode with --profile embed-local (see [docs/local-embedder.md](docs/local-embedder.md)) for a fully self-contained deployment: no admin keys, no external API calls, all embeddings computed locally. Useful for offline / air-gapped environments and personal-laptop installs.

Admin key — multi-tenant with full access:

ADMIN_API_KEY=your-long-random-admin-key

Pass X-API-Key: your-long-random-admin-key and include tenant_id in request bodies / query params.

Shared gate — for network-exposed OSS deployments:

MEMCLAW_API_KEY=your-shared-key

Clients send X-API-Key: your-shared-key plus X-Tenant-ID: .

> See [AGENT-INSTALL.md](AGENT-INSTALL.md) for the full agent self-install walkthrough.

Running tests

# Unit tests (no DB needed)
pytest tests/ -m "unit"

# All tests (requires PostgreSQL)
docker compose up -d db
pytest tests/ -m "not benchmark"

# Smoke test against live API (~30s, auto-cleanup)
python scripts/smoke_test.py --url http://localhost:8000 --api-key 

OpenClaw Plugin

Already running an OpenClaw fleet? Install Caura as a plugin against either the managed platform or your self-hosted stack:

# Point at whichever URL hosts your Caura API
export MEMCLAW_URL=https://memclaw.net          # managed
# or:  export MEMCLAW_URL=http://localhost:8000  # self-hosted
export MEMCLAW_KEY=your-key                      # `standalone` works in self-hosted standalone mode
export MEMCLAW_FLEET=my-fleet

curl -sf -H "X-API-Key: $MEMCLAW_KEY" \
  "$MEMCLAW_URL/api/v1/install-plugin?fleet_id=$MEMCLAW_FLEET&api_url=$MEMCLAW_URL" | bash

# Restart the gateway to load the plugin
openclaw gateway restart

The plugin claims the OpenClaw memory slot (replacing memory-core) and exposes the same 12 MCP tools. Full setup, agent prompts, and trust levels: [static/docs/integration-guide.md](static/docs/integration-guide.md).

Python client

Talk to any Caura deployment (managed or self-hosted) from Python:

pip install memclaw-client

from memclaw_client import Caura

mc = Caura("mc_xxx", tenant_id="my-team", agent_id="my-agent")
mc.write("Q3 revenue target is $4M, set on 2026-04-15.")
print(mc.recall("Q3 revenue target").summary)

A thin wrapper over the REST API — see [clients/python/](clients/python/) for the full client.

TypeScript client

Same, from TypeScript / JavaScript (Node 18+, zero dependencies):

npm

…

## Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [caura-ai](https://github.com/caura-ai)
- **Source:** [caura-ai/caura](https://github.com/caura-ai/caura)
- **License:** Apache-2.0
- **Homepage:** https://memclaw.net

Install and usage instructions live in the source repository linked above.