# OpenWork Roadmap: Desktop-First to Cloud-Native Workspace Evolution

> Explore the OpenWork roadmap, detailing its evolution from desktop-first to cloud-native workspaces. Discover planned features like hosted workspaces and multi-surface support.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: roadmap
- Published: 2026-08-05

---

**OpenWork's roadmap describes a three-layer evolution from local desktop workspaces to portable cloud-native capabilities, with hosted workspaces and multi-surface support planned for 2025.**

The OpenWork project maintains a public, code-driven roadmap that tracks the evolution of its AI workspace platform. This roadmap spans the desktop application, OpenWork Connect portability layer, MCP specification compliance, central cloud management, hosted workspaces, and future surface expansions.

## Understanding the OpenWork Roadmap Structure

The roadmap organizes development across **six capability layers**, each with clear status tiers: **Live** (shipping), **Partial** (incomplete), **Building** (active development), **Next** (planned), and **Exploring** (under consideration).

### Desktop App: Core Workspace Experience

The desktop application serves as OpenWork's primary workspace. Currently live features include:

- Full-featured local workspace for macOS, Windows, and Linux
- Skills, plugins, MCPs, and connected services
- Organization-managed capabilities
- Built-in browser control and artifacts
- Partial implementation of isolated sandbox workspaces

Active development focuses on **better organization for long-running work**, addressing friction in managing extended sessions.

### OpenWork Connect: Portable Capability Layer

**OpenWork Connect** extends desktop capabilities into external AI agents. This MCP client layer is already live for:

- Claude Code, Codex, Cursor, and OpenCode integration
- Organization marketplaces with shared and per-user authentication

The team is currently **building Git-based publishing and automatic sync** to streamline capability distribution across teams.

### MCP Specification Compliance

OpenWork implements the **Model Context Protocol (MCP)** authorization specification, enabling plug-and-play enterprise gateway connections.

| Status | Capabilities |
|--------|--------------|
| **Live** | OAuth 2.1 self-discovery, PKCE, resource indicators, silent session renewal, manual client-credentials fallback |
| **Building** | `application_type` declaration, client-ID metadata docs, issuer-bound credentials |
| **Next** | Authorization hardening, URL-based client IDs in OpenWork Cloud |

This dual client/server MCP implementation allows OpenWork to bridge desktop workspaces with enterprise infrastructure.

## Roadmap Implementation in Source Code

The roadmap is not static documentation—it is a **shared visual component** synchronized across the entire codebase.

### Core Component: `OpenWorkRoadmap`

In [`packages/ui/src/react/roadmap.tsx`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/roadmap.tsx), the `OpenWorkRoadmap` component renders the visual roadmap from a typed data structure:

```tsx
import { OpenWorkRoadmap } from "@openwork/ui/react";

export default function RoadmapPage() {
  return (
    <section data-testid="openwork-roadmap">
      <OpenWorkRoadmap />
    </section>
  );
}

```

The component consumes `roadmapSections`, an exported array that defines each section, its items, and their status. Updates to the underlying markdown file propagate automatically to all consuming surfaces.

### Programmatic Roadmap Access

Developers can import and query roadmap data directly:

```ts
import { roadmapSections } from "@openwork/ui/react";

// Example: list all upcoming items
const upcoming = roadmapSections.flatMap(s =>
  s.items.filter(i => i.status === "Next" || i.status === "Exploring")
);
console.log(upcoming);

```

The exported types—`RoadmapSection`, `RoadmapItem`, and `RoadmapStatus`—provide full TypeScript coverage for integration workflows.

### Single Source of Truth: `roadmap.mdx`

The definitive roadmap content lives in `packages/docs/roadmap.mdx`. This markdown file is parsed into the `roadmapSections` data structure, ensuring:

- One update propagates to landing page and documentation site
- Version control tracks roadmap evolution
- Community contributions follow standard pull request workflows

