# Caura: governed shared memory for AI agent fleets

> Caura (formerly MemClaw) is an Apache-2.0 memory layer for multi-tenant, multi-agent systems, exposed as MCP tools such as caura_write and caura_recall. It runs locally with docker compose, and its governance model is the part worth judging before adoption.

**caura-ai/caura** — Caura (formerly MemClaw) — governed shared memory for AI agent fleets. Multi-agent, multi-tenant, MCP-native. Trust tiers, keystone policies, audit trails, knowledge graph, self-improving retrieval. Apache 2.0.

- Repository: https://github.com/caura-ai/caura
- Website: https://caura.ai
- Stars: 543 · Forks: 89
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/caura-ai-caura

## The fleet problem Caura is built around

Most agent memory projects target one assistant serving one user across a long conversation. Caura targets the other shape: dozens or thousands of agents working for one organization, each learning something the others need. The README is explicit that public benchmarks such as LoCoMo and LongMemEval measure "one agent, one user, one long conversation," and that Caura instead optimizes for the axes that grow with agent count: latency, token efficiency, and governance.

That framing determines who the project is for. If two agents on the same platform team should not repeat each other's mistakes, the interesting question is not whether a vector search returns a similar sentence. It is who may read a memory, which agent wrote it, and whether a claim from a low-trust agent can be elevated into fleet knowledge. Caura answers those with tenant and fleet scoping, a trust ladder, and audit trails rather than with a better embedding index.

The repository describes production use at eToro, with the README stating 300+ agents, 26,500+ memories, 1,372 shared skills and 23 ms p50 search. Those are the project's own published numbers, not measurements made for this article, and the architecture write-up sits on the vendor blog rather than in the repository.

## Write, recall, compound: how the memory loop is wired

The mechanism is a three-step loop the README calls write, recall, compound. Agents write plain text. Caura derives structure from it: memory_type, title, status, weight, and a summary under metadata. With no AI provider configured, those fields come from a deterministic local heuristic over the content string. With a provider configured, they are model-inferred and metadata can also carry tags.

The storage stack is visible in the repository layout and compose file. Postgres runs the pgvector/pgvector:pg16 image, Redis 7 handles caching and can fall back to in-memory when unset, and the API is a FastAPI service. The top level splits into core-api, core-storage-api, core-worker, core-operations, common and clients, which tells you the write path is not a single process: a storage service owns PostgreSQL CRUD, a worker handles enrichment, and the API fronts both. Alembic migrations sit at alembic.ini, so schema changes are versioned rather than applied ad hoc.

Retrieval is scoped by fleet and visibility. A memory written with visibility scope_agent stays private to its author, scope_team shares it inside the fleet, and scope_org opens governed cross-fleet recall subject to the trust ladder documented in docs/integration-without-plugin.md. The README's two-agent example shows the practical effect: a deploy-agent records a rollback command, an incident-agent in the same fleet recalls it, and the result identifies deploy-agent as the author. Knowledge graph and self-improving retrieval are listed as capabilities, but the README excerpt does not spell out the graph schema, so treat that layer as documented elsewhere until you read the source.

## Running Caura locally with docker compose

The README's quick start is deliberately keyless. It clones the repository, copies the environment template, appends IS_STANDALONE=true for single-tenant operation with auth bypassed, and brings up Postgres, pgvector, Redis and the API. The compose file is expected to reach a healthy state in roughly thirty seconds, and it boots with dummy embeddings so nothing external is required.

```bash
git clone https://github.com/caura-ai/caura.git
cd caura
cp .env.example .env && echo "IS_STANDALONE=true" >> .env
docker compose up -d --wait
```

With the stack up, the first real use is a write followed by a search. Both calls go to the API on port 8000 and authenticate with the literal key standalone in standalone mode. The write uses write_mode strong, which is the path that produces the derived title, status and weight fields.

```bash
curl -X POST http://localhost:8000/api/v1/memories \
  -H "X-API-Key: standalone" -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "agent_id": "quickstart", "write_mode": "strong", "content": "Our auth service uses JWT with 15-minute expiry."}'

curl -X POST http://localhost:8000/api/v1/search \
  -H "X-API-Key: standalone" -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "query": "JWT expiry"}'
```

The README warns about one trap here: the keyless query reuses words from the memory, so it proves the pipeline works but not that semantic recall does. To exercise paraphrase matching, set a real provider in .env and query "authentication token lifetime" instead. Provider combinations are enumerated in .env.example: OpenAI for both embeddings and entity extraction, or Anthropic, Gemini or OpenRouter for extraction paired with OpenAI for embeddings, since those three do not offer embedding APIs here. Vertex AI is reserved for platform-tier deployments and is not a tenant-facing provider.

For an MCP client rather than curl, the write and recall calls take structured arguments. A deploy-agent writes with fleet_id, visibility and content; an incident-agent recalls with fleet_ids and a query.

```json
{
  "agent_id": "deploy-agent",
  "fleet_id": "platform",
  "visibility": "scope_team",
  "content": "Roll back auth-service with: deployctl rollback auth-service --to <version>."
}
```

## Where Caura is the wrong tool, and what it costs to run

