Caura: governed shared memory for agent fleets, reviewed from the README

The problem Caura targets: memory that leaks across tenants or dies inside one agent

Most agent memory work starts with one assistant and one user. Caura starts from the opposite end. The README describes it as memory for multi-tenant, multi-agent fleets, where agents store what they learn, find what the fleet knows, and learn from each other instead of repeating mistakes. The stated unit of value is the fleet, not the conversation. That framing drives everything else in the repository: tenant identifiers on every write, fleet identifiers on recall, visibility scopes that decide whether a memory stays private to the agent that wrote it, is shared inside a team, or crosses fleets under governance. If your agents are isolated processes that each keep their own context window, Caura is solving a problem you have not created yet. If you already have a deploy agent, an incident agent and a support agent that keep rediscovering the same operational facts, the repository is aimed squarely at you. The README also states that nothing changes for a single-agent setup, which is a fair claim to make and also a way of admitting that the extra machinery earns nothing until agent count grows.

Write, recall, compound: the loop and the visibility scopes behind it

The documented loop is three steps: write, recall, compound. Agents write plain text, and Caura turns it into searchable, governed memory. The README's fleet example shows the mechanism concretely. Agent A calls caura_write with an agent_id, a fleet_id, a visibility value and a content string, recording an operational lesson about rolling back a service. Agent B calls caura_recall with its own agent_id, a fleet_ids array and a natural language query, and the result identifies deploy-agent as the author. That authorship attribution is the compounding part: recall returns who knew the thing, so a second agent reuses a first agent's lesson rather than re-deriving it. Visibility is the governance lever. scope_agent keeps a memory private, scope_team shares it within the fleet, and scope_org enables cross-fleet recall subject to what the README calls the trust ladder. The trust ladder itself is not spelled out in the README body; it is linked to docs/integration-without-plugin.md, which is the file to read if trust elevation is the part you care about. The description also lists a knowledge graph, audit trails and keystone policies, but the README excerpt does not show their request or response shapes, so treat those as documented features whose interfaces you should confirm in the repository before designing around them.

Standalone mode and the keyless quickstart: what actually runs

The fastest documented path needs no API key and no signup. You clone the repository, copy .env.example to .env, append IS_STANDALONE=true, and run docker compose up -d --wait. The README says this brings up Postgres with pgvector, Redis and the API, and that it takes roughly thirty seconds. Standalone mode runs single-tenant with auth bypassed, and the example requests use the literal header X-API-Key: standalone against http://localhost:8000. The write call posts to /api/v1/memories with tenant_id, agent_id, write_mode set to strong, and a content field; the search call posts to /api/v1/search with tenant_id and a query. One detail deserves attention because it changes what you are actually evaluating. The README states that keyless mode boots with dummy embeddings, and that the keyless strong-write response derives memory_type, title, status, weight and a metadata summary from a deterministic local heuristic over the single content field. With an AI provider configured, those values become model-inferred and metadata can also carry tags. So the quickstart proves the plumbing (service boots, write persists, search returns) and not the retrieval quality. The README is honest about this and even tells you the keyless query deliberately reuses words from the memory, then suggests retrying with a paraphrase once an embedding provider is configured.

MCP-native integration and where the plugin documentation lives

Caura exposes its tools over the Model Context Protocol, and the tool names are prefixed caura_, with caura_write and caura_recall shown in the README's fleet example. The repository carries a plugin with its own release line (plugin-v2.21.1 at the time of the listed releases), separate from the backend line (backend-v3.7.0). That split matters operationally: the MCP-facing surface and the server can move independently, so a plugin upgrade is not automatically a backend upgrade. The README points to static/docs/integration-guide.md for plugin documentation and to docs/integration-without-plugin.md for the non-plugin path, which is where it says to mint an agent-scoped credential for production and where the trust ladder is described. For production deployments the README advises giving each client its own agent-scoped credential rather than sharing one. That is the right instinct for a multi-tenant system, but the excerpt does not show the credential minting request, so the integration-without-plugin document is the required reading before you wire anything into a live fleet.

