Agent Memory

Give the next session somewhere to start.

Persistent memory for agents, built on RedDB and planned as a managed service.

Planned service. No self-service deployment yet; we onboard early users by email.

Proposed flow Planned
  1. 01 Messages
  2. 02 Retained memory
  3. 03 Relevant context
Keep useful context and retrieve it when the agent needs it.

What is planned

Built around your workload.

Teams whose agents need context across sessions.

01
Capture useful context
The proposed pipeline extracts and embeds memories from application messages.
02
Retrieve what matters
Use semantic retrieval to bring relevant stored context into a new session.
03
Control what is retained
Tenant isolation, retention and deletion must be qualified before managed access opens.

How it works

Managed long-term memory for your agents: messages go in, durable memories come out, and the next session starts with the context that matters.

How it is planned to work
  1. 01

    Write messages

    Your agent sends the conversation. One extraction call per write turns it into memories.

  2. 02

    Store in RedDB

    Memories are embedded and kept in RedDB alongside their graph and vectors.

  3. 03

    Recall by meaning

    A query is embedded and matched with vector search, returning the memories relevant to the new session.

You would pay for

  • Memory tokens (extraction and embeddings)
  • Retained memory storage, per GB-month
  • Not metered: retrievals, agents, end users or seats

Not promised yet

  • The API shape, retention controls and bring-your-own-key options are still being decided.

Source: planning record, as of 2026-09-24.

Pricing

Plan the workload before the bill.

The plan separates memory-pipeline tokens from retained storage. Managed access, retention and rates are still being qualified.

Early access

Help shape Agent Memory.

Tell us what you want to run, which models or runtimes you use, and what you need to keep. We will discuss fit and availability before any deployment.