OpenWork Is Betting the AI Agent Should Be the Replaceable Part

AI agents are multiplying faster than the workflows people build around them. A team can configure one client with skills, connect another to MCP servers, teach a third its project conventions, and then discover that much of the useful setup is trapped inside whichever agent it chose first. OpenWork is built around a different assumption: the agent should be replaceable.

OpenWork is a cross-platform desktop app and MCP-backed capability layer for sharing AI workflows. Its latest desktop release, v0.18.25, shipped on August 15. The project describes itself as an open-source alternative to Claude Cowork and Codex, but that comparison undersells the more interesting part of its design: the desktop app is optional. OpenWork wants the same capabilities to remain available when a user moves between Codex, Claude Code, Cursor, OpenCode, or another compatible agent.

That turns the project into a test of a broader idea. As model and agent clients become easier to swap, the durable layer may be the collection of skills, tools, permissions, connections and workflows that sits behind them.

The workflow lives behind the agent

Most agent products naturally accumulate their own operating environment. A user adds an MCP server, installs a skill, signs into a service, configures a prompt, grants permissions and teaches the client how work should be done. Even when the underlying model is replaceable, the surrounding setup creates switching cost.

OpenWork tries to move that environment one layer back. Its README says one OpenWork MCP can bring assigned skills, plugins, MCP connections, Google Workspace and Microsoft 365 capabilities into any compatible agent. A user can keep working in an existing client instead of treating OpenWork's desktop interface as the mandatory place where every task begins.

The important unit of portability is therefore not the conversation transcript. It is the capability: something the agent is authorized to discover and use regardless of which compatible shell is currently asking for it.

A narrow capability rail instead of a giant tool list

At the center of OpenWork's MCP design are two generic operations: search_capabilities and execute_capability. The first discovers what the current user is allowed to use; the second invokes an exact capability returned by search. The current server instructions explicitly tell agents to search before concluding that something is unavailable.

That is a more consequential design choice than it first appears. Instead of permanently exposing every connected service as another top-level tool, OpenWork can put a growing catalog behind a discovery layer. Its capability architecture describes native provider operations, external MCP connections and marketplace content riding the same rail, with access controls determining what each member can see.

In principle, this can reduce the amount of tool schema an agent must carry before it knows what the task requires. It also creates a single place to apply authorization and connection state. The tradeoff is that search quality becomes part of the execution path: if a capability is poorly described or hard to discover, portability on paper will not translate into a smooth workflow.

OpenWork is also selective about what becomes agent-callable. Its Den MCP policy excludes authentication plumbing, internal admin surfaces, webhooks and several credential-sensitive operations from broad exposure. That separation matters if the same capability layer is expected to serve both individual agents and organizations.

The desktop app is optional — and that is the point

OpenWork still ships a full desktop application for macOS, Windows and Linux. It can be the dedicated workspace for people who want one. But making that interface optional changes the competitive framing.

If a team prefers Codex for one task and Claude Code for another, OpenWork does not need to win the argument over which client becomes the permanent front end. It can instead try to remain behind both. The user keeps the agent interface they prefer while the shared capability layer carries the operational setup.

This is different from a conventional 'open-source alternative' strategy. A clone wins by replacing the incumbent application. A portable capability layer can succeed even when the incumbent application remains in use.

Portability becomes an organizational problem

OpenWork's Den layer extends the idea from an individual's configuration to a team's operating environment. The project says administrators can provision model providers, manage members and teams, set desktop policies, control local model access, publish skills and plugins, and assign capabilities to an organization, team or specific person.

Den can also import Anthropic-compatible plugins and make supported skills and remote MCPs available through the OpenWork connection. This is where the project starts to look less like a desktop agent and more like a control plane for distributing what agents are allowed to know and do.

For organizations, that is potentially more valuable than synchronizing a few local settings. An agent can be replaced because the organization's capabilities, access rules and service connections do not have to be rebuilt from scratch inside the replacement.

Portable capabilities do not guarantee portable behavior

There is an important limit to this argument. Connecting the same capability to two agents does not make those agents behave the same. They can differ in planning, prompting, context management, tool-selection discipline, approval UX, retries and how they interpret the result of a tool call.

OpenWork also depends on the surrounding interoperability layer. A client must support the relevant MCP connection, downstream services still need authentication, and client-specific features cannot automatically be normalized into a shared capability. A workflow that relies on a proprietary UI or local behavior may remain client-specific.

The useful claim is therefore narrower than 'switch agents with no cost.' OpenWork can make the operational substrate more portable. Whether a task remains equally reliable after a switch is still an empirical question for the agents themselves.

The licensing split matters

OpenWork's README calls the desktop app free and open source, and the repository's top-level license makes the core licensing boundary explicit. Code outside the /ee/ enterprise directory is available under the MIT License. Code inside /ee/ is governed separately.

The enterprise directory uses the Functional Source License 1.1 with an MIT future license. It permits internal use, education, research and other non-competing uses, but restricts competing commercial uses. Each version converts to MIT on the second anniversary of the date that version is first made available.

So it would be inaccurate to describe every line in the monorepo as MIT-licensed open source today. The core is MIT; the enterprise layer is source-available under FSL before its future conversion. The latest v0.18.25 release also ships distinct public, cloud and enterprise artifacts, reflecting that product split.

The agent could become the replaceable shell

The usual question in the agent market is which client should become the place where work happens. OpenWork asks a different question: which parts of that work should survive when the client changes?

If skills, connections, permissions and organizational workflows become portable, agent applications can compete more directly on the quality of their planning, execution and interface rather than on how painful they are to leave. The switching cost moves away from the shell and toward the shared capability layer.

OpenWork has not proven that this layer will become the durable center of the agent stack. It still has to make capability discovery reliable, keep cross-client behavior understandable and justify the complexity of another control plane. But that is the more interesting bet behind the project: not that OpenWork can become the next Codex or Cowork, but that users may eventually stop wanting their workflows to belong to any one agent at all.