Build a Second Brain for Your AI Agent in 5 Minutes

Five minutes is enough because nothing here is novel. The architecture is Tiago Forte's Building a Second Brain pattern (capture, organize, distill, express) and the cultural moment around it is Andrej Karpathy's llm-wiki gist from April 2026, which spent a week on the front page of Hacker News and triggered a wave of "agents that learn" posts. The five-minute promise is just the integration.

The five steps, in order:

1. Get an API key at app.ragionex.com/keys — about one minute.
2. Save your first memory with one curl call — about one minute.
3. Wire your agent to recall via MCP or HTTP — about one minute.
4. Verify with a fresh session by closing the chat and asking — about one minute.
5. Layer in projects so different repos do not share a brain — about one minute.

The rest of this post is the why, the long-term capture habit that makes the second brain worth having, and the honest comparison with the Karpathy-style markdown vault that some readers will already be running.

What "Second Brain" Means for an Agent (and What It Doesn't)

Tiago Forte's framing in Building a Second Brain is that human knowledge work fails when the worker tries to keep everything in their head. The fix is an external store with four operations: capture what is worth keeping, organize it by where it will be useful, distill the noisy version into the durable version, and express it back into work when called for. The CODE acronym (capture, organize, distill, express) is now standard vocabulary in the productivity literature.

For an AI agent the same four operations are the same four operations. Capture is a write to the memory store. Organize is the project label. Distill is the agent rewriting verbose context into a tight, retrievable note before saving. Express is the recall call at the start of the next task. The pattern is borrowed because it works. The tooling is the only thing this post adds.

What it does not mean is "the agent's memory replaces the model". The model still does the reasoning. The second brain is the corpus the model reaches into. It also does not mean "save everything". Forte's whole argument is that capture without distillation produces a swamp. The same is true for an agent's memory store: cheap, high-volume, undistilled writes produce a search corpus that returns noise. The agent ends up worse off than if you had saved nothing.

For an AI coding agent specifically, the second brain is where decisions, conventions, artifacts, and gotchas live. Things like "we tried Redis for the queue and rejected it because we wanted one operational dependency" or "naming convention: services use snake_case, database tables use plural". The kind of residue that has nowhere good to live in a normal repo and currently lives in your head.

Step 1-2: Sign Up + Save Your First Memory

Step 1. Open app.ragionex.com/login. Email link sign-in. The dashboard shows your API key on the keys page. Copy it. The free tier is 1,000 memories total, 500 writes per UTC month, 10,000 searches per UTC month, and 100 project labels. That budget is sized for a real working developer; the section near the bottom of this post has the math on what that covers.

Step 2. Save your first memory with a single HTTP call. Replace the key.

curl -X POST https://api.ragionex.com/v1/memory/write \
  -H "X-API-Key: rgx_memory_..." \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Decided to use Postgres advisory locks for the queue worker. Redis was rejected because we wanted one operational dependency. Decision date 2026-05-03.",
    "project": "infra-decisions"
  }'

The response includes an id like mem_K7X2P9Q4R1 and a status of processing. Indexing runs in the background. The memory is searchable as soon as the status flips to ready, which you can check via /v1/memory/status/{id} or just by searching for it.

Step 3-4: Wire Your Agent to Recall

Step 3. Pick the integration that matches where your agent runs.

If your agent is in Cursor, Claude Code, or Windsurf, the wiring is the MCP config block. Same JSON shape across all three editors; only the file location differs. The walk-through is in Add Persistent Memory in 3 Lines and the short version is:

{
  "mcpServers": {
    "ragionex-memory": {
      "command": "npx",
      "args": ["-y", "@ragionex/mcp-memory"],
      "env": { "RAGIONEX_API_KEY": "rgx_memory_..." }
    }
  }
}

If your agent is your own backend talking to Claude or another model, the wiring is one HTTP call before each model call. The recall result lands in the system prompt or as a prepended user message, exactly where conversation history used to land.

curl -X POST https://api.ragionex.com/v1/memory/search \
  -H "X-API-Key: rgx_memory_..." \
  -H "Content-Type: application/json" \
  -d '{
    "query": "What did we decide about the queue worker?",
    "scope": "segment",
    "results": 5,
    "project": "infra-decisions"
  }'

Step 4. Verify by closing the conversation entirely and opening a new one. In the new session, ask the agent: "What did we decide about the queue worker, and why?" The agent should call memory_search, find the memory you wrote in step 2, and answer with both the decision and the rationale. If the answer matches what you wrote, the loop is closed.

