Concepts

Governance

How Multiplayer OS keeps agents useful without letting them silently change company knowledge, tools, or external systems.

Governance model

Governance is not a separate admin checklist. It is the operating model for every agent proposal, wiki write, skill install, source sync, and external action.

Governance boundary

Local work only becomes company state after policy, review, and audit are attached.

Local machine

Local agents

Work in user tools

Signals

Files, meetings, sources

Proposals

Structured suggested changes

Review boundary

Queue

Roles and risk tiers

Human decision

Policy-controlled sync

Managed workspace

Company wiki

Approved durable knowledge

Actions

External work after approval

Audit trail

Actor, evidence, outcome

Least privilege

No direct bypass

Rollback-ready records

Local work crosses into the managed workspace through review, with permissions, audit, and rollback attached.

Workspace roles: Owners and managers can approve higher-risk proposals, configure sources, and govern workspace policy.
Agent permissions: Each agent gets scoped read/write access by wiki path, source, skill, and external action type.
Approval queue: Medium-risk or high-risk work waits for a human decision before it reaches shared workspace state.
Risk tiers: Low-risk moments can be saved or surfaced quickly. Changes to shared knowledge, customer systems, permissions, or external messages require review.
Audit trail: Approved actions retain actor, producer, source references, artifacts, decision outcome, and timestamps.

Trust boundaries

Local before shared: A local tool can report a proposal without automatically syncing raw files, transcripts, or chat history.
Propose before write: Agents should propose wiki writes and external actions. The workspace decides what lands.
Credentials stay with the app: Local agents use mos; the app and managed platform handle sign-in, workspace routing, and sync credentials.
Policy before inference: Workspaces can decide which providers may process company data, what must be redacted, and what stays local.

Review decisions

Approve: Commit the proposal to the selected workspace or perform the approved action.
Deny: Record the decision and prevent the proposal from landing.
Request changes: Send the proposal back to the agent or human owner with review context.
Reroute: Change the destination workspace when the local routing guess is wrong.
Rollback: Reverse an approved change when the workspace needs to restore a prior source of truth.

Default posture

Local event reporting is explicit and reversible.
Workspace sync requires sign-in and a selected workspace.
Wiki writes use wiki_write proposals with proposed_write artifacts.
External actions require approval unless workspace policy explicitly allows them.
Raw local data should not be uploaded wholesale; use source refs, excerpts, redaction, and consent.