# Main Services and Modules in OpenWork: Desktop-First AI Architecture Explained

> Explore OpenWork's main services and modules including desktop runtime, OpenWork Den, MCP integration, shared types, and auxiliary services. Understand its desktop-first AI architecture.

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

---

**OpenWork is organized into five distinct architectural layers: a desktop runtime built on Electron, a cloud control plane called OpenWork Den, an MCP (Model Control Plane) integration layer, shared TypeScript type definitions, and auxiliary services including email and provider adapters.**

OpenWork by different-ai is a desktop-first AI workflow platform that combines local execution with cloud governance. Understanding the main services and modules in OpenWork is essential for developers extending the platform or integrating with its MCP-based service architecture. The codebase follows a modular monorepo structure that separates concerns between the local Electron runtime, organizational management APIs, and standardized AI service integrations.

## Desktop Runtime Layer

The **desktop runtime** provides the local execution environment for AI workflows. Built on Electron, this layer handles the main process, API gateway, and user interface components.

### Server Process

The Electron main process and API gateway reside in [`apps/server/src/server.ts`](https://github.com/different-ai/openwork/blob/main/apps/server/src/server.ts). This file initializes the HTTP/IPC server, loads plugins, and manages the local workspace state. When OpenWork starts, this module sets up the routing infrastructure that connects the UI to local and remote services.

### UI Component Library

Reusable React components are packaged separately in [`packages/ui/src/react/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/index.ts). This separation allows the desktop application to consume a consistent design system while keeping the UI framework agnostic from the core server logic. The package exports theme configurations, workspace dialogs, and capability selection interfaces used across the application.

## Cloud Control Plane (OpenWork Den)

**OpenWork Den** provides centralized tenancy, policy management, and model-provider governance for teams and organizations.

The Den API, located at [`ee/apps/den-api/src/routes/org/plugin-system/store.ts`](https://github.com/different-ai/openwork/blob/main/ee/apps/den-api/src/routes/org/plugin-system/store.ts), exposes REST endpoints for organizational management. This module handles plugin system storage, team configuration, and MCP connection policies. When organizations need to enforce usage policies or share curated AI service catalogs, the desktop runtime queries these endpoints to synchronize org-level settings.

## MCP Integration Layer

The **Model Control Plane (MCP)** integration layer standardizes how agents and plugins discover, authorize, and invoke external AI services like OpenAI, Azure, and Ollama.

### Enterprise MCP Client

The core SDK lives in [`packages/enterprise-mcp-client/src/enterprise-mcp-client.ts`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-client/src/enterprise-mcp-client.ts). The `EnterpriseMcpClient` class manages service discovery, OAuth flows, and tool catalog caching. Desktop applications and remote agents instantiate this client to communicate with the MCP, fetching available capabilities and executing tool calls through a unified interface.

### Mock Server for Development

Testing and local development rely on [`packages/enterprise-mcp-mock-server/src/runtime/mock-server.ts`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-mock-server/src/runtime/mock-server.ts). This in-process test double simulates the production MCP, allowing developers to validate integrations without external network dependencies or API rate limits.

### Connection Link Utilities

Secure resource linking is handled by [`packages/connect-link/src/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/connect-link/src/index.ts). These utilities generate cryptographically secure connection URLs and validate inbound links from external services, ensuring that MCP resources are accessed only through authorized channels.

## Shared Type Definitions

Type safety across the desktop runtime, Den API, and MCP layer is enforced through [`packages/types/src/openwork-context.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/openwork-context.ts). This central module defines TypeScript interfaces for workspaces, capability metadata, diagnostic structures, and context objects. By sharing these definitions, OpenWork maintains compile-time contracts between loosely-coupled services, preventing integration errors when the desktop client communicates with cloud APIs.

## Auxiliary Services

Supporting functionality is split into specialized service modules that handle cross-cutting concerns.

### Email Service

The notification system in [`packages/email/src/send-email.ts`](https://github.com/different-ai/openwork/blob/main/packages/email/src/send-email.ts) renders and delivers templated HTML messages. It handles invitation flows, policy change alerts, and system notifications. The module exports `renderInvitation()` for template generation and `sendEmail()` for delivery, abstracting the underlying transport mechanism.

### Provider Adapters

Bridge code in [`apps/server/src/opencode-plugins/openwork-provider-adapters.ts`](https://github.com/different-ai/openwork/blob/main/apps/server/src/opencode-plugins/openwork-provider-adapters.ts) maps MCP-exposed services to local provider implementations. These adapters translate between the standardized MCP protocol and the specific requirements of local AI providers, enabling the desktop UI to consume remote services as if they were local capabilities.

## Code Examples

### Listing Available MCP Services

```typescript
import { EnterpriseMcpClient } from 'packages/enterprise-mcp-client/src/enterprise-mcp-client';

async function listServices() {
  const client = new EnterpriseMcpClient({ baseUrl: 'https://api.openworklabs.com/mcp/agent' });
  const catalog = await client.fetchToolCatalog();
  console.log('Available services:', catalog.map(s => s.id));
}

listServices();

```

### Creating a Workspace from the Desktop Runtime

```typescript
import { createWorkspace } from 'apps/server/src/workspaces';

async function initDemoWorkspace() {
  const ws = await createWorkspace({
    name: 'Demo',
    description: 'A quick-start workspace',
    initialSkillIds: ['openai-image-generation-service'],
  });
  console.log('Workspace created at', ws.path);
}

initDemoWorkspace();

```

### Sending Invitation Emails

```typescript
import { renderInvitation, sendEmail } from 'packages/email/src/index';

async function inviteUser(email: string) {
  const html = renderInvitation({
    invitee: email,
    inviter: 'alice@example.com',
    joinUrl: 'https://app.openworklabs.com/join?token=XYZ',
  });
  await sendEmail({ to: email, subject: 'You’re invited to OpenWork', html });
}

inviteUser('bob@example.com');

```

## Summary

- **Desktop Runtime**: Electron-based local execution environment split between [`apps/server/src/server.ts`](https://github.com/different-ai/openwork/blob/main/apps/server/src/server.ts) (main process) and `packages/ui` (React components).
- **OpenWork Den**: Cloud control plane in `ee/apps/den-api` providing organizational governance and policy management.
- **MCP Integration**: Standardized AI service layer comprising the enterprise client, mock server for testing, and secure connection utilities.
- **Shared Types**: Centralized TypeScript definitions in [`packages/types/src/openwork-context.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/openwork-context.ts) ensuring type-safe communication across modules.
- **Auxiliary Services**: Email templating/delivery and provider adapter patterns that bridge MCP protocols to local implementations.

## Frequently Asked Questions

### What is the difference between OpenWork Desktop and OpenWork Den?

OpenWork Desktop refers to the Electron-based runtime that executes locally on user machines, handling workspaces and plugin execution. OpenWork Den is the cloud control plane that provides organizational features like team management, policy enforcement, and centralized MCP connection governance. The desktop runtime optionally connects to Den for enterprise features while maintaining local-first execution.

### How does the MCP integration layer standardize AI service access?

The MCP integration layer uses the `EnterpriseMcpClient` class to provide a uniform interface for discovering and invoking AI services. Rather than implementing separate adapters for each provider (OpenAI, Azure, Ollama), developers interact with the MCP client which handles OAuth, capability cataloging, and request routing. This abstraction allows plugins to work with any supported provider through a consistent API.

### What is the purpose of the enterprise-mcp-mock-server?

The mock server in [`packages/enterprise-mcp-mock-server/src/runtime/mock-server.ts`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-mock-server/src/runtime/mock-server.ts) provides an in-process simulation of the production MCP for local development and CI testing. It eliminates external dependencies and API rate limits during development, allowing engineers to test capability discovery and tool invocation workflows without network access or live service credentials.

### Where are workspace and capability types defined in the codebase?

Core type definitions reside in [`packages/types/src/openwork-context.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/openwork-context.ts). This module exports TypeScript interfaces for workspace metadata, capability structures, and diagnostic objects. By importing from this shared package, both the desktop runtime and cloud Den API maintain type compatibility, ensuring that data exchanged between local and cloud services adheres to the same structural contracts.