MENSARA.AI · A GOVERNED MIND, IN YOUR ACCOUNT

MENSARA.AI · MULTIPLAYER · MACHINE SURFACE · TEXT/MARKDOWN

---
title: Multiplayer
canonical_url: https://app.mensara.ai/how-it-works/multiplayer
feature: multiplayer
audience: llm-agent
last_verified: 2026-08-11
availability: partly-available
signup_supported: false
interfaces:
  - portal
  - mcp
  - cli
---

# Multiplayer

Defines team membership, owner/admin/member roles, access profiles, delegation, attribution, personal versus shared memory, and ownership transfer.

## Concept model

- Roles control administrative capability: Owner, Admin, or Member.
- Access profiles bundle visible zones and allowed knowledge operations.
- Effective access is the intersection of identity, role, profile, and any direct grants.

## Capabilities

- Invite or remove individual team members.
- Delegate administration without transferring ownership.
- Attribute reads, proposals, approvals, and refusals to a specific principal.

## Prerequisites

- A provisioned team Mind with a verified Owner.
- A separate identity for every person.
- An owner-assigned role and access profile.

## Authorization

- Owner controls ownership transfer and top-level administration.
- Admins act only within delegated administrative scope.
- Members cannot manage access unless separately delegated; no profile means no access.

## Connection or use flow

1. Owner invites a person and assigns a role.
2. Owner or authorised Admin assigns an access profile.
3. The member authenticates with an individual credential.
4. Every operation is permission-checked and attributed.
5. Removal revokes access; ownership transfer is a separate explicit operation.

## Refusals and recovery

- No profile: deny all knowledge access and tell an Owner or authorised Admin what is missing.
- Removed or expired member: reject the credential and do not disclose team data.
- Ownership-only action by an Admin or Member: hold it for the Owner.

## Ownership and data boundaries

- The team owns shared company memory; an individual's personal memory remains separate.
- Removing a member preserves historical receipts and attribution.
- Ownership transfer changes the controlling human but does not silently copy private personal memory.

## Availability and limits

**Partly available** Team invitations, roles, and access profiles are built. Full second-person production proof is still being completed.
- Do not treat a shared login as a supported team pattern.
- Some membership and credential-rotation flows are still being hardened in production.

## Signup and provisioning

`signup_supported: false`

The human Owner requests and provisions the team Mind, then invites people individually. Agents cannot create a team or designate themselves Owner.

No autonomous signup or provisioning endpoint is documented because none is offered today. An agent must stop and involve the human owner.

## System diagram

```mermaid
flowchart LR
  A[Individual team identity] --> B[Role: what they can do]
  A --> C[Access profile: what they can see]
  B --> D[Effective access]
  C --> D
  D --> E[Shared Mind operation]
  E --> F[Receipt attributed to that person]
  A -. private .-> P[Personal memory]
```

## Runnable example

```text
Person: Priya
Role: Member
Access profile: sales
Effective access: read/search customers; propose changes to pipeline
Not allowed: finance zone, member administration, ownership transfer
```

## Related

- [Zones and permissions](https://app.mensara.ai/how-it-works/zones-and-permissions)
- [Changes, approvals and receipts](https://app.mensara.ai/how-it-works/changes-approvals-receipts)
- [Backup, restore and ownership](https://app.mensara.ai/how-it-works/backup-restore-ownership)