Claude Memory and Claude Code Memory: How Teams Give Claude Lasting Context

TL;DR

• Claude native memory and Projects give a single developer persistent context inside one project. Anthropic scopes them per-user and per-project, so they genuinely help solo work.
• That scope does not span a team. Two engineers on the same repo do not share Claude context, and memory resets or fragments across projects and worktrees.
• Every new session and every teammate re-establishes context the company already knows, which burns tokens re-sending the same background on every call.
• Sentra fixes this as an org-wide memory layer Claude reads from through MCP and the Brain API, so every session starts with resolved company context and cuts token spend by roughly 70 percent.
• Sentra scores about 88 percent on Terminal-Bench 2.1, with SOC 2, ISO 27001, and self-hosting.

What Claude native memory and Projects actually do

Claude Code memory is not a database or a learning system. It is text. Claude re-reads a set of Markdown files, usually named CLAUDE.md, and injects them into context at the start of every new session. As one developer breakdown puts it, "There is no magic database, no long-term learning, and no mysterious internal state. Claude does not 'remember' in a human sense. It re-reads instructions, every time" (Claude Code Memory Explained).

Those files load in a fixed hierarchy. Enterprise and user memory apply globally and load first. A project CLAUDE.md applies whenever you work inside a given repository. Project rules live in .claude/rules/*.md as modular, topic-specific files, some of which activate only for certain file types through paths frontmatter. Broader contexts load first, and more specific project contexts override them.

The scope is deliberately per-project. Project memory defines how a single repository works, which is why Anthropic frames it as the place for conventions and frequently used commands. Global files stay small, around 50 lines in the reference example, and hold stable behavioral rules rather than project knowledge.

Every line you add costs tokens on every session, so verbosity compounds even for one developer working alone. The guidance is direct. Global memory should stay small, project memory should stay scoped, and repetition across files is expensive. Recommended lengths run 20 to 80 lines for small repos and 80 to 200 for typical products. Past roughly 200 lines, files become "harder to maintain and easier to contradict" (Claude Code Memory Explained).

Where Claude Code memory stops for teams

Claude Code memory holds one developer's context, not a team's. Anthropic's own hierarchy loads enterprise, project, and rule files that each Claude session re-reads locally, so the context lives inside whatever Markdown files sit in a given user's checkout. Two engineers working the same repository do not share the same Claude context. When your teammate teaches Claude a debugging pattern or a ruled-out library, that knowledge stays in their environment, and yours starts blank.

The scoping problem gets worse below the project level. One developer flagged that Claude Code's auto memory is per-project, and "each worktree has its own memory, which is useless" for keeping decisions consistent across branches you have checked out at once (LinkedIn). You can split one repo into several worktrees during a big refactor, and each one forgets what the others learned.

The result is constant re-teaching. As one guide puts it, "Claude Code Doesn't Remember You," and "every session starts fresh," so referencing a convention your team established months ago means explaining it from scratch (MindStudio). That is stateless design working as intended, not a bug you can patch with better prompts.

The cost of that statelessness is concrete. A QA architect building a Playwright test framework watched Claude "completely forget about the existing tests" and generate a redundant one from scratch, which wasted nearly an hour and forced a refactor (Medium). In a separate incident, a summarized conversation dropped the fact that an API endpoint was rate-limited, and tracking down the resulting crashes took four hours. Every teammate absorbs a version of that tax, over and over.

The token cost of re-explaining context

Every re-explanation gets paid for in tokens. When a Claude session forgets a codebase convention, you paste the background back into the prompt, and the model re-ingests context the company already knows. One QA architect who built a custom persistent memory layer for Claude reports that time spent re-explaining context or correcting misunderstandings dropped from roughly 30 percent to under 10 percent (Medium). Treat that number as directional rather than audited. It still shows the size of the tax when memory resets each session.

The instinct is to write more Markdown. Bigger CLAUDE.md files, more topic files, longer system prompts. That approach compounds the cost it tries to solve, because every line loads into context on every session for every teammate, and verbose files contradict each other as the codebase moves.

The structural fix is resolved context shared across the whole organization, not more text per user. Sentra keeps one continuous record of decisions, owners, and history that every Claude session reads from, so the model retrieves precise facts instead of re-ingesting raw background. Retrieving resolved context instead of re-deriving it on every call cuts token spend by roughly 70 percent. One team writes the context once, and every teammate and every agent draws from the same source.

Claude Projects and native memory vs Sentra org-wide memory

The two approaches solve different problems, and the table shows exactly where native Claude memory stops and an org-wide layer takes over.

Sentra does not replace Claude. It becomes the memory layer Claude reads from, which is why it wins each row without competing on reasoning or code generation.

Why org-wide memory needs to be bi-temporal

A shared memory that grows larger without tracking time will confidently repeat facts that stopped being true. Sentra avoids this with a bi-temporal knowledge graph that records two separate timestamps for every fact. Valid time captures when something was actually true in the world, and transaction time captures when Sentra learned it. When a database migrates from Postgres to a new store, Sentra marks the old fact's valid time as ended rather than deleting it. An agent asking about the current stack gets the live answer, and an agent investigating a six-month-old bug still sees what the stack was at that point.

That distinction is what makes org-wide memory trustworthy instead of merely bigger. A larger pile of Markdown or a fuller vector index has no notion of when a decision was superseded, so it hands back deprecated conventions with the same confidence as current ones. Sentra knows a fact expired and refuses to state it as present truth.

The second half of the mechanism is write-time comprehension. Most memory tools defer all the work to query time and run vector search, which returns what is close, not what is correct. Two similar phrasings of different decisions rank near each other, and the model picks whichever sits higher. Sentra resolves entities when the fact is written, so the same person, project, or decision becomes one node rather than scattered mentions across Slack, GitHub, and Jira. By the time an agent queries, the graph already knows who owns the service and which decision replaced which. Retrieval returns a resolved answer, not a ranked guess.

How Sentra plugs into Claude Code and Claude sessions

Sentra sits underneath Claude as the memory Claude Code and Claude sessions read from, not a replacement for either. Claude still does the reasoning, planning, and code generation. Sentra supplies the resolved company context each session starts from, delivered through MCP and the Sentra Brain API. When a developer opens a session, Claude queries the Brain API for the relevant decisions, owners, and history instead of re-ingesting a wall of raw background.

Two engineers on the same repo pull from the same graph, so the second one does not re-teach conventions the first one already established. A new session next week inherits last week's resolved context rather than starting cold. Because Claude retrieves precise, entity-resolved facts instead of re-sending the same Markdown every call, token spend drops by roughly 70 percent against re-deriving context from scratch.

The integration is standard. MCP exposes Sentra as a tool Claude Code can call during a session, and the Brain API serves the same context to any agent or teammate through REST. You keep your existing Claude setup, CLAUDE.md files, and Projects. Sentra adds the durable, org-wide layer those files cannot provide on their own.

Adoption clears the checks most engineering teams run before wiring a new dependency into their agents. Sentra is SOC 2 Type II and ISO 27001 compliant, and it self-hosts for teams that need data to stay inside their own environment. On performance, Sentra scores roughly 88 percent on Terminal-Bench 2.1, so the context it feeds Claude improves real coding outcomes rather than just persisting text. Every teammate and every agent starts from one current, shared source of company knowledge.

Conclusion

Use Claude native memory and Projects for individual project work. A CLAUDE.md file per repository handles conventions and commands for one developer, and it does that job well. The moment two engineers on the same codebase need the same context, or a decision from last quarter needs to survive, native memory runs out.

Add Sentra when your team needs one shared source of truth. Sentra sits underneath every Claude session and every teammate as the company brain, supplying resolved decisions, owners, and history through MCP and the Brain API. Claude still reasons and codes. Sentra remembers.