Skip to main content
Conare AI Memory gives each of your end users a persistent, isolated memory. Your app writes distilled observations; Conare handles embedding, indexing, hybrid retrieval (vector + BM25, fused and reranked), LLM synthesis, and connector-fed ingest.

​
What it does

  • Save — POST /api/v1/memories stores an observation for one end user. Deduplicated by content. Batch import up to 100 at a time with /memories/batch.
  • Search — POST /api/v1/search: sub-second ranked matches over one user’s memory. Use when your own agent does the reasoning and just needs relevant raw material.
  • Deep recall — POST /api/v1/recall: a synthesized, citation-grounded answer (“what do we know about this user relevant to X”) designed to be injected into a system prompt at session start.
  • Suggestions — POST /api/v1/suggestions: given a moment of context, up to 5 concrete next actions, each grounded in a specific memory — never generic advice. Returns [] for new users, so render conditionally and fetch async.
  • Connector ingest — end users connect their tools (integrations) and their memory fills itself, organized into per-source containers.

​
Source-owned memories

If you sync memories from a system of record (CRM rows, profile fields, tickets), use the versioned lifecycle surface: upserts and deletes carry a version, so out-of-order deliveries and crash retries are safe by construction. Read the source-owned memories guide.

​
Lifecycle and compliance

  • DELETE /api/v1/memories/by-id/{memoryId} — remove one memory.
  • DELETE /api/v1/containers/{containerTag} — drop one source’s memories for a user.
  • DELETE /api/v1/users/{endUserId} — full GDPR wipe of an end user.

​
Two ways to consume

  1. Partner HTTP API (this section + API Reference) — memory for your product’s users.
  2. MCP — coding agents use Conare memory directly. See MCP tools.