The Memory page (/memory) in the Tandemu dashboard gives engineering leads visibility into what your AI teammate knows — and what it’s missing.

Knowledge Gaps

Knowledge gaps are modules in your codebase with frequent code changes but few or no documented memories.

How it works

Tandemu cross-references two data sources:

1. Git activity — Which files and folders change most often (from ClickHouse telemetry)
2. Memory coverage — Which files have associated memories (from memory metadata)

Files with high churn but low memory coverage get flagged. Gaps are aggregated at the folder level (e.g., apps/backend, packages/types) rather than individual files — because memory is typically about modules, not single files.

Why it matters

When Claude starts a task that touches a gap area, it has no stored context about past decisions, gotchas, or patterns in that module. The developer has to re-explain everything. Over time, this slows the team down.

Where gaps appear

• Memory Dashboard — The “Knowledge Gaps” insight card shows the top gaps with change counts and progress bars
• /morning skill — When a developer starts a new task, Claude checks for knowledge gaps in the relevant modules and warns: ”⚠ apps/auth/ — 15 changes, 0 memories. Consider documenting decisions in this area.”

Acting on gaps

When you see a gap, the fix is simple: do work in that module with Tandemu’s /finish skill. Claude automatically stores architecture decisions, patterns, and gotchas at the end of each task. Over time, gaps close naturally as the team works.

You can also ask Claude directly to document knowledge:

Remember: the auth module uses JWT with refresh tokens stored in Redis.
The 15-minute access token TTL was chosen to balance security vs UX.

Most Referenced Memories

The “Most Referenced” card shows which memories Claude uses most in search results and context retrieval.

High-reference memories are your team’s most valuable knowledge — the patterns, decisions, and gotchas that come up again and again. These should be kept accurate and up-to-date.

If a memory is referenced frequently but is outdated, it can actively mislead Claude. Review your top memories periodically to ensure they still reflect current reality.

Cleanup Candidates

The “Cleanup Candidates” card shows memories that have never been accessed by Claude in search results. These might be:

• Stale — Documented a pattern that no longer exists
• Too specific — Describes a one-time fix that won’t apply again
• Poorly written — Stored in a way that doesn’t match how developers search

Recently created memories (less than 7 days old) are excluded — they haven’t had time to be accessed yet.

Click the card to open a review dialog where you can delete individual memories.

Keeping the knowledge base healthy

A healthy knowledge base has:

• High memory health — Most memories are actively used (visible in the KPI card as a percentage)
• Few gaps — Active modules have documented context
• Low stale count — Old memories are reviewed and removed

Think of it like code maintenance — knowledge needs upkeep too.

Memory Health Score

The Memory Health KPI card shows the percentage of your team’s memories that are actively referenced by Claude. It’s calculated as:

Health = (Accessed memories / Total memories) × 100%

• 80%+ — Healthy. Most knowledge is being used.
• 50-80% — Review cleanup candidates. Some knowledge may be stale.
• Below 50% — Many memories aren’t useful. Review and clean up.

A new team will naturally start at 0% since the access tracking begins when you first use the memory dashboard. Health improves as the team works more sessions with Tandemu.