MemexAI Docs

MemexAI is drop-in, inspectable memory infrastructure for multi-tenant agents. Run the service beside Postgres, give agents scoped memory tools, and use the admin console to inspect the memory record that changes future behavior.

Start with the service

Product mental model

MemexAI is not transcript RAG. Raw conversations can stay in your app, warehouse, or audit store. MemexAI owns the smaller working set your agent should carry forward: preferences, constraints, corrections, project notes, decisions, shared policies, and source-backed updates.

The default production flow is:

agent / SDK / MCP -> MemexAI service -> Postgres

From there:

• Architecture: the service owns database access, while SDKs, adapters, REST, and MCP all route through the same tool engine.
• Memory model: agents write structured files; search is BM25-first, with optional pgvector hybrid search inside Postgres.
• Scopes: user/ is private per userId; shared/ is global guidance, read-only by default, and writable only when explicitly enabled.
• Operations: revisions, access logs, time travel, observability, and hot/cold files make memory inspectable.
• Optimization: teams can update memory schema over time, and dreaming can compact and clean user memory after activity goes quiet.

How the two paths work

1. Recommended: containerized service

Run the MemexAI service alongside Postgres. Your app never gets database credentials; it connects to the service over HTTP with the TypeScript or Python SDK, or through MCP over SSE/stdio.

Use this when you want a deployable memory service with API key auth and the admin UI built in.

If you want your coding agent to perform the integration, start with Coding Agent Onboarding. It uses the same service path, then asks the agent to prove memory with a two-turn test.

2. Advanced: direct Postgres runtime

Skip the MemexAI service container only when your JavaScript or Python app should own the Postgres connection directly. Your app imports the MemexAI runtime, passes a Postgres URL, runs migrations, and executes memory tools in-process.

Use this for embedded deployments, local experiments, or environments where sharing database credentials with the app is an intentional tradeoff.

Two integration paths

Agentic tools

Use this for most assistants. The model gets two tools, and your system prompt gets the MemexAI prompt block.

const system = await memory.getSystemPrompt('You are a helpful assistant with durable user memory.')
const tools = memory.createAgenticToolset()
// memory_memorize, memory_search

Pass both system and tools into your model call. Tools store and retrieve memory; the prompt block is what makes stored memory available to the next answer.

Raw tools

Use this when your agent or application should manage memory files directly.

const tools = memory.createRawToolset()
// memory_list, memory_read, memory_write, memory_patch, memory_smart_read

Framework adapters

Drop Memex into the framework you already use.

Shared memory can guide behavior

User memory stores per-user facts, preferences, and project state. Shared memory stores global guidance that every agent can read, such as tool rules, product policies, escalation criteria, and evaluation rubrics.

Operate and evaluate memory

Benchmarks are useful, but production memory also needs inspectability. Evaluate whether important facts were written, retrieved, cited, and answerable; then check whether an operator can explain failures from revisions, access logs, and time-travel snapshots.

What MemexAI stores

Memory lives in Postgres tables:

Agents use virtual paths like user/profile.md and shared/policy.md. MemexAI translates those paths to physical database paths and enforces user isolation.

Community / Support

Got a question, found a bug, or want to share how you're using MemexAI? Join us on Slack →