← cMCP home

Space and memory model: placing every memory in the right space

Paper v1.1 · adopted in the build plan (M-106) · built in stages 1l–1t v1.1: indexes and index cards Consolidated and expanded 2026-10-09
This version brings together the space-mapping paper (v0.1–v0.3, including the user's proposals) and a new part on building memory from the content of spaces, in one order. It designs from the problem up, not from what cMCP does today. It is based on seven research agents (four earlier, three for this paper) and the user's decisions. When this was written nothing was built; it has since been built as stages 1l–1t (M-109, M-111), and the build plan records where the build differs.

Summary

1. The problem

Goals:

• Every memory item can answer the seven questions.
• The same space is recognised on every machine and in every tool.
• Nothing personal becomes shared without a person deciding.
• Knowledge from people's work and from the spaces reaches the organization, and comes back to everyone working there.

Not goals (for now): replacing the company's search engine, storing every mail and chat forever, or monitoring people.

2. Design principles

3. Vocabulary

The picture

4. Actors: who creates memory

Solid facts we start from:

• the org is created by the web-admin and has an org ID;
• people are identified by e-mail, name, mobile and ID, and work for the org;
• agents are attached to a person and hold longer conversations with them;
• bots are attached to a person or an agent for a specific task.

The coming case is AI workers with their own e-mail, name and ID, a long life, and a person as master, who talk to people and other bots by e-mail or Teams. They form a fourth kind: the digital worker.

How each actor is identified

Rules for digital workers

1. Created only by an ADMIN, in person. Each has a purpose, a master and a backup, assigned places, an end date, and limits on spend and calls.
2. Never ADMIN. It never approves or grants anything, never reads anyone's Personal memory or work pool, and never creates other workers.
3. Its own short-lived credentials, never its master's.
4. Its conversations are spaces. Its mail threads and chats get space IDs and owner sides like any other space, and a client's wall applies when it writes to that client.
5. Its input is untrusted. Mail and messages from outside or from other bots become memory only as data, never as instructions.
6. It doesn't count as a person for promotion, so AI workers never out-vote people.
7. Lifecycle:
   • its master reviews it every 90 days, and a kill switch pauses it at once;
   • if its master leaves and no new master is named within 7 days, it is paused;
   • at retirement, what it learned stays with its places, and its worker memory goes to a successor or the archive.
8. It always says what it is: an AI badge and who it works for, on every message and item.

5. Places: the company's structure

• Org: created by the web-admin, with an org ID. It is the root of everything.
• Projects and teams: created by the ADMIN or people with the power to create places. These are two separate axes: a project can span teams, and a team can work on several projects.
• Clients: companies the org works for. Each sits behind a wall: one client's memory never reaches another.
• Members: people and digital workers are members of places with a role. Agents and task bots are never members; they work within their person's or launcher's places.

Places have their own IDs. A space links to places; the place tree (team → project → org) then gives the full path. The person's relation to a space always comes from their membership, which is why the person is never part of a space ID (decided by the user, 2026-10-09).

6. Spaces: identity, owner side and registration

Space address and space ID

The identity of a space is the platform's stable id within its tenant: space:<kind>:<tenant or host>/<stable id>. cMCP issues a short space ID for each address, and every alias (URLs, keys, names, local paths) points to it.

Registration

• Company tenants are registered once: Bitbucket workspace, GitHub organization, Google domain, Microsoft tenant, Slack enterprise, Atlassian site. Every space inside them is company-owned. Client tenants are registered as clients.
• Company spaces come in through connectors (repos, Jira projects, shared mailboxes, channels, shared drives), are kept current by webhooks, and can also be registered as facts (org, project, team, owner).
• People's spaces are reported by their apps and helpers (folder fingerprints, tool project ids), or found through personal accounts they connect.

7. Linking spaces to places

Matching ladder

8. The space manifest and the helper (user proposal, adopted)

cMCP seeds every app that creates memory with the person's space IDs at session start, so the app knows from the beginning where it is and what to confirm.

• Content: the person's space IDs, each with its recognisers (remote URLs, root commits, host ids, folder markers, Jira keys, Drive folder ids, chat project names) and its place path. A version number lets later changes arrive as small updates.
• Scope: only spaces the person belongs to, and client spaces only when the person is assigned to that client. For real company accounts it goes only to apps on the account's allowed list.
• Matching is done by the helper, not the model. A small helper (a hook or local bridge) matches the working folder, every folder change and the file paths the tools touch, all on the person's machine. The model is only told the result: "you are in Shipping (sp_ship_api)". Models can skip instructions; the helper always runs.
• Asking: only when a space is unknown, and only once ("link to Shipping / keep private / later"). The answer is remembered on every machine. Work is never blocked, except in client spaces where policy says so.

9. Session routing and the work pool

1. Detect: the helper tags each stretch of the session with its space ID.
2. Post: at checkpoints (after answers, before compaction, at the end), the app posts its session memory (notes and facts, with the stretch tags and the run id) and a session copy as the source. Whole transcripts are kept only under the rules of M-105.
3. Route: cMCP splits the memory into single items and decides each one, using the strongest evidence first:
   1. the stretch's space tag;
   2. an explicit mention that matches the manifest, such as a repo name, Jira key or path;
   3. similarity to a space's memory, as a suggestion only.
   Items about the person (preferences, habits) go to their own memory, and items about the work follow the space. One item can link to several spaces without being copied.
4. Pool: what can't be placed with enough confidence stays in the person's private work pool. It is placed later when a link appears, and a weekly digest lets the person sort the rest.
5. Return: the answer says what went where and returns the updated memory for the current space.

A limit: cMCP can't stop a tool writing its own local memory (for example Claude Code's memory files). But the helper knows the space for every stretch, so every local note can be tagged and copied with the right space ID.

