How we are building shared agent workspaces for entire teams

Part of the Matrix company OS series.

The first generation of AI assistants is personal. You open your conversation, connect your account, and receive an answer that only you can see.

That model breaks when the work belongs to a team.

A colleague needs to know what the agent changed. A project owner needs to approve a client-facing document. Someone going on leave needs to hand over an active workflow without forwarding a pile of prompts. The company needs to remove access when a person leaves while retaining the project record.

Matrix OS already provides a persistent workspace for files, terminals, apps, and agents. The next step is to make that workspace natively shared.

This is a product design for capabilities on our roadmap. It describes how we believe team workspaces should behave, not only what is available today.

The workspace belongs to the project

Personal assistants make the user the owner of every interaction. A shared workspace makes the project the durable owner of its state.

That means a project can outlive:

• one chat session,
• one agent or model,
• one employee's access,
• one device,
• one integration token.

The workspace holds the plan, connected resources, generated artifacts, approvals, and activity history. People and agents join it with scoped roles.

This extends the architecture described in Web 4 is an operating system: interfaces come and go, but the computer and its state persist. For a company, identity and permissions must persist with that state too.

People and agents need different identities

An agent should never appear in the activity log as if it were the employee who launched it.

We need distinct identities for:

• organization members,
• service accounts and integrations,
• agents,
• scheduled workflows,
• external guests.

Every action should record both the actor and the authority behind it. For example: “Reporting Agent created Draft 3 using Maria's delegated OneDrive access; Marcus approved it; the workflow stored the final file.”

That chain is essential for trust. It lets a reviewer answer three different questions:

1. Who or what performed the operation?
2. Which permission allowed it?
3. Which person approved or owned the outcome?

Roles should describe work, not infrastructure

Traditional server permissions are too low-level for most teams. “Can write to this directory” does not explain whether someone may approve a client email.

A Matrix team workspace needs product roles such as:

The names may change, and organizations should eventually be able to customize them. The important point is that permissions map to meaningful actions.

Sharing is more than simultaneous access

Putting multiple people in the same interface is not collaboration. A shared agent workspace needs explicit coordination primitives.

Ownership

Every active run, task, and approval has an owner. “The AI is doing it” is not an ownership model.

Presence and status

Colleagues can see whether work is queued, running, waiting for input, blocked, ready for review, or complete. Matrix already treats long-running sessions as inspectable work; team status makes that legible without opening every terminal.

Handoffs

A handoff transfers responsibility while preserving context. The next person receives the goal, current state, relevant sources, unresolved decisions, and recent actions—not a summary pasted into a new chat.

Review

Review is an object with a proposed action, evidence, risk level, reviewer, decision, and timestamp. It should not be buried in a message thread.

Notification

Matrix can surface the same workspace through different shells. A reviewer might receive a notification in Matrix Messages, open the workspace on mobile, and inspect the full artifact on the desktop.

Integrations must remain user-aware

External systems already have their own access models. The team workspace should preserve them rather than flattening them.

Microsoft Graph's delegated access model limits an application to data the signed-in user can access, while application permissions allow background access without a user. That difference should be visible in Matrix.

A delegated connection might support personal email follow-up drafts. A company-administered application connection might support a shared reporting process. The workspace should show which mode a workflow uses, who consented, what scopes were granted, and when the grant expires or changes.

When a member loses access to a OneDrive folder, Matrix must not keep presenting stale indexed content as if the access still exists. When an integration is disconnected, dependent workflows should stop safely and explain what they need.

Shared memory should be inspectable

Team memory is not one giant vector database.

We see at least four kinds of memory:

• Source references: links to authoritative files, messages, and records.
• Workspace state: plans, owners, statuses, decisions, and approvals.
• Working artifacts: drafts, extracted data, intermediate calculations, and notes.
• Organization knowledge: reusable policies, templates, terminology, and skills.

Each kind has a different retention and permission boundary. Source references follow the source system. Workspace state belongs to the project. Working artifacts may be temporary. Organization knowledge should be versioned and curated.

The current Matrix file system model gives agents and users inspectable artifacts. Team workspaces extend that principle: shared memory should be visible, attributable, and removable.

Activity history is part of the interface

Most products hide audit logs in an administrator screen. For agentic work, the activity record should be part of the everyday product.

A useful project timeline might show:

• a new source file was detected,
• a workflow extracted required fields,
• the agent flagged a missing item,
• a colleague supplied the item,
• the agent generated a draft,
• a reviewer requested a change,
• the final action was approved and completed.

That history is both operational and evaluative. Teams can find bottlenecks, understand why an output exists, and improve the instructions that produced it.

The first team workspace we want to prove

The smallest credible team version is not a general social network. It is one shared project with:

• organization membership,
• a workspace template,
• connected resources,
• assigned agents and owners,
• a common activity timeline,
• a queue for input and approvals,
• permission-aware links to source material.

If a colleague can open the workspace and answer “what is happening, what needs me, and what changed?” without asking the person who started the workflow, we have crossed the important line from personal assistant to company infrastructure.

Shared AI should not mean that everyone shares a chatbot. It should mean that people and agents share an accountable place to work.

Read the broader architecture in building a company OS on existing tools, then see how files can become permission-aware working memory for agents.