The clearest limitation is stated by the project itself. Caura is optimized for fleets, and the governance machinery exists to serve that shape. For a single agent in a single conversation, you are paying for tenant scoping, trust tiers and audit trails that nothing in your system queries. A local vector store and a prompt template will be less code and fewer moving parts.

The operational surface is another constraint. A working deployment needs PostgreSQL with pgvector and Redis, and the compose file splits responsibilities across a storage API, a worker and the main API. The requirements.txt comments show how tightly the local-dev path is pinned: uvicorn is floored at 0.52.4 because common/serve.py passes timeout_worker_healthcheck to uvicorn.run(), a parameter that arrived in 0.37.0, and the file notes that container images do not resolve from it at all, installing frozen from each service's uv.lock instead. Two dependency paths that can drift is a real maintenance cost.

Standalone mode is convenient and unsafe by design. IS_STANDALONE=true runs single-tenant with auth bypassed and a fixed API key. The README presents it as the local try-it path and recommends agent-scoped credentials for production, which is the right split, but it means any deployment that forgets to flip the flag has no authentication in front of its memory.

Provider choice is a smaller trap. Anthropic, Gemini and OpenRouter cover entity extraction only, so semantic search still depends on an OpenAI key for embeddings. A team standardizing on one non-OpenAI vendor will end up with two provider relationships or with dummy embeddings and keyword-only recall.

## Caura against a plain pgvector retrieval service

The obvious alternative is what most teams build first: a table of embeddings in Postgres with pgvector, a retrieval endpoint, and a prompt that pastes the top matches into context. That approach shares Caura's storage substrate, which makes the comparison sharp. A hand-rolled pgvector service gives you similarity search and nothing else. It has no notion of which agent wrote a row, no visibility scope between teams, no trust level attached to a claim, and no audit record of who recalled what. Every one of those becomes application code the moment a second agent or a second tenant appears.

Caura's difference is that governance is in the write path, not bolted on afterward. Visibility is set at write time, the trust ladder governs elevation, and the API is exposed as MCP tools so an MCP-capable client gets the same semantics without custom glue. The trade is that you inherit Caura's schema, its provider matrix and its migration cadence.

If your agents are already inside a framework that ships its own memory abstraction, that built-in store is the other realistic alternative. It will be simpler to wire up and will lack cross-agent visibility and trust tiers. The decision is whether shared, governed recall is a feature you need or a feature you are buying ahead of demand.

## Maintenance status, licensing and the MemClaw rename

The repository is not archived, and the last push was on 2026-09-10, ten days before this article's reference point. Release activity is current: backend-v3.7.0 on 2026-09-10, plugin-v2.21.1 on 2026-09-09 and plugin-v2.21.0 earlier the same day. The backend and plugin version lines move independently, so an upgrade plan has to track two artifacts rather than one product version.

The licence is Apache-2.0, declared in both the README badge and package.json. That permits commercial use and modification with the usual attribution and notice obligations, and the repository carries a NOTICE file alongside LICENSE, which is where Apache-2.0 attribution typically lives. This is a description of the licence text, not legal advice; the NOTICE and any bundled third-party terms are what your own review should read.

The rename from MemClaw to Caura has one sharp edge worth knowing before you pin dependencies. Tool names are now caura_*, and the README states the old memclaw_* tool names, environment variables and URLs keep working unchanged. The yanked PyPI release memclaw-client==0.5.0 still installs caura-client for exact pins, but it does not provide the retired memclaw_client import or the MemClaw class aliases. The npm package @caura/memclaw-client was never published, so any documentation pointing at it is wrong.

## Conclusion

Adopt Caura when several agents or tenants must share what they learn under visibility and trust rules, and when you can run Postgres with pgvector plus Redis. Skip it for a single chatbot with one long conversation, where the governance layer adds schema and operational weight for little return. Before adopting, verify three things in a staging deployment: that your embedding and entity-extraction provider combination from .env.example actually produces semantic matches, that IS_STANDALONE=true is confined to local use since it bypasses authentication, and that the trust ladder in docs/integration-without-plugin.md matches the cross-fleet recall you intend to allow. The legacy memclaw_* names and env vars still work, so the rename is not a migration blocker.

## FAQ

### What is Caura?

Caura, formerly MemClaw, is an open-source memory layer for multi-tenant, multi-agent AI fleets. Agents write plain text through tools such as caura_write, and Caura turns it into searchable, governed memory that other agents can recall.

### Is Caura legit?

The project is published at github.com/caura-ai/caura under Apache-2.0 and the repository is not archived, with its last push on 2026-09-10 and current backend and plugin releases. The README also states production use at eToro with 300+ agents on one governed memory.

### Who owns Caura?

The repository is hosted under the caura-ai organization on GitHub and package.json lists the author as Caura. The README does not name a legal entity or company behind the project, so ownership beyond the GitHub organization is not documented there.

## Sources

- [caura-ai/caura on GitHub](https://github.com/caura-ai/caura)
- [License: Apache-2.0](https://github.com/caura-ai/caura/blob/main/LICENSE)
- [Project website](https://caura.ai)
- [README](https://github.com/caura-ai/caura/blob/main/README.md)
- [Releases](https://github.com/caura-ai/caura/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/caura-ai-caura