What is memory?

Tandemu turns Claude Code into a persistent AI teammate. Without memory, every session starts from scratch — Claude doesn’t know your name, your coding style, or what you worked on yesterday. Memory fixes that.

When you work with Tandemu, Claude silently observes and stores context: who you are, how you code, what you’ve built, and how you like to collaborate. The next time you open a session, it picks up where you left off.

Memory is powered by an MCP (Model Context Protocol) server that runs locally. Your memories are scoped to your user — no one else on the team can see them.

What gets stored

Tandemu stores four types of memory:

Personal context

Things Claude learns about you as a person — stored the moment it hears them, never asked directly.

Your name
Role and team
Timezone
Communication style (terse vs detailed, humor vs formal)
How you react to suggestions

Coding DNA

Patterns Claude observes across your sessions — stored after seeing them two or more times.

Naming conventions (camelCase, snake_case, how you name files)
Error handling style (try/catch, early returns, Result types)
Framework and library preferences
Testing approach (TDD, tests after, which framework)
Import style, comment density, type annotation habits
When you override a suggestion — what you prefer instead

Project context

Decisions and context that help Claude understand the work, not just the code.

Architecture decisions and the reasoning behind them
Known gotchas in specific files or modules
Dependencies and their quirks
Patterns that worked vs ones that caused problems

Task history

What you shipped, stored automatically when you run /finish.

Task ID and description
What was accomplished
Key technical decisions made during the task
Time spent and AI ratio

When memory is stored

Memory storage happens continuously — you don’t need to do anything special.

During sessions

First mention of your name — stored immediately, highest priority
Coding patterns — stored after Claude sees the same pattern 2+ times
Corrections — when you reject a suggestion (“no, use early returns here”), Claude stores your preference
Explicit requests — when you say “remember this” or tell Claude something about yourself
Architecture decisions — when you explain why something is built a certain way

During `/finish`

When you complete a task, Claude automatically stores:

A summary of what was built
Coding patterns observed during the task
Any corrections or preferences you expressed

During `/morning`

Claude searches existing memories to greet you personally and reference recent work. No new memories are stored during /morning — it’s read-only.

How memory is used

Session start

When you open Claude Code, Tandemu silently searches for your personal context and recent project work. You won’t see a “loading memories” message — Claude just responds as if it’s always known you.


Morning Sebastian. Last session you were deep in the auth module —
want to continue there or switch to something fresh?

During work

Before suggesting code, Claude checks your stored preferences. If you’ve corrected it before — say, you prefer explicit return types or always use zod for validation — it applies those preferences without asking.

The “btw” moment

At natural breakpoints (after completing a task, at the end of /morning), Claude may include a brief, casual aside. This builds rapport and surfaces things it has learned about you.


btw, 14 files changed and zero test failures. clean run.


btw Sebastian, how did that invoice module deployment go?

These happen roughly 1 in 3-4 interactions. Never during active debugging or when you seem rushed.

How memory works under the hood

Memory runs as an MCP server registered in ~/.claude.json:


{
  "mcpServers": {
    "tandemu-memory": {
      "url": "http://localhost:8765/mcp/sse",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

The server is scoped to your Tandemu user. Each developer on the team has their own isolated memory space — your preferences and context are private.

The memory server exposes tools for adding, searching, listing, and deleting memories. Claude uses these tools automatically — you never need to call them directly.

Personal vs Organization memory

Tandemu stores two kinds of memory:

Personal memory

Scoped to you. No one else can see it. Includes your name, coding style, preferences, communication patterns, and corrections you’ve given Claude.

Organization memory

Shared across the team. Created automatically during /finish when Claude stores architecture decisions, patterns, gotchas, and dependency quirks discovered during a task.

Org memories go through a draft gating process:

Created as draft — visible only to the author while the task is in progress
Promoted to published when the task completes via /finish
Deleted if the task is cancelled (the decisions weren’t shipped, so don’t persist them)

Admins can manually approve draft memories from the Memory Dashboard.

Memory metadata

Every memory stored during /finish is enriched with metadata:


{
  "repo": "sebastiangrebe/tandemu",
  "files": ["apps/backend/src/auth/jwt.guard.ts"],
  "category": "architecture",
  "taskId": "SGS-107"
}

Categories help organize memories for browsing and search:

Category	What it captures
`architecture`	System design, module boundaries, data flow
`pattern`	Reusable coding patterns the team follows
`gotcha`	Traps, edge cases, things that broke before
`preference`	Personal coding style choices
`style`	Naming, formatting, import conventions
`dependency`	Library quirks, version constraints
`decision`	Why something was built a certain way

Memory Dashboard

Browse and manage all memories from the Tandemu dashboard at /memory. The dashboard has four sections, each loading independently:

Stats

Four KPI cards showing total memories, personal count, organization count, and memory health (percentage of memories actively used by Claude in search results).

Charts

Memory Categories — horizontal bar chart showing how knowledge is distributed across categories
Memory Coverage — donut chart showing what percentage of memories are actively referenced

Insights

Three insight cards powered by telemetry:

Knowledge Gaps — modules with frequent code changes but no documented memories. Claude also surfaces these during /morning
Most Referenced — the memories Claude relies on most in search results
Cleanup Candidates — memories that have never been accessed (excludes recently created ones). Click to review and delete stale knowledge

Browser

Toggle between Personal and Organization scope. Search with semantic matching, filter by category or repository. Two view modes:

List view — memories grouped by repository, collapsible, with category-colored accent borders
File tree view — navigate memories by file path like a file explorer

Edit, delete, or approve memories directly from the browser.

Managing your memories

From the dashboard

The Memory Dashboard at /memory gives you full control — browse, search, edit, and delete memories visually. Org admins can approve draft memories.

From Claude Code

Ask Claude directly:


What do you remember about me?


What coding preferences have you stored?

Correct a memory

If Claude has stored something wrong, just tell it:


Actually I switched from Jest to Vitest last month, update that.

Claude will update the stored preference.

Delete memories


Forget my timezone preference.

Or to start fresh:


Delete all memories about my coding style.

What’s never stored

Secrets, tokens, or passwords
File contents or source code
Anything from other team members’ sessions
Sensitive personal information beyond what’s needed for collaboration

Self-hosted memory

When running Tandemu self-hosted, the memory server (OpenMemory) runs as part of the Docker Compose stack on port 8765. All memories stay on your infrastructure — nothing leaves your network.


# Check memory server health
curl http://localhost:8765/health

See Self-Hosting for full deployment details.