Team Sharing

How to share client minds with team members, set their role, find what they've added, and keep sensitive content behind the right gate.

Overview#

Team sharing lets you grant a teammate (a VA, an internal collaborator, an editor) access to a specific client mind. They get their own login and Coppermind installation; you decide what role they hold on each client.

Default-deny. A team member sees nothing about a client until you explicitly grant access.

Direct write, role-tagged. When your VA stores something, it goes live immediately and gets tagged with their role. You can find every contribution they made later with one search. No approval queue to babysit.

Sensitive content stays gated. Coppermind classifies new memories at write time. Anything flagged sensitive or CMO-only stays hidden from VAs and Viewers, even if they wrote it themselves.

Roles#

What "open" sensitivity means. When a memory is stored, Coppermind looks at its content. If it mentions compensation, terminations, medical/legal, contract dollar amounts, NDAs, SSN/account numbers, or other sensitive topics, the classifier flags it sensitive or cmo-only. Everything else is open. VAs and Viewers see only open.

martech is not a v1 role. The original spec described a separate MarTech persona with credential-vault access, but that requires features we haven't shipped yet. For now, give technical contributors the Editor role. We'll add martech when it actually means something different from editor.

Adding a Team Member#

"Add Sarah to the Acme team as a VA"
"Add mike@example.com to Acme as an editor"

New team members default to viewer if you don't specify a role. Tell Coppermind the role at add time to skip the second step.

"Show me Acme's team"

Returns the full team for the active client mind: customer ID, role, granted date, email, name.

During beta: Ben manually creates accounts for team members. Tell him "I want to add Sarah as my VA on Acme" and he handles signup.

Changing a Team Member's Role#

"Change Sarah's role to editor on Acme"
"Make Mike a viewer for Acme"

update_role mutates the role in place without removing and re-adding. Their access adjusts on the next request.

You cannot change the mind owner's role. Owners are owners. Transfer of ownership is a separate (future) feature.

Removing a Team Member#

"Remove Sarah from Acme"

Soft-revoke: the access row is timestamped with a revoked_at and the team member loses access immediately. Their previously-stored memories stay in the client mind (attribution preserved).

Finding What Your VA Added#

This is the killer feature for D1 (no review queue):

"Search Acme for what Sarah added this week"

Or directly:

search_memory(query: "Acme deliverables", created_by_role: "va")

Returns every memory tagged with created_by_role="va". Combine with a date hint or a topic and you get a tight contribution review without a daily approval inbox.

Why no approval queue? A typical VA stores 10-30 memories/week. A queue you have to triage daily turns into either bulk-approve-without-reading (defeats the safety net) or ignore-the-inbox (the VA's work becomes invisible). Direct write + role tag + filtered search gets you the same oversight without the tax.

Sensitivity at Write Time#

Every new memory runs through a classifier. Approximate categories:

Owners and editors can override classification when needed (a misclassified "salary" mention you actually want shared can be re-tagged later).

VAs and viewers cannot override sensitivity. If a VA writes content the classifier flags cmo-only, the memory is stored as cmo-only and the VA can no longer see what they wrote (only the CMO can). This prevents a VA from labeling sensitive content as open to bypass the read filter.

What Each Role Cannot Do#

Brand voice is always visible to all roles. A VA writing marketing copy needs the brand voice. So does a viewer who's just observing.

Saved meeting briefs are owner-only. They contain stakeholder details and your strategic notes — those don't go to a VA.

Edge Cases#

• Role change mid-session. Takes effect on the next tool call. No session-level cache to worry about.
• One role per team member per client mind. Sarah can be VA on Acme and editor on xScape — that's per-client mind, not per-customer.
• No access at all. If someone tries to search or write on a client they haven't been added to, they're denied -- access is closed by default. Add them to the team first.
• Custom roles. Not supported yet. The four roles cover the primary personas.

Coming Later#

• martech role with credential-vault access and technical-memory routing. Blocked on real martech-specific behavior worth shipping.
• Per-client mind sensitivity overrides (sharing_config.viewer_allowed_types). Today the default-deny model handles all cases we've seen; we'll revisit if a CMO needs to widen VA access on a specific client mind.
• Per-task elevation. "Just for this Q3 launch, Sarah can see everything." More useful than the role mutation surface, but bigger to build.
• Role-aware audit log. Today every write is tagged with created_by and created_by_role. We don't surface a chronological audit yet — search_memory(created_by_role="va") is the workaround until we ship the dedicated audit view.