Both [`ee/apps/landing/app/roadmap/page.tsx`](https://github.com/different-ai/openwork/blob/main/ee/apps/landing/app/roadmap/page.tsx) and [`ee/apps/landing/app/docs/roadmap/page.tsx`](https://github.com/different-ai/openwork/blob/main/ee/apps/landing/app/docs/roadmap/page.tsx) render this shared component.

## Upcoming Capabilities: Hosted Workspaces and Multi-Surface Reach

### OpenWork Cloud: Central Management

The cloud control plane is fully live with:
- Desktop policies enforcement
- Members, teams, and roles
- Skill and plugin marketplaces
- Anthropic-compatible plugins
- SAML SSO
- Telemetry and OpenTelemetry coverage

### Hosted Workspaces (Building → Next)

Persistent cloud environments represent a major architectural shift:

| Phase | Capabilities |
|-------|--------------|
| **Live** | Remote workspace connections |
| **Building** | Persistent hosted workspaces, reproducible environments, background tasks |
| **Next** | Scheduled workflows, "continue from another surface" functionality |

This enables filesystem state, dependencies, and task progress to survive device shutdowns—critical for long-running AI-assisted workflows.

### Multi-Surface Expansion (Next / Exploring)

OpenWork plans to extend beyond desktop and existing AI agents:

- **Next**: Slack integration, mobile applications
- **Exploring**: Email and messaging interfaces, custom organization agents

## Architectural Principles Driving the Roadmap

The roadmap reflects four core design decisions visible in the source:

1. **Local-first, cloud-ready** — Desktop remains the primary workspace; cloud extends rather than replaces it
2. **MCP-driven portability** — Standard protocol ensures capabilities work across any compatible surface
3. **Centralized policy propagation** — OpenWork Cloud settings automatically apply to all connected clients
4. **Extensible surface model** — New interfaces (Slack, mobile, custom agents) consume the same capability layer

## Key Files in the Roadmap System

| File | Purpose |
|------|---------|
| `packages/docs/roadmap.mdx` | Definitive markdown source for roadmap content |
| [`packages/ui/src/react/roadmap.tsx`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/roadmap.tsx) | React component and typed data exports |
| [`packages/ui/src/react/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/index.ts) | Public API re-exports |
| [`ee/apps/landing/app/roadmap/page.tsx`](https://github.com/different-ai/openwork/blob/main/ee/apps/landing/app/roadmap/page.tsx) | Landing page route |
| [`ee/apps/landing/app/docs/roadmap/page.tsx`](https://github.com/different-ai/openwork/blob/main/ee/apps/landing/app/docs/roadmap/page.tsx) | Documentation site route |
| [`packages/docs/README.md`](https://github.com/different-ai/openwork/blob/main/packages/docs/README.md) | Integration guidance for the roadmap component |

## Summary

- OpenWork's roadmap spans **six capability layers** from desktop to multi-surface expansion
- The **OpenWorkRoadmap** component in [`packages/ui/src/react/roadmap.tsx`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/roadmap.tsx) provides a **single source of truth** across landing and documentation sites
- **MCP specification compliance** enables enterprise integration through standardized authentication flows
- **Hosted workspaces** (currently building) will add persistent cloud environments with scheduled workflows planned next
- The roadmap data structure exports **full TypeScript types** for programmatic consumption

## Frequently Asked Questions

### Where is the OpenWork roadmap defined?

The definitive source is `packages/docs/roadmap.mdx` in the repository root. This markdown file contains all roadmap sections, items, and status assignments. It is parsed into a typed data structure consumed by the `OpenWorkRoadmap` React component.

### How do I embed the OpenWork roadmap in my own application?

Import `OpenWorkRoadmap` from `@openwork/ui/react` and render it directly. For custom integrations, import `roadmapSections` to access the raw data with full TypeScript typing via `RoadmapSection`, `RoadmapItem`, and `RoadmapStatus` interfaces.

### What does "Building" status mean on the OpenWork roadmap?

"Building" indicates **active development** with partial availability. Unlike "Live" (fully shipped) or "Next" (planned), Building features are implemented but incomplete—such as the current Git-based publishing system for OpenWork Connect.

### When will Slack and mobile support arrive?

Slack integration and mobile applications are marked **Next** in the roadmap, indicating committed planning without active engineering. These follow the completion of hosted workspaces and scheduled workflows, which are currently in Building status.