Memory

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 has a dual-scope memory system: personal memories visible only to you, and organization memories shared with your team.

Personal memories

Things only you and your Claude sessions can see.

Personal context — stored the moment Claude learns them:

Your name, role, team, and timezone
Communication style (terse vs detailed, humor vs formal) — persistent patterns only, never momentary mood
How you react to suggestions and give feedback

Coding DNA — stored after Claude observes the same pattern 2+ times:

Naming conventions, import style, comment density, type annotations
Error handling style (try/catch, early returns, Result types)
Framework and library preferences
Testing approach (TDD, tests after, which framework)
When you override a suggestion — what you prefer instead

Organization memories

Shared knowledge that helps your whole team. These go through a draft → published lifecycle: memories created during a task start as invisible drafts. When you run /finish, they’re automatically promoted and become visible to teammates. If a task is cancelled, its draft memories are cleaned up.

Project context:

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 — stored automatically on /finish:

What was accomplished (task ID, description, summary)
Key technical decisions made during the task
New patterns or libraries introduced

Memory categories

Every memory is tagged with one of seven categories: architecture, pattern, gotcha, preference, style, dependency, or decision. This powers the category breakdown chart and file tree view on the dashboard.

Structured metadata

Each memory carries rich metadata that enables search, filtering, and insights:

repo — which repository (owner/repo format)
files[] — relevant file paths
category — one of the seven categories above
taskId, taskUrl — linked task
commitSha, prNumber, prUrl — source code provenance
source — how it was created (finish, mcp, manual, git, pr)

This metadata powers knowledge gap detection (files with many changes but no memories), the file tree browser, and usage insights on the dashboard.

Memory observability

Every time Claude searches or accesses a memory, it’s logged. This enables:

Most referenced — which memories Claude actually relies on
Never accessed — cleanup candidates that may be stale
Knowledge gaps — actively changed files with no memory coverage

Stale draft memories are cleaned up automatically via background jobs.

When memory is stored

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

During sessions

Claude continuously stores observations as you work — not just at task boundaries.

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
Module-level observations — when touching a module for the first time, Claude notes patterns and gotchas
Dependency choices — when you add or prefer specific libraries

During `/finish`

When you complete a task, Claude automatically stores:

A summary of what was built (organization scope)
Architecture decisions and new patterns (organization scope — draft → published)
Coding patterns and preferences observed (personal scope)
Any corrections you made to Claude’s suggestions (personal scope)

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 pre-loads your personal context into the session via a startup hook. Your personality, preferences, and coding style are written to ~/.claude/CLAUDE.md so Claude has them immediately — no search delay. The repo’s memory index is also loaded, giving Claude a map of what knowledge exists for the current project.


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

During work

Claude checks stored memories at specific trigger points — not just passively:

First time touching a module — searches for architecture decisions and gotchas
Before refactors — checks for known patterns and past decisions
When encountering surprising code — looks for documented context
Before adding dependencies — checks for existing preferences or quirks
When you ask “why” — searches for architecture decisions and rationale

If you’ve corrected Claude 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 at most once per session. Never during active debugging or when you seem rushed.

How memory works under the hood

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


{
  "mcpServers": {
    "tandemu-memory": {
      "type": "sse",
      "url": "https://memory.tandemu.dev/mcp/tandemu/sse/<your-user-id>"
    }
  }
}

The URL includes your user ID to scope memories to you. 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 https://memory.tandemu.dev/health

See Self-Hosting for full deployment details.