The rename, and why the compatibility story is not clean

MemClaw is now Caura, and the README treats the old name as a taught legacy alias. The compatibility claims are specific and worth reading carefully. Tool names are caura_*, and the old memclaw_* tool names, environment variables and URLs keep working unchanged. The PyPI release memclaw-client==0.5.0 was yanked, still installs caura-client for exact pins, but does not provide the retired memclaw_client import or the MemClaw class aliases. The npm package @caura/memclaw-client, the README says, was never published. The practical consequence is that a project pinned to memclaw-client==0.5.0 will install and then fail at import time if it references the old module path or class name. Anyone migrating should grep for memclaw_client and MemClaw in their own code, not just for the tool names and URLs, because those are the two things the release explicitly does not preserve. This is a small piece of the repository but it is the kind of detail that turns a rename into an afternoon of debugging.

Where Caura is the wrong tool, and what to weigh against it

The README makes its own strongest counterargument. Public agent-memory benchmarks such as LoCoMo and LongMemEval, it says, measure one agent, one user, one long conversation, which is the single-chatbot shape, and therefore score the on-ramp rather than the axes that compound with agent count: latency, token efficiency and governance. That is a defensible position, and it also means you cannot use those benchmark rankings to compare Caura against a per-conversation memory library on the axis that library optimizes. If your workload is one long chat with one user, a simpler store keyed by conversation will do the job with less infrastructure. Caura's own floor is Postgres with pgvector plus Redis plus the API, brought up through Docker Compose, and semantic recall requires an AI provider key. The alternative to consider is not another fleet memory server but the memory feature already inside your agent framework, or a plain vector store you query directly. The difference in approach is governance scope: a direct vector store gives you one namespace and no notion of who wrote what, no visibility boundary between agent, team and organization, and no trust tier gating cross-fleet recall. If you need those boundaries, a vector store will not grow them later without a rewrite. If you do not, Caura's scopes are configuration you carry and never exercise. The production reference in the README is eToro, described as running 300+ agents, 26,500+ memories and 1,372 shared skills on one governed memory with a 23 ms p50 search; that is the vendor's own published figure, not an independent measurement, and it describes a deployment rather than a benchmark you can reproduce from the repository.

Maintenance surface, release cadence and licence

The repository is active rather than archived, with a last push in September 2026 and a backend release (backend-v3.7.0) plus two plugin releases (plugin-v2.21.0 and plugin-v2.21.1) within roughly a day of each other. Two independently versioned artifacts mean two upgrade paths to track, and the plugin-to-backend compatibility matrix is the thing to check before bumping either. The stack you operate is Postgres with pgvector, Redis and the API, all defined in the compose file, so the upgrade cost is partly database migration cost rather than only container image tags. The project is Apache-2.0, which permits commercial use, modification and redistribution under that licence's terms, including its patent grant and its notice and attribution requirements; that is a plain statement of what the licence is, not legal advice, and if you are embedding Caura in a product you should have your own counsel read the LICENSE file rather than this paragraph. The README also links a CONTRIBUTING.md and a Discord invite, which tells you the project expects outside contributors, though the excerpt does not describe a governance or maintainer model.

Editorial conclusion

Adopt Caura if you are running several agents that should share operational lessons under tenant and fleet boundaries, and if you can run Postgres with pgvector plus Redis and configure an embedding provider. Do not adopt it if you only need per-conversation memory for one assistant, because the governance surface (tenants, fleets, visibility scopes, trust tiers) is overhead you will not use, and the keyless local mode boots with dummy embeddings that cannot match paraphrases. Before committing, run the standalone compose stack, confirm that the search endpoint returns your written memory with a real provider key configured, and read docs/integration-without-plugin.md to check how agent-scoped credentials and trust elevation are actually minted.

Official sources

1. caura-ai/caura on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases