different-ai/openwork describes itself as a free open-source desktop app for doing AI work on local files, but the sharper source read is architectural. The project is wrapping OpenCode in a host that can start on localhost, expose sessions to a UI, connect remote workers, govern file access, package reusable setups, and move the same work surface toward team and enterprise deployment.
The README's own architecture section gives the outline. In host mode, OpenWork runs a local stack; the default runtime is the openwork orchestrator, which coordinates opencode, openwork-server, and optionally opencode-router. The desktop UI then uses the OpenCode SDK to list and create sessions, send prompts, subscribe to server-sent events, read todos, and surface permission requests.
The Host Shape
The orchestrator is the tell. Its docs define a CLI-first host that can run without the desktop UI, download and cache sidecars through a SHA-256 manifest, withhold live pairing credentials from normal stdout, run sidecars inside Docker or Apple's container boundary, and create short-lived file sessions for catalog, batch read, write, events, and close operations.
That makes OpenWork less like an alternate chat pane for an agent and more like a product boundary around agent work. The server routes normalize OpenCode sessions into a read model, reject invalid upstream shapes as opencode_invalid_response, require collaborator scope before mutating session groups, and use file-session limits, path normalization, traversal rejection, text-file filtering, and approval hooks before exposing workspace files.
Where Control Lives
The control surface is also visible outside the UI. workspace-export-safety.ts scans MCP, plugin, and provider settings for token, bearer, password, credential, private-key, and secret-like signals before making workspace exports portable. approvals.ts gives the server both auto approval and manual pending approval replies, with timeout denial rather than unbounded waiting.
The recent commit trail pushes that boundary further into organizational deployment. Commit c713c9a adds single-org deployment mode across Den API, Den Web, Helm, Docker, tests, and eval flows. The accompanying plan says self-hosted OpenWork EE should behave like one customer-owned workspace by default while keeping organizations, roles, SSO, SCIM, workers, plugins, API keys, and MCP resources inside the model.
Why It Matters
That is the useful distinction for builders watching agent tools. OpenWork is not only asking whether an agent can edit a file. It is asking how the agent session becomes a repeatable work process: local by default, shareable when opted in, scoped by token and approval, exportable without carrying obvious secrets, and deployable as a single customer-owned workspace when a team needs a governed version.
Commit 8beb799 shows the same direction from the connections side. Slack cloud connections move through pre-registered OAuth apps, with flow tests and UI data changes, while the commit note refuses agent principals from carrying those secrets. That is a small but concrete example of the product line: agent work is useful only if the surrounding system knows which human, org, worker, or connection is allowed to do what.
Limits
The evidence proves architecture and current implementation movement, not adoption, complete enterprise readiness, or perfect safety. Single-org mode is documented as an implemented first pass with follow-up work still named. The right watch item is whether OpenWork keeps tightening the same boundary: fewer ad hoc secrets, clearer org policy, better session provenance, and enough tests that the host remains auditable as it grows.