← cMCP home

Space mapping: putting every person's AI memory in the right place

Paper v0.3 · superseded by the space and memory model v1.1 Fresh design 2026-10-09 v0.2: space IDs, manifest and session routing (user proposal) v0.3: four kinds of actor, digital workers
This paper sets aside what cMCP does today and designs from the problem up. It draws on earlier research (Q-35) and two new research agents (company knowledge graphs and catalogs; space identity and ownership). Nothing was built from this draft directly: it was folded into the space and memory model v1.1, which was built as stages 1l–1t.

1. The problem

2. The idea in one picture

3. Concepts

4. Identifying a space

Rule: the identity of a space is the platform's stable id inside its tenant. Names, URLs, keys and local paths change, so they are only aliases. (Every product studied separates the two: Microsoft drive + item ids, Google file ids, Backstage entity references, OpenLineage namespace + name.)

Address format: space:<kind>:<tenant or host>/<stable id>, plus aliases and an owner side.

5. Identifying who: person, bot, app, agent run

Key point: the caller only says where it is and what it is doing; cMCP works out the rest. A bot or app never claims an org, person, team or project — those come from the credential and the space graph, so they cannot be faked.

Four kinds of actor (added in v0.3, 2026-10-09)

The solid facts:

• 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 (claude.ai, the Claude CLI);
• bots are attached to a person or an agent for a specific task.

The new case is AI workers with their own e-mail, name and ID, a long life (a project or the whole org), working on their own and talking to people and other bots by e-mail or Teams, with a person as master. These are a separate kind of actor. In cMCP they are called digital workers ("AI workers" or "agent identities" elsewhere; "robot" works in conversation).

Why a separate kind, and not a person or a bot.

• A digital worker is a member of places and keeps memory across months, like a person.
• It is not human: no HR data, no Personal memory, accountable to someone else, and limited in what it may decide.
• Treating it as a person would give it powers it must never have.
• Treating it as a task bot would lose its identity and long memory.

Identity providers are moving the same way, giving AI agents their own directory identities. The IETF agent-auth draft also says each agent should have its own identity and calls shared static keys an anti-pattern.

How a digital worker maps into cMCP

1. Created only by an ADMIN, in person. Each one gets a purpose, a master and a backup, the places it is assigned to, an end date, and limits on spend and on calls. A digital worker never creates another one.
2. Its own identity record, like a person's. Its e-mail, Teams, Slack and Jira accounts are linked to it the same way a person's accounts are (section 5). Each credential is its own and short-lived; it never uses its master's.
3. Members of places, with ceilings. It is assigned to projects and teams. It may read and write memory there, but it never becomes ADMIN, never approves or grants anything, and never reads anyone's Personal memory or private work pool.
4. Its own memory.
   • Lanes per space, like a person's, so its items count toward the places it works in.
   • Worker memory, about how it does its job. This is the equivalent of a person's User memory.
5. Its conversations are spaces. A mail thread, Teams chat or Slack channel it works in gets a space address and an owner side like any other space. When it writes to a client, the client's wall applies.
6. Its input is untrusted. Mail and messages from outside, or from other bots, can carry planted instructions. They become memory only as data, never as instructions, never as must-apply items, and reach shared memory only through review.
7. Promotion is decided by people. Its items count in collective memory and are marked AI. But "seen by three or more people" counts only humans, so AI workers can never out-vote people.
8. The chain is stamped on every item. The memory address names the digital worker, its master, and anything it launched: for example "task bot X, launched by digital worker Y, master Alice".
9. Lifecycle.
   • The master reviews it every 90 days.
   • 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 about its places stays with those places, and its worker memory is handed to a successor or archived.
10. It always says what it is. Every message and memory item carries an AI badge and names who it works for.

6. The memory address on every item

The address is written when the item is created and never rewritten. If a link changes later, the item keeps its original address and the new link is applied by version, so history stays honest.

7. Linking people's spaces to organizational places

Four kinds of link

Matching ladder

8. Placement: where a memory item goes

Principle: store once at the origin, count by links. The item is stored in its lane (the person or bot, in that space). Nothing is copied into team or project memory. Links decide what the item counts toward; promotion decides what becomes organizational memory.

Kind of memory also matters: a preference about the person ("Alice prefers short answers") stays personal wherever it was said; a fact about the work ("SHIP deploys use blue-green") follows the space's links. The writer (the app's model, a hook or the bot) marks each item as about the person or about the work; the server checks.

9. Two memories from the same items

10. Space IDs, the space manifest and session routing (user proposal, 2026-10-09)

The flow

1. Register. The company's fixed spaces are registered from connectors and from facts (org, project, team, owner). cMCP issues a space ID for each and links it to its place IDs.
2. Seed. At session start, cMCP sends the app a space manifest:
   • 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, so later changes arrive as small updates.
   It contains only spaces the person belongs to, and client spaces only when the person is assigned to that client.
3. Detect.
   • The helper matches the working folder, every folder change and the file paths the tools touch, all on the person's machine.
   • It tells the app the current space and marks each stretch of the session with the active space ID.
   • Unknown folders get a local marker and a pending question.
4. Post. At checkpoints (after answers, before compaction, at the end), the app posts:
   • its session memory: the notes and facts it made, with the space tags per stretch and the session id;
   • a copy of the session memory, kept as the source. Whole transcripts are kept only under the M-105 rules.
5. Route. cMCP splits the memory into single items and decides each one, using the strongest evidence first:
   • the stretch's space tag;
   • an explicit mention that matches the manifest, such as a repo name, Jira key or path;
   • similarity to that space's memory. This is weak evidence, so it can only make a suggestion.
   Items about the person (preferences, habits) go to their own memory. One item can link to several spaces without being copied.
6. Pool. Anything that can't be routed with enough confidence stays in the person's work pool, which is private. It is routed later when a link appears (late binding), and a weekly digest lets the person sort what remains.
7. Return. The answer says what went where and returns the updated memory for the current space. The next session's manifest includes any new spaces and links.

What the app must confirm before saving, and what it doesn't

A limit to accept: cMCP can't stop a tool writing its own local memory (for example Claude Code's memory files). It can make sure every local note is tagged and copied with the right space ID, because the helper knows the space for each stretch of the session.

11. Discovery: how the graph fills itself

12. Changes over time

Rule: ownership of a memory item follows the owner side of the space when the item was created.

13. Worked examples

14. Data model sketch

15. Rollout in steps

16. Decisions for review

17. Sources