10. The memory address on every item

The address is written when the item is created and is never rewritten. If a link changes later, the new link applies by version.

11. Placement: where an item goes

12. Two memories from the same items

13. Space knowledge: building memory from the content of spaces

Sections 8–12 cover memory that AI apps create while people work. Spaces also hold knowledge themselves: mail threads, channel conversations, documents, issues, commits. This section covers how cMCP turns that content into memory.

Four layers

Kinds of space memory, and who they help

Where space memory is stored and who sees it

• Lane: space knowledge is stored once, in the space's own lane: the source is the space, and the authors are recorded as evidence. It counts toward the places the space is linked to, like any other item (P5).
• Access: a derived record is visible only to people who can see all of its sources (the intersection of the source audiences), and access is checked again on every read. A digest of a private channel is visible only to that channel's members.
• Deletion: deleting a source, a permission change, retention or a legal hold flows down to every record built from it.
• Into organizational memory: decisions, facts and procedures from company spaces join the place's collective memory automatically, marked with their source. They become organizational memory only when the lead approves (one click, from the decision log or digest). Status signals from Jira or Git are trusted directly.

Sources: what is on by default

Processing

1. Sync by changes only: Microsoft Graph delta links, Gmail history ids and webhooks, with a full re-sync when a change token expires (Gmail keeps history for about a week).
2. Clean without any AI: strip quotes, signatures and disclaimers; drop duplicates by hash and message id; resolve people by address.
3. Filter by rules: drop newsletters, notifications, bot messages and one-line replies, so the slow local model only sees the small share worth reading.
4. Extract when a thread goes quiet (for example after 2 hours), one message at a time with its thread context. Use a fixed JSON format, keep a quote and line reference, and resolve dates like "next Friday" against the message date.
5. Synthesise on a schedule: decision log and project status nightly, digests weekly, "who to ask" from counts.
6. Reconcile: newer facts mark older ones as replaced, with dates. Duplicates add a confirmation instead of a copy.

What the local model can and can't do

Until a bigger model is approved, synthesis uses rules and the simple records, and real accounts stay on the local model only (M-46). Every extracted record carries its extractor version, so it can be re-extracted later with a better model.

14. Indexes: a searchable card for every category

Yes. cMCP keeps one searchable index per category, in two groups. They work the way Claude's own memory index works, at company scale.

Every index can be searched by keyword and by meaning. Every entry carries its audience, so a search only returns what the person asking may see. A link graph ties the indexes together: who is a member of what, which space is linked to which place, who created an item and in which space, what each record is about, and which source it came from.

Like Claude's memory index, at company scale

Claude Code keeps a short index file (MEMORY.md): one line per memory, loaded in every session, with the details in separate files that are opened only when needed. cMCP does the same with index cards:

• A card is a short summary of one entry in a catalog index: a person, a place or a space. Every line in it points to the memory or knowledge items behind it.
• At session start, the app gets the space manifest (section 8) plus the cards for the person and their current place. That's a few hundred tokens.
• Everything else is fetched only when needed, through search. That keeps the AI fast and cheap, and it never gets more than it needs.
• Cards are generated from the indexes (nightly, and whenever something changes). Nobody writes them by hand, but a lead can pin a line.

How a question is answered

1. Resolve who and where in the catalog indexes: "canary" is a topic, "we" means Alice's places, and Shipping has three spaces.
2. Filter to the places and spaces the asker may see, including client walls.
3. Search the memory and knowledge indexes within that scope, by keyword and meaning together.
4. Follow links to the evidence and the source text.
5. Answer with sources: "Blue-green with a 5-minute canary — decided 3 Oct in #shipping (Alice); confirmed by 7 people's notes."

How it is stored: the catalog tables (section 18) are the truth. Each index is a search view over them, with keyword and meaning search, built and rebuilt separately for each category. The link graph lives in the same database. Cards are stored with their version and source references, so an answer can always show where each line came from.

15. Changes over time

Rule: ownership of an item follows the owner side of its space when the item was created.

16. Security and privacy

17. Worked examples

18. Data model sketch

Every table carries the account and org, and keeps them apart with row-level security.

19. Rollout in steps

20. Decisions

21. Sources