AI Memory

Long-Term AI Memory for Agents & LLMs

AI agents forget everything between runs unless you give them a memory. Montycat is that memory — a self-hosted database that stores what your agent learns and lets it recall by meaning, not just by key. Persistent, semantically searchable, and running on your own hardware — memory you control, not memory you rent.

Read the docs

What is AI agent memory?

An LLM only knows what fits in its context window. The moment a conversation ends or a process restarts, everything it "learned" is gone. AI agent memory is external storage the model can write to and read from over time — long-term memory for facts, tool results, user preferences, decisions, and prior conversations that outlives any single request.

Effective agent memory has to do two things at once: store structured state reliably, and retrieve the relevant pieces by meaning when the agent needs them. A key/value cache can do the first but not the second; a bare vector index can do the second but not the first. Montycat does both in a single engine, which is why it fits the memory problem so cleanly.

The kinds of memory Montycat supports

Practical agents need more than one type of memory. Montycat is a substrate for all of them:

  • Semantic memory — facts and knowledge the agent has accumulated, retrievable by meaning rather than exact key.
  • Episodic memory — a log of past interactions and events the agent can search to recall "what happened before".
  • Working / scratch memory — fast, in-memory keyspaces for state within a task, with optional persistence.
  • User & profile memory — per-user preferences and history, isolated cleanly by keyspace as a data product.

How Montycat provides it

Write to Montycat like any NoSQL store; every value is embedded and indexed as a vector automatically, in the background, at write time. Your write path never pays the embedding cost — it just enqueues, and a background worker embeds in batches.

When your agent needs to remember, it queries by natural-language meaning and gets back the most semantically similar entries with scores, optionally filtered by a similarity floor so only confident matches come back. Because the vectors live in the same engine as the records, there is nothing to sync and nothing to keep consistent between two systems.

A typical agent memory loop

Wiring long-term memory into an agent is a short loop:

  • Perceive — the agent receives a new message, tool result, or observation.
  • Recall — it runs a semantic search over memory for the most relevant past entries and adds them to the prompt as context.
  • Act — the LLM reasons over the augmented context and takes an action.
  • Remember — the new interaction and any learned facts are written back to Montycat, embedded automatically for next time.

Why self-hosted matters for memory

Agent memory is often your most sensitive data — user history, internal documents, tool outputs, and decisions. Montycat runs on your infrastructure with on-device embeddings, so that memory never leaves your environment. There is no per-query retrieval bill and no third-party embedding API in the loop, which matters both for privacy and for cost as an agent accumulates memory over months of use.

Agent memory vs. a standalone vector database

You can build agent memory on a dedicated vector database, but you then run a second system for the structured side of memory — user records, session metadata, tool state — and keep the two in sync. Montycat collapses that: the record and its embedding are the same entry in the same engine. Fewer moving parts, no drift between what the agent stored and what it can recall, and one system to secure and back up.

Recall by meaning (Python)

# semantic search is on by default in the montycat-semantic edition
hits = await memory.semantic_search_get_values(
    "what did the user say about billing?", limit=5
)
# -> [{__key__, __score__, __value__}, ...] ranked by semantic similarity

FAQ

Is this a vector database or a NoSQL database?

Both, in one engine. Montycat stores agent state as records and indexes it as vectors, so you get key/schema access and semantic recall without running two systems.

Do I need an external embedding API like OpenAI?

No. Montycat embeds on-device with a built-in engine — no API keys, no per-query bill, no data egress.

Does the memory persist across restarts?

Yes. Montycat offers persistent keyspaces backed by a durable engine, so agent memory survives restarts, redeploys, and crashes.

Can I use it with LangChain, LlamaIndex, or my own agent framework?

Montycat exposes a structured client API (Python, TypeScript, Dart, Rust) you can call from any agent loop or framework to store and semantically recall memory.

How does agent memory scale as it grows?

Search stays sub-linear thanks to an approximate nearest-neighbor (HNSW) index, and embedding happens off the write path in the background, so recall latency stays low as memory accumulates.

Explore