Building a company OS around the tools your team uses

Part of the Matrix company OS series.

Most companies do not have a shortage of software. They have a coordination problem.

The files are in OneDrive or Google Drive. Client communication is in Outlook or Gmail. Pipeline data is in a spreadsheet or CRM. Project plans live somewhere else. An AI assistant may be available in each product, but every assistant sees only part of the company.

The result is local automation without shared operations. One employee can summarize a document, but the team still has to move information between systems, decide what happens next, and reconstruct the state of a project.

We think the next layer is a company OS: a shared environment where people and agents can work across the tools a company already uses. Matrix OS is moving in that direction.

This post describes the product architecture we want to build. It is a roadmap and design direction, not a claim that every capability below is available today.

Do not replace the systems of record

A company OS should not begin by demanding a migration.

OneDrive may remain the source of truth for documents. Outlook may remain the source of truth for email. A CRM, spreadsheet, or accounting system may remain authoritative for its own records. Matrix should connect those systems to a durable workspace rather than quietly creating another disconnected copy.

That gives us four layers:

This follows the same premise behind agents needing a computer rather than another chat box. The difference is that the computer now belongs to a team and must respect the boundaries of the organization around it.

Integrations should be capabilities, not data dumps

The easiest integration is often the most dangerous: grant broad access, copy everything into a new index, and hope retrieval sorts it out.

We want a narrower model. A Matrix integration should declare specific capabilities such as:

• list files in an approved project folder,
• read a selected document,
• create a draft in a working folder,
• watch a mailbox folder for new messages,
• prepare an email without sending it,
• update one approved field in a deal record.

Microsoft distinguishes delegated access, where an app acts on behalf of a signed-in user, from app-only access, where it acts as itself. Microsoft recommends requesting the least-privileged permissions required and notes that app-only permissions can be broader and more sensitive. That is a useful product constraint, not just an OAuth detail.

Matrix integrations should therefore start with delegated, read-only, and resource-specific access wherever the workflow permits. Broader background access should be explicit, administered, and visible.

You can see the beginning of this capability model in the current Matrix integrations guide. The company OS requires extending it with organization identity, scoped grants, shared ownership, and durable audit records.

A workspace is the shared unit of work

Chat is organized around a conversation. Business work is organized around an outcome.

A mandate, client engagement, hiring process, or monthly close should have a workspace containing:

• its goal and current status,
• connected folders and communication channels,
• a plan with owners and deadlines,
• reusable company instructions and templates,
• agent runs and their outputs,
• pending approvals and completed actions,
• a history colleagues can inspect.

The workspace should not ingest every piece of company data. It should reference the sources needed for the job and materialize only the working state required to complete it.

That makes access understandable. A colleague invited to Project North can see what Project North uses. An agent assigned to a document workflow receives only the capabilities required for that workflow. Revoking a person or integration has a concrete boundary.

The execution model is persistent and interruptible

Business workflows do not fit neatly into one model response. They wait for files, approvals, replies, deadlines, and external systems.

Matrix already treats persistence as a core property of agent work. A Matrix cloud computer keeps files, shells, services, and sessions in one environment. For company workflows, persistence also needs a structured runtime:

1. A trigger creates or resumes a run.
2. The run gathers authorized context.
3. An agent performs bounded work.
4. Policy decides whether it may continue automatically.
5. A person reviews consequential output.
6. The action and its evidence are recorded.
7. The run waits, completes, or escalates.

Every stage must be replayable enough to diagnose and resumable enough to survive an expired token, unavailable API, or delayed colleague.

Shared does not mean everyone can see everything

The company OS needs at least three permission planes:

Workspace access controls which colleagues can enter a project and what roles they have.

Integration access controls which external resources Matrix and its agents may read or change.

Action policy controls which operations require review, such as sending email, sharing a folder, changing a client record, or exporting personal data.

These planes should intersect. A user cannot give an agent access they do not possess. A workspace role does not automatically grant access to every connected system. A technically permitted action may still require company approval.

This is also why logs matter. NIST's Generative AI Profile organizes risk management around governing, mapping, measuring, and managing AI risk. A practical system needs evidence for all four: configured policy, known context, evaluated output, and recorded intervention.

What the first useful version looks like

We do not need to build a universal ERP to make the company OS useful.

A focused first version could provide:

• one organization with members and roles,
• project workspaces created from templates,
• OneDrive and Outlook connections scoped to selected resources,
• persistent agent runs with schedules and event triggers,
• a shared queue of drafts, exceptions, and approvals,
• an activity record linking every action to its source and reviewer.

One complete workflow is more valuable than twenty shallow connectors. A monthly report that reliably gathers project state, drafts the document, routes it for review, and stores the approved result can prove the architecture end to end.

From there, the same primitives extend to client onboarding, KYC collection, follow-up preparation, document assembly, and deal tracking.

The company OS is a coordination layer

Matrix should not become the place where company data disappears. It should become the place where company work becomes legible.

The source systems continue to own their records. Matrix provides the persistent computer, shared workspace, agent runtime, permission boundary, and review surface around them.

That is the path from personal AI tools to operational AI: not one assistant per application, but one trustworthy environment where the company can decide what agents know, what they may do, and how people remain in control.

Continue with how we are building shared agent workspaces for teams, the trust layer for company agents, and the design for a lightweight agent-native CRM.