Your AI Agent Has Amnesia. Persistent AI Memory Is the Fix (I Tested Lighthouse Memory)

Every AI agent has the same dirty secret: when the session ends, it forgets everything.

Not "compresses context." Forgets. Preferences, project decisions, that fix you explained yesterday, gone. Tomorrow you paste the same context again and call it intelligence. Context window is not memory, and no amount of prompt engineering closes that gap.

The category that solves this is called persistent AI memory — an external memory layer your agent writes to and reads from across sessions. I spent an afternoon testing one of them, Lighthouse Memory, including running it locally with zero API keys. Here's what persistent AI memory actually is, how it works, and where it still breaks.

What is persistent AI memory?

Persistent AI memory is storage that lives outside the conversation. The model still does the reasoning; the memory layer handles three jobs:

1. Remember — save facts, preferences, decisions with tags.

2. Recall — retrieve relevant records for a later session, by meaning or keyword.

3. Forget — remove records you no longer want in context.

The key property: the memory survives the chat. Close the laptop, switch models, restart the process — the records are still there, addressed by content identifiers instead of being trapped in a transcript.

How Lighthouse Memory works

Lighthouse Memory ships as a composable SDK. Engine, storage, and embedder are separate npm packages, which means you can start with nothing but a local folder:

npm install @lighthouse-ai/core @lighthouse-ai/engine-batched @lighthouse-ai/store-local-fs @lighthouse-ai/embed-keyword

The API is three calls:

const memory = new BatchedEngine(storage, { namespace: 'demo', embedder })

await memory.remember('User prefers dark mode.', { tags: ['preference'] })
const hits = await memory.recall('what are user preferences?')
const { cid, gatewayUrl } = await memory.flush()   // push pending writes to the network

Writes are batched: remember() queues, flush() (or an auto-flush every 10 writes) pushes the batch to storage and returns a CID — a content identifier. That CID is the "verifiable" part: you can check that retrieved content matches what was saved. It proves integrity, not truth. If the agent stored a wrong fact, the CID happily verifies the wrong fact.

Storage backends are swappable without touching application code:

• local-fs — local folder, zero keys, zero network

• lh-ipfs-filecoin — durable, IPFS/Filecoin with an API key

• lh-ipfs-walrus — durable, Walrus

• s3 — your own bucket

• engine-memwal — the encrypted relayer path (SEAL-encrypted Walrus blobs, every write goes straight to the network, no flush needed)

That last one matters: batched memory is unencrypted by default. Lighthouse says this plainly in their docs. If you're storing anything sensitive, you pick the encrypted engine on purpose, not by accident.

MCP memory: one server, every client

The other integration path is MCP (Model Context Protocol). Lighthouse runs a hosted MCP server — a single stateless HTTP endpoint, no package to install:

POST https://memory-api.lighthouse.storage/mcp
Authorization: Bearer <token>

Your MCP-capable agent (Claude Code, Claude Desktop, anything that speaks MCP) gets tools like memory_remember, memory_recall, memory_forget, memory_flush. The docs even suggest the prompt habit that makes batching safe: "Before ending a session, call memory_flush if any memories are pending."

Because the backend is shared, memory stops being vendor property. The same records can serve ChatGPT, Claude, Cursor, Ollama, or a LangChain stack — each application needs its own connection, but the brain is the same. That's the "different minds, shared memory" claim, and mechanically it's just: storage doesn't care which model wrote the record.

Hands-on: what actually happened when I ran it

I ran two configurations on a plain Linux box.

Config 1 — offline keyword mode. No API key, no network, ~1 second:

node memory.mjs
recall → [{ content: 'User prefers dark mode.', score: 0.5, pending: true }]

It works exactly as advertised. Two memories in, recall out, pending: true until flush.

Config 2 — semantic mode with the local MiniLM embedder (~25 MB model, fully local, one npm install):

q: "what are user preferences?"
 → User prefers dark mode.        0.4992 ✓
 → TypeScript strict mode.        0.1225

q: "how does the user ship code?"
 → User prefers dark mode.        0.2066 ✗  ← wrong record, ranked first
 → TypeScript strict mode.        0.1651

That second result is the honest part nobody puts in a demo video: on a two-record index, the semantic embedder ranked the wrong memory first, and the scores were close (0.21 vs 0.17). Keyword mode was no better. The lesson generalizes beyond Lighthouse: your embedder is your memory quality. If you don't test recall against real queries, you don't have a memory layer, you have a folder with a search box.

Limitations worth knowing before you build on it

• Forget is not deletion everywhere. On local-fs/S3, forget() hard-deletes. On the Lighthouse backend it stops renewal. On the encrypted relayer, there's no delete API at all — the blob lapses on its own and can still surface as indexed: false. Plan retention with that in mind.

• Batched = unencrypted (repeated, because it's the one that bites).

• CIDs verify integrity, not correctness. Garbage in, verifiably garbage out.

• Index vs blob are different objects. Removing a record from the index doesn't erase a stored blob. Your agent's "memory" has two lifetimes, not one.

Lighthouse Memory vs the other approaches

Fair comparison, three ways people solve agent amnesia today:

The tradeoff is real: a self-hosted vector DB gives you full control and full operational burden; decentralized storage gives durability with proofs, at the cost of another dependency (and an API key for the durable tiers). Which one is right depends on whether your memory needs to outlive your infrastructure.

Lighthouse is not a weekend project either: the company reports 34,000 builders and 50 TiB of storage consumed, with backers including Protocol Labs, Fenbushi Capital, NGC Ventures and Balaji Srinivasan, and clients like SingularityNET and the ASI Alliance. An upcoming TGE has been signaled; no date, no token details have been officially announced, so nothing to price in yet — just context.

The one question to ask any agent framework

Next time you evaluate an agent product, ask: where does memory live after the chat closes?

If the answer is "nowhere," you're looking at a demo. If the answer is "our database, but only if you stay subscribed," you're looking at a hostage. Persistent memory — verifiable, portable, encrypted when you need it — is the difference between an agent that works for you and an agent you re-onboard every morning.

Quick start if you want to try it yourself: docs.lighthouse.storage/memory/quick-start (offline mode really does take five minutes), or point any MCP client at their hosted server.

Tested: Lighthouse Memory SDK (@lighthouse-ai/core, batched engine, local-fs + local embedder) on Linux, October 2026. Results above are from my own runs.