Mnemo · network shared memory

Memory is a network service, not a library.

Mnemo is a headless, per-tenant memory service for agents on the Layr8 network. It stores conversation turns, temporal facts, and learnings, and serves them back over a native memory/1.0 protocol. Any agent that speaks DIDComm gets shared, cross-session memory from one service identity.

protocol: memory/1.0 over DIDComm v2

Your Space · memory/1.0

A session starts. It asks what the team knows.

context-request · memory space: ops · session: s-114 · budget: 4,000 tokens
hot 12 · warm 8 · cold 3 · kb 5 · facts 9 · kb_dropped 0

no HTTP surface · grants on the caller’s identity · receipts, or a correlated rejection

The old way

Your agents’ memory holds your organization’s context. Most stacks leave it readable by anything.

On Layr8

Mnemo has no HTTP surface at all. Nothing can read or write it except an authenticated identity holding a grant.

Why a service

One memory across every agent you run.

Most agent stacks keep memory as a library inside each agent: a file on disk, a store per framework, a connection shared across the whole account. Every agent remembers alone, and nothing about who may read what is enforced anywhere. Mnemo puts memory on the network: one protocol, one service identity, grants per memory space, and recall that tells you what it dropped.

Shared

Claude Desktop, Claude Code, Hermes, any DIDComm agent: the same memory, addressed by one service identity. A session starts already knowing what the last one learned.

Scoped

The memory space is the unit of tenancy (Mnemo’s own unit, distinct from your Layr8 Space). Every read and write names a memory space. Which agent reaches which memory space is a grant, not a convention.

Honest

Recall runs under a token budget and reports what it kept and what it dropped, tier by tier. Truncation is never silent.

The security story

The memory service has no attack surface.

The memory holding your organization’s context cannot be read or written except by an authenticated identity holding a grant.

Protocol only

No HTTP API. No MCP endpoint. No UI. No chat of its own. Every interaction is a DIDComm message routed through a Layr8 node.

Grants on the caller’s identity

Authorization is keyed on the authenticated sender, never on an identity claimed in the message body. Members hold reader, writer, or owner on a memory space. Only deployment admins create memory spaces.

Fail closed

No grant means denied, on everything. An unknown memory space and one you’re not a member of answer identically, so there is nothing to enumerate.

Receipts, or a correlated rejection

Writes are one-way. Ask for an acknowledgement and the service answers with a delivery receipt; a rejected write answers with a problem report tied to the write that failed.

Two layers, both on the record. The node’s own grant layer gates who may send memory/1.0 to the service at all, and records every allow and deny in the Space’s decision ledger. Inside the service, memory-space membership decides what that sender may read or write. The two denials at the top of our own audit log are an agent asking to write memory it had no grant for, refused at the node, on the record.

How recall works

Tiered recall under a token budget.

A context request names the memory space, the session, and a token budget. Mnemo assembles the reply from five tiers, matched to the conversation, and stops at the ceiling. The response says how much came from each tier and how much was dropped.

recall assembly · illustrative
context-request · memory space · session · conversation peer · token_budget: a hard ceiling
Hot
12 turns

This session, verbatim.

Warm
8 turns

Verbatim turns from other sessions, matched to what you are asking.

Cold
3 summaries

Compressed summaries of older sessions.

Knowledge base
5 entries

Durable learnings, keyed. Latest value wins.

Facts
9 triples

Temporal, with as-of history: update, forget, ask what was true when.

response reports: per-tier counts kb_dropped: 0 assembled under budget

The budget is a ceiling on the whole assembly, and the response says how much came from each tier and what was dropped. Truncation is never silent.

Per-identity rate limits. Semantic search over turns when an embedder is configured. If the database is unreachable, reads say so and turn writes buffer for replay. Nothing is silently lost, and nothing is silently truncated.

Memory and the identity layer

Joiner. Mover. Leaver. Memory.

JML is the identity lifecycle security teams already run for people: provision access on joining, change it on a role move, revoke it on leaving, and keep evidence of each step for the auditor. Memory access gets the same lifecycle here.

Joiner

An agent gets memory by receiving a grant on a memory space. Until then, every call is denied by design.

Mover

A role change is a grant change: reader to writer, writer to owner. Review means listing who holds what on the memory space.

Leaver

Pull the grant and the agent’s access to the memory space ends. No key to rotate, because it never held one.

Memory is the first thing an agent reaches for and the last thing most stacks secure. On Layr8 it is governed like every other resource: an identity, a grant, a ledger entry.

Bring your agent

Who talks to it today.

Claude Code

The Layr8 plugin captures turns automatically and injects recall at the start of each turn. A session is bound to a memory space and arrives already primed.

Claude Desktop

Reaches the same service over the network. Write from the desktop, recall from the terminal, and back.

Hermes, and any DIDComm agent

A Hermes plugin speaks memory/1.0 directly. A published skill on the skills registry teaches any DIDComm-speaking agent the protocol.

Getting access: discover the service by its tags or the memory/1.0 protocol URI. An admin creates a memory space. Its owner grants your agent a role. Nothing to install on the service side, nothing to expose on yours.

Give your agents one memory.

Get on the network Or book a demo →