Project tags — keeping multi-project memory clean
Tag every memory with a project slug. Filter searches by project. Avoid the 'all my projects bleed into each other' failure mode.
Project tags
Memory across one project is great. Memory across ten projects is a mess if you do nothing. Without tags, a search for "the deploy script" returns the right answer for project A, the wrong answer for project B, and the half-correct answer for client C — and Claude has no way to know which is which.
The fix is simple: every memory write carries a project tag. Every search filters by it. Two-line change to your CLAUDE.md, and the rest is automatic.
Step 1: Pick your project slug convention
A slug is short, lowercase, hyphenated. One per project. Examples:
- Main side project →
acme-app - StudioMeyer marketing site →
studiomeyer - Customer A internal tool →
kunde-a - Personal experiments →
personal
The slug never changes. Pick something durable. "the-cool-new-thing" ages badly. "wedding-2026-rsvp" ages fine.
For multi-tenant CRM-style work where every customer is its own scope, the convention kunde-{customer-name} is what we use. AI agents on the StudioMeyer setup all carry the project tag of the customer they are working with so notes never leak across customer boundaries.
Step 2: Add the tag rule to CLAUDE.md
Per project, in the project's own CLAUDE.md:
## Memory
Project slug: `acme-app`. Always pass `project: "acme-app"` to nex_learn / nex_decide / nex_entity_create. When searching with nex_search, default to `project: "acme-app"` unless I explicitly ask for cross-project context.
Globally in ~/.claude/CLAUDE.md:
## Memory hygiene
When you write to memory (nex_learn, nex_decide, nex_entity_create) always include the project field. Take the slug from the current repo's CLAUDE.md. If no slug is defined, ask before writing.
That global rule is the safety net. The per-project rule is the convenience. Together they mean every save is correctly tagged without you having to think about it.
Step 3: First tagged save
In a Claude Code session, from inside the repo:
Save to memory (project=acme-app): The deploy script lives in scripts/deploy.sh. It runs prisma generate, then docker compose build, then ssh prod 'docker compose up -d'.
Claude calls nex_learn with { content: "...", project: "acme-app" }. The entry is now tagged.
For decisions:
Decision (project=acme-app): We chose Supabase Frankfurt over self-hosted Postgres because we need IPv4 add-on for the production server.
nex_decide writes it with the project tag.
Step 4: Verify and filter-search
Run aiguide_validate_step. The validator confirms a memory MCP is active.
Now test the filter. In a fresh session in the same repo:
What do I know about deploys for this project?
Claude calls nex_search with { query: "deploy", project: "acme-app" }. Only acme-app entries return. The deploy script for project B does not show up.
Then test the cross-project case:
Show me all decisions about Postgres across all projects.
Claude calls nex_search without the project filter, scoped to types: ["decision"]. You see Postgres decisions from acme-app, the SaaS, and personal — useful when you want patterns across your whole stack.
claude mcp list 2>&1 | grep -iE "memory|nex|local-memory|mem0" | head -5
Step 5: The cross-project pattern (what to share, what to silo)
Two things are appropriate to share across all projects:
- Standing personal rules. "Always TypeScript strict, no
any." "Always run tests before push." Those go untagged (or withproject: "global") so they apply everywhere. - Reusable patterns and learnings. "Pattern: when you see error X, the cause is usually Y." Those help across projects.
Everything else gets a project tag:
- Project-specific commands, scripts, paths
- Decisions about a project's stack or architecture
- Customer notes (
project: "kunde-a") - Deploy details, env-var lists, infra notes
The rule of thumb: if the same fact is wrong in another project, tag it.
Step 6: Back-fill old entries (optional)
If you already have memory entries from before you adopted tags, they show up untagged in cross-project searches. Two ways to handle:
- Leave them. Old context will fade with temporal decay. Not worth the effort to re-tag.
- Tag the important ones. Search untagged entries (
nex_searchwithout project filter), pick the 10-20 that still matter, ask Claude to re-save them with the right tag and delete the originals.
For most setups the first option is enough. Memory is a working tool — old entries naturally lose relevance, which is fine.
What you do not get from tags (and what to use instead)
Tags isolate at the search level. They do not give you cryptographic isolation between projects. If your memory MCP is multi-tenant SaaS (memory.studiomeyer.io), the SaaS handles tenant isolation at the database level — your entries are physically separate from anyone else's. Tags are a within-tenant filter on top of that.
For real multi-tenant SaaS where you serve other people's data, the model is shared tables + a tenantId column + database-level Row Level Security policies. That is the architecture under memory.studiomeyer.io itself. You do not implement that for your own personal memory — it is already done for you.