Your agents finally
remember everything

Two calls.
That's the whole API.

The entire surface area, as it was documented when the service ran.

curl -X POST https://memstore.dev/v1/memory/remember \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content":"User prefers dark mode, uses React"}'

curl "https://memstore.dev/v1/memory/recall?q=user+settings" \
  -H "Authorization: Bearer YOUR_KEY"

# {"memories":[{"content":"User prefers dark mode,
#   uses React","score":0.97,"age":"2h ago"}]}

Try it yourself

No API key needed. Select a memory, store it, then recall it semantically.

How it was built

A small, deliberately boring stack. Two endpoints doing real work, and one SQL function doing the interesting part.

The recall function

Recall is one round trip. The API embeds the query, then hands the vector to Postgres, which does filtering, scoring, and ranking in a single indexed pass — no candidate set is ever shipped back to Node for re-ranking.

-- Semantic recall (cosine similarity via pgvector)
CREATE OR REPLACE FUNCTION recall_memories(
  p_agent_id   UUID,
  p_embedding  VECTOR(1536),
  p_session    TEXT  DEFAULT NULL,
  p_top_k      INT   DEFAULT 5,
  p_threshold  FLOAT DEFAULT 0.5
)
RETURNS TABLE (
  id          UUID,
  content     TEXT,
  session     TEXT,
  metadata    JSONB,
  score       FLOAT,
  created_at  TIMESTAMPTZ
)
LANGUAGE SQL AS $$
  SELECT
    m.id,
    m.content,
    m.session,
    m.metadata,
    1 - (m.embedding <=> p_embedding) AS score,
    m.created_at
  FROM memories m
  WHERE
    m.agent_id = p_agent_id
    AND (p_session IS NULL OR m.session = p_session)
    AND (m.ttl IS NULL OR m.ttl > NOW())
    AND 1 - (m.embedding <=> p_embedding) >= p_threshold
  ORDER BY m.embedding <=> p_embedding
  LIMIT p_top_k;
$$;

<=> is pgvector's cosine distance operator, so 1 - distance gives a similarity score in the same expression that drives the sort. The ORDER BY on the raw distance is what lets the ivfflat index serve the query; ordering on the derived score column instead would force a sequential scan.

What is persistent memory
for AI agents?

Persistent memory for AI agents is the ability to store facts, decisions, and context outside the agent runtime and retrieve them semantically on future runs. Unlike context window stuffing, persistent memory scales across sessions, reduces token costs, and gives agents long-term recall without manual state management.

Three calls.
Memory that survived the run.

What your agent needs
to remember

Not a vector DB tutorial — a memory layer with agent-native primitives.

Built for every
agent type

What it was used for, from customer-facing bots to internal automation pipelines.

Works with your
existing stack

No SDK required — any language that could make an HTTP request worked with Memstore.

# LangChain / CrewAI / any agent
import requests

requests.post(
  "https://memstore.dev/v1/memory/remember",
  headers={"Authorization": f"Bearer {api_key}"},
  json={"content": "User prefers dark mode"}
)

// Any JS agent or framework
await fetch(
  "https://memstore.dev/v1/memory/remember",
  { method: "POST",
    headers: { Authorization: `Bearer ${apiKey}` },
    body: JSON.stringify({
      content: "User prefers dark mode"
    })
  }
)

Stop building infrastructure.
Start building agents.

How the alternatives compared at the time Memstore was running.

Usage-based pricing. No seats. No surprises.

Pricing as designed when the service was live.

Pay for what your agents use. Free tier generous enough to build your first production agent.

1 operation = 1 store or recall call. Most agent runs use 20–100 ops.

Common questions

Your data stays yours

Agent memory holds sensitive data, so these were the guarantees the service was designed around.