OpenWork takes on Claude Cowork by making AI workflows portable

The most interesting thing about OpenWork is not that it exists. It is that it treats AI workflows as portable infrastructure rather than vendor features. The open-source desktop app, built by different-ai, positions itself as a free alternative to Claude Cowork and Codex for macOS, Windows, and Linux. But the real bet is on a standard: the Model Context Protocol, or MCP.

OpenWork’s core pitch is that you should not have to rebuild your skills, MCP connections, and service integrations every time you switch agents. The README is explicit: add one OpenWork MCP to Codex, Claude Code, Cursor, or another compatible agent, and you reuse the same skills, MCPs, and connected services across tools, teammates, and machines. Create something once, share it with coworkers or friends, or keep it for yourself.

That framing inverts the current agent economy. Right now, the major labs compete by deepening their own ecosystems. Anthropic pushes Claude Cowork as a dedicated workspace. OpenAI pushes Codex. Each wants your workflows to accumulate inside their walled garden, because accumulated workflows are the switching cost that keeps you there. OpenWork is a direct challenge to that logic: it says the workflow is yours, not the agent’s.

The mechanism is worth examining closely. OpenWork exposes two MCP tools: search_capabilities to find what you can use, and execute_capability to run it. After adding the MCP, your client opens a browser so you can sign in and choose your OpenWork organization. The setup is deliberately minimal. For Codex, one command: codex mcp add openwork --url https://api.openworklabs.com/mcp/agent. For Claude Code, one command: claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent. For OpenCode, a small JSON block in opencode.json. Any MCP client can use the remote server URL directly.

This is the quiet radicalism of the project. MCP was introduced by Anthropic in late 2024 as an open standard for connecting agents to tools and data. It has since been adopted by OpenAI, Google, and most serious agent frameworks. What OpenWork does is treat MCP as the substrate for a portable identity layer. Your capabilities live in OpenWork, and any agent that speaks MCP can reach them. The agent becomes a thin client. The workflow becomes the durable asset.

The desktop app is the optional surface. The README is clear that the app is there when you want a dedicated workspace, but it is not required. You can use OpenWork from the agent you already have. That is a smart architectural decision. It means OpenWork does not need to win the agent war to win the workflow war. It can sit underneath whichever agent wins.

For larger organizations, OpenWork Den is the control plane. It provisions inference at scale and controls which members and teams can use each model provider. It manages invites, teams, and access from one place. It sets desktop policies, restricts local model access, and controls which app versions an organization can use. It publishes skills and plugins through marketplaces, then assigns them to the organization, a team, or specific people. It can even import Anthropic-compatible plugins and make their supported skills and remote MCPs available through the OpenWork MCP.

That last feature is the most strategically significant. Importing Anthropic-compatible plugins means OpenWork is not just a parallel ecosystem. It is a migration path out of Anthropic’s ecosystem. Teams that built skills for Claude Code can lift them into OpenWork and then run them from Codex, Cursor, or anything else. The switching cost evaporates.

The implications for AI builders are direct. If you are building agent workflows today, you have a choice: build them against a single vendor’s runtime, or build them against a portable layer. OpenWork is evidence that the portable layer is becoming viable. The project is young, and the README does not disclose adoption numbers or funding. But the existence of a control plane, an admin interface, and per-user connection management suggests the team is thinking about enterprise deployment, not just hobbyist tinkering.

There is a real tension here. OpenWork’s value depends on MCP being stable and widely supported. That is a reasonable bet today, but it is a bet. Anthropic controls the standard’s evolution, and the company could in principle steer future MCP versions toward its own interests. The same is true of OpenAI. Standards are only open until they are not. OpenWork’s answer is to be open-source itself, so that if the standard shifts, the community can fork and adapt.

The other tension is trust. OpenWork’s model requires you to route your capabilities through its remote MCP server at https://api.openworklabs.com/mcp/agent. That means your skills, your connections, and potentially your data pass through a third party. The README does not detail the security model beyond OAuth-based sign-in. For individuals, that is a reasonable trade. For enterprises, it will be the first question in any procurement conversation. The project’s open-source nature helps, but audits take time.

What is genuinely new here is not the app. It is the assertion that AI workflows are a portable asset class. Claude Cowork and Codex are both excellent products, but they are products. OpenWork is infrastructure. The distinction matters because infrastructure compounds differently. A product captures value through usage. Infrastructure captures value through adoption. If OpenWork succeeds, the agents become interchangeable, and the value settles in the layer that owns the workflows.

For AI builders, the practical takeaway is to watch where your capabilities live. If you are building skills and MCP connections today, consider whether they are portable. The cost of rebuilding them for a new agent is low now and high later. OpenWork is one option. The deeper lesson is that the agent wars are moving from model quality to workflow ownership. The models are increasingly commoditized. The workflows are not.

The dev workflow details in the README are a small window into the project’s maturity. The pnpm dev:worktree command handles multiple git worktrees, sets OPENWORK_DEV_PROFILE=auto, derives a stable profile name from the worktree path, lets Electron choose a free CDP port, and asks Vite for a free dev-server port. There is a note about OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN=1 because on macOS the real keychain prompts block Electron’s main loop. These are the details of a project that has real users hitting real friction. That is a good sign.

The headline number here is zero. OpenWork costs nothing, and its MCP server is free to use. That pricing is a statement. The project is not trying to monetize the individual layer. The control plane, the enterprise features, the inference provisioning: that is where the business lives. The individual layer is the distribution channel.

The open-source alternative framing is accurate but undersells the project. OpenWork is not just a clone of Claude Cowork. It is a bet that the future of AI work is portable, shareable, and standard-based. Whether that bet pays off depends on MCP staying open and on teams trusting a third-party control plane. Both are open questions. But the direction is right. The workflows are the asset. The agent is just the window you look through.