SOVEREIGN MEMORY · LIVE

Agent memory that
actually persists.

A cryptographically signed, vector-indexed memory layer that survives sessions and restarts. Owned by the agent, not the platform. Every write is an R+2 signed receipt.

Memory Writes (live)
Agents
1536
Embedding dims
R+2
Signed receipts
THE PROBLEM

AI agents have a memory problem.

They forget you between sessions. They can't tell what they did yesterday from what they did six months ago. And when you ask them to prove what they remembered — they can't.

Today's agent memory in practice

You ask ChatGPT a question. It answers brilliantly. You come back tomorrow and it has no idea what you talked about. You ask an autonomous agent to "remember the user prefers vegetarian food." Two weeks later it serves them a recipe with chicken in it. There is no audit trail, no signed proof of what was remembered, and no way for the user to take their memory with them when they switch tools.

$ agent.recall("user dietary preferences")
Error: no persistent memory layer configured
HOW IT WORKS

Three calls. Cryptographically signed. Cross-session.

A memory write becomes a signed R+2 receipt (Ed25519), indexed in pgvector at 1536 dimensions, and recoverable across sessions. Agent identity is anchored by a soul-bound token (SBT) on Base mainnet — non-transferable.

curl · memory/storetriple-click to copy
# 1. Store a memory — produces a signed R+2 receipt
curl -X POST https://api.dcslabs.ai/v1/memory/store \
  -H "Authorization: Bearer $DCS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "0001",
    "content": "User prefers dark theme, vegetarian, lives in Mumbai",
    "tags": ["preferences"]
  }'

# → { "memory_id": "mem_a83f12cd",
#     "receipt_id": "r2_a83f12cd",
#     "embedding_dim": 1536,
#     "signed": true }
curl · memory/searchsemantic recall
# 2. Semantic recall — fuzzy query, returns by cosine similarity
curl -X POST https://api.dcslabs.ai/v1/memory/search \
  -H "Authorization: Bearer $DCS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "0001",
    "query": "what does this person like to eat",
    "top_k": 3
  }'

# → { "results": [
#     { "memory_id": "mem_a83f12cd",
#       "content": "User prefers dark theme, vegetarian, lives in Mumbai",
#       "cosine_similarity": 0.524,
#       "receipt_id": "r2_a83f12cd" } ] }
curl · memory/verifycryptographic proof
# 3. Verify the receipt — no trust required, runs client-side
curl https://api.dcslabs.ai/v1/receipts/r2_a83f12cd \
  | npx dcslabs-r2-verify

# → ✓ Signature valid (Ed25519 / RFC 8785)
#   ✓ Chain pointer matches predecessor
#   Receipt verified — independently, client-side.
WHAT MAKES IT SOVEREIGN

Owned by the agent. Auditable by anyone.

[01]

Cryptographic ownership

Every memory write is cryptographically signed (Ed25519) and hash-chained to the agent's prior entries. An entry can't be altered after the fact without breaking the signature and the chain — tampering is always detectable.

[02]

Cross-session persistence

Memories survive process death, server restarts and redeployments. Backed by pgvector + managed Postgres with automated backups. Multi-region replication is on the roadmap.

[03]

Semantic recall via 1536-dim embeddings

Uses OpenAI's text-embedding-3-small. Cosine similarity threshold tuned for nuanced recall — a query like "what does the user like to eat" finds the stored preference "vegetarian" without needing exact word matches.

[04]

R+2 receipt chain

Every memory operation generates a tamper-evident receipt linked to the agent's full action history. Regulators, auditors, and users can prove what an agent remembered at any point in time.

[05]

Portable, not locked-in

Memory is exportable in a single API call as a stream of signed R+2 receipts. Switch tools, switch frameworks, switch hosting providers — your memory comes with you, cryptographically intact.

[06]

On-prem & air-gap ready

The R+2 receipt format is open and the stack (pgvector + verifier) can be self-hosted. Air-gapped / on-premise deployment is offered on the Sovereign tier for environments with restricted connectivity (roadmap for gov, defence, healthcare).

PRICING · DURING LAUNCH

Free for the first 1,000 builders.

During the public launch window, the Free tier covers anything most teams need. No credit card, no SSO requirement, no time limit on the free allocation. Paid tiers exist for production scale, but most builders never need them.

Builder
$29/mo
For solo builders and small teams shipping production agents.
  • 50,000 memory writes / mo
  • 500,000 queries / mo
  • 10 agent identities
  • Priority support · 24h SLA
  • IPFS receipt pinning
  • Audit export API
Sovereign
Custom
Air-gapped deployments, on-premise installation, dedicated infrastructure.
  • Unlimited writes & queries
  • Unlimited agent identities
  • On-prem · air-gappable
  • Direct technical support
  • Compliance reporting (DPDP / GDPR / RTI)
  • Sectoral profile customization
SIGNUP · 30 SECONDS
FAQ

Common questions

What's actually stored in memory?
Whatever you pass in the content field. We embed it (1536-dim vector via OpenAI's text-embedding-3-small) and store both the original content and the embedding. The content is encrypted at rest. The embedding is what enables semantic search.
Can the agent's memory be edited or deleted after the fact?
No — once a receipt is signed, the underlying memory entry is immutable. You can mark an entry as logically deleted (a new signed receipt with action_type memory/delete), and queries respect the delete marker. But the original entry remains in the receipt chain. This is the right tradeoff for audit compliance: regulators need to see what an agent remembered at the time it acted, not the cleaned-up version.
Is the memory shared across my agents or per-agent?
Per-agent. Each Agent SBT has its own memory namespace, signed by its own private key. If you want shared memory across multiple agents, model it explicitly — have a "shared" agent that both agents can read from, or use the federation primitive to relay memory entries between agents.
What happens to my data if DCS Labs goes away?
Three protections. First: receipts are exportable any time via /v1/memory/export as a signed R+2 stream — you can keep your own copy. Second: optional IPFS pinning means receipts live on a decentralized layer independent of our infrastructure. Third: the spec is open and MIT-licenced — any team can spin up a compatible service, and your existing signed receipts remain verifiable forever.
How does this compare to LangChain / LlamaIndex memory?
LangChain and LlamaIndex memory modules are in-process — they live in your application's memory and disappear when the process restarts. DCS Sovereign Memory is a separate service with persistent storage, cryptographic receipts, and cross-session recall. You can use both: LangChain for ephemeral in-context memory, DCS for the long-term layer that needs to survive deployments and be auditable.
Does this work with Claude / OpenAI / open-source models?
Yes, model-agnostic. The memory layer is a separate API. You call memory/store and memory/search from any code, irrespective of which LLM you're using. The easiest way to wire it in is via our MCP server (npm install dcslabs-mcp-server), which adds memory as a default tool that any MCP-compatible client (Claude Desktop, Cursor, Windsurf) can call.
What's the latency profile?
A query is an embedding call plus a pgvector cosine search; a write adds signing and a DB insert. In practice the embedding step dominates latency. If you need lower latency you can pre-compute the embedding client-side and pass it in the request. Published latency benchmarks will accompany a future load-test report.