This verification step is the one that distinguishes a real persistent memory from in-context conversation history. Inside one session a chat buffer can recite anything you typed earlier. Across sessions, only a real store can. For more on why the popular framing of "amnesia" is mechanically a retrieval problem, not a capacity problem, see Your Agent Doesn't Have a Memory Problem.

Step 5: Use Projects to Keep Brains Separate

The fifth minute is the one most people skip and regret a week later. The project field is mandatory on every write. It is a lowercase alphanumeric label up to 50 characters. It is the equivalent of Forte's "P" in PARA - the active project axis that organizes capture by where it will be expressed.

The reason it matters: a single mega-brain across every repo, every client, and every personal note returns garbage on recall. A query like "what naming convention do we use" matches against three different conventions if three different projects are mixed in the same store. Project-scoped recall is the difference between an agent that helps and an agent that confidently quotes the wrong codebase at you.

A reasonable starting layout for a working developer:

• conventions - personal coding preferences, error handling style, naming preferences
• infra-decisions - architectural choices made and why
• One project label per active repo - billing-service, auth-platform, etc.
• scratch - ad-hoc notes that have not earned a real project yet

The 100-project ceiling on the free tier is not the constraint people expect it to be. Most users sit at five or six. If you find yourself needing dozens, the right move is usually to merge the small ones rather than to upgrade.

The capture habit makes the second brain. The integration is five minutes. The discipline of "this is worth saving, this is not" is the part that compounds.

Beyond 5 Minutes: What to Capture Long-Term

The five-minute integration is the smallest viable loop. The thing that turns the loop into a useful second brain is the steady habit of capture. The categories worth saving are narrower than they sound; most teams who try this end up with five or six durable patterns.

Architectural decisions and the rejected alternatives. "We chose X. We rejected Y because Z." This is the highest-leverage thing to capture and the one most often forgotten. The agent referencing the rejection saves you from re-litigating the same decision in three months.

Naming and code style preferences. Things you currently keep in a CLAUDE.md, a .cursorrules, or a stale CONTRIBUTING.md. The advantage of a memory store over those files is that recall is queryable - you do not have to fit everything into one budget-constrained context window. For the longer take on when the markdown-file pattern hits its ceiling, see Beyond CLAUDE.md.

"We tried this and it did not work" notes. The single most painful kind of context to recover is the dead end you walked down six months ago. Capturing it - including the reason it failed - prevents the agent from suggesting the same dead end again.

Vendor and library selections with reasoning. "Picked Pino over Winston for logging because of structured output and lower allocation footprint." When the agent is about to suggest swapping the logger, it can read its own past reasoning instead of hallucinating a fresh argument.

Code review preferences. What you flag in PRs, what you do not, and the threshold between the two. Cursor and Claude Code both adapt to this when it is in their recall path.

What not to capture: every conversation turn, every line of code the agent generates, every transient observation. Those produce a noisy store. Forte's distillation step is the filter; if a memory cannot be expressed in two or three sentences, it probably should not be saved as one memory. The same discipline applies on the documentation side - retrieval quality lives or dies by what you put in - which we wrote up in Context Engine vs RAG.

The Difference From a Markdown Vault

Karpathy's llm-wiki gist describes a working pattern: a markdown vault in Obsidian, slash commands in Claude Code that read and write to it, and the agent treating it as the long-term store. The Hacker News thread on it (item 43677907) ran for hundreds of comments mostly agreeing that this is the right shape. It is the right shape. For one developer on one machine.

The places where the vault pattern stops working are predictable. Multi-machine. The vault has to sync, which means iCloud or git or Dropbox, which means conflicts and stale files. Multi-tool. Cursor's context window does not load 200MB of markdown the way Claude Code's slash commands do. Team. A vault is one person's brain; the moment two engineers want to share the second brain, file-based sync hits the limits of file-based sync. Recall scaling. A markdown vault is searched by file scan or grep; semantic recall over hundreds of notes is something the vault tools are now adding but were not designed for.

The honest summary is that the vault pattern is correct for solo-personal scale and the API path is the upgrade for team, multi-tool, or persistent-across-sessions cases. They solve the same problem at different sizes. If you are one developer with one editor and the vault works, keep it. If any of "multi-machine", "multi-tool", "team", or "I want this to work in five different chat clients" is true for you, the API path is what scales.

The five-minute promise applies whichever path you take. If you are reading this in a coding agent right now, you can start saving real memories before the next compile finishes.