0.3 Quickstart: Your First Memory

This chapter gets you from zero to a working memory in a few minutes, using the same coding agent you already use for everyday work. We assume the most common case: you talk to a chat-based coding agent that supports MCP (OpenCode, Codex, Claude Code, Cursor, Claude Desktop, or any other MCP-capable harness).

You should not have to know how MentisDB stores thoughts, what an "agent identity" is, or what the memory schema looks like. You ask the agent to remember things. The agent does the right thing behind the scenes.

If you are building a custom agent in Rust, Python, or TypeScript: skip the chat path below and start at 5.1 Rust: Minimal Agent with Memory or 5.3 Python: Custom Agent with pymentisdb. The rest of this chapter is for people whose "agent" is a chat window.

Step 1: Get a running MentisDB server

The simplest path is the one-line installer that detects your coding harness and configures the MCP connection for you:

mentisdb wizard

The wizard installs the mentisdb binary if you don't already have it, starts a local server, and registers it with OpenCode, Claude Code, Codex, or whichever harness it finds. It writes a minimal default chain so you can begin immediately.

If you prefer to do it by hand, or you want a shared server for a team, follow 3.5 Deployment Patterns. The cookbook is operator-friendly, not installer-hostile, but the wizard is the right default for a first memory.

Step 2: Open your coding agent

Open the coding agent you use every day. In its MCP / tool list you should see mentisdb_* tools. If your agent has not been primed yet, paste this one-time instruction into a new chat:

Use MentisDB as your durable memory for this conversation. Start by opening the
project chain, loading the core skill, reading the recent context, and telling
me what you already know. Search before you add new memories.

From that point on, in any future chat with the same project, the agent will reuse the same memory by default. You do not need to paste the instruction again.

Step 3: Save your first memory

Ask the agent in plain language. For example:

Remember that I prefer Postgres over DynamoDB for anything that needs joins or
strong transactions. We picked it because DynamoDB's single-region eventual
consistency bit us in a previous incident.

The agent decides what kind of memory this is, what tags and concepts to attach, and where in the chain it belongs. You do not have to know.

Save a second memory the same way:

Remember the lesson from the rate-limiting incident: throttling at the API
gateway is more reliable than per-service limits. We saw three deploy-time
failures from per-service limits.

And a third:

Remember this constraint: all user PII must be encrypted at rest with envelope
encryption. It is a compliance requirement, not optional.

Step 4: Ask your agent to recall it

A few minutes later — or the next day, or in a brand new chat — ask:

How do we handle rate limiting on this project? Check MentisDB first.

The agent searches the chain, finds the throttling lesson, and answers with the context you saved. If the agent ignores the chain and answers from its general knowledge, that is the signal that the MCP connection is not yet wired up correctly.

You just built an agent that remembers. The chain is on disk, hash-chained, and queryable. Close the chat, open a new one tomorrow, and the agent will still find the same three memories.

What just happened

The wizard registered an MCP server so your coding agent can call MentisDB tools.
Your first three prompts told the agent to remember durable things. The agent decided how to store them.
Your fourth prompt asked the agent to recall. The agent searched the chain, found the rate-limiting lesson, and answered from it.
Next time you open a chat in the same project, the same memories are there.

What to ask for next

The chat-based loop is the same on every coding harness. These are the requests users make most often. Use them verbatim or in your own words:

Save a decision — "Remember that we decided to use Postgres for the events table. Reason: we need transactions and joins."
Save a constraint — "Remember the security rule: PII is encrypted at rest with envelope encryption. Compliance requirement."
Save a lesson — "Remember the lesson from this bug: do not recreate deleted chains on cache drop. The safe fix is to detach persistence first."
Save a checkpoint — "Before we stop, write a checkpoint of what we did today, what passed, what failed, and the exact next step."
Recall — "How do we handle rate limiting on this project? Check MentisDB."
Find old work — "Search MentisDB for any prior decisions or mistakes about websocket reconnects before I start this fix."

For the full operating loop (when to search, when to save, what to skip, harness-specific tips) read 1.0 Operator Playbook for Coding Agents next.

Inspecting the chain (optional)

If you like dashboards, the same server exposes one. Run:

mentisdb --mode dashboard

and open the URL it prints. You will see the chain you just wrote, the three memories, and a search bar. It is read-only by default.

What's next

You have a working memory and an agent that uses it. Before you add another thought, read the next chapter on the search-first discipline — it is the single highest-leverage habit in this entire cookbook.