Vision & Principles
Relevant source files
The following files were used as context for generating this wiki page:
OpenWork is an open-source, extensible alternative to "Claude Cowork," designed to bridge the gap between technical agentic engines and everyday productivity for non-technical users. It operates as a "thin layer" or experience layer built on top of the OpenCode engine, prioritizing a premium, slick, and mobile-friendly user interface while maintaining strict security through local-first execution and explicit permission models.
The vision for OpenWork is to make "agentic work" feel like a productized process rather than a terminal-centric developer tool. It targets a broad spectrum of users—from "Susan in accounting," who needs automated workflows that "just work," to "Bob the IT guy," who configures and shares these workspaces with his team.
Sources: README.md:3-13, PRODUCT.md:5-20, AGENTS.md:5-10, INFRASTRUCTURE.md:4-8
Core Product Vision
OpenWork's primary goal is to turn OpenCode configurations into usable experiences. It is built to be a native desktop application that simplifies complex agentic tasks into guided workflows.
Target Personas
| Persona | Description | Needs/Goals |
|---|---|---|
| Knowledge Worker | Non-technical users like "Susan" | "Do this for me" workflows with safe guardrails. |
| Admin/Host | IT/Ops users like "Bob" | Manages shared machines, profiles, and workflow setup. |
| Power User | Technical users | Performance, speed, and deep inspection capabilities. |
| Mobile-first User | Remote users | Ability to start and monitor tasks from a phone. |
Sources: PRODUCT.md:5-24, AGENTS.md:8-10
Success Metrics
The vision is quantified by specific performance and usability targets:
- Time to Value: Less than 5 minutes to the first successful task on a fresh install.
- Autonomy: Greater than 80% task success without requiring a terminal fallback.
- UI Performance: Consistent 60fps animations and interaction latency under 100ms.
- Safety: High understanding and low accidental denial of permission prompts.
Sources: PRODUCT.md:26-31, AGENTS.md:65-72
Strategic Principles
The project follows a specific decision framework and set of constraints to ensure consistency between the OpenWork UI and the underlying OpenCode engine.
Operational Principles
- Parity with OpenCode: Every UI action must map cleanly to an OpenCode server API or tool. New abstractions are avoided unless they map to existing OpenCode primitives (skills, plugins, commands, MCP).
- Transparency: The application must remain "auditable." Plans, steps, tool calls, and permission decisions should be visible to the user at all times.
- Prompt as the Workflow: Logic should reside in prompts, rules, and skills rather than being hard-coded into the application UI.
- Local-First & Portable: No secrets are committed to the repository; the application uses OS keychains for credentials and prioritizes local execution.
Sources: PRINCIPLES.md:3-23, AGENTS.md:14-22, INFRASTRUCTURE.md:12-25
User Experience (UX) Philosophy
OpenWork aims for a "premium, calm, and high-contrast" design that eliminates "developer vibes" in its default mode. This includes:
- Mobile-native interactions: Support for bottom navigation, swipe gestures, and haptics.
- No Blocking States: Avoidance of blocking spinners; the UI should always show the current progress state.
- Accessibility: Commitment to WCAG 2.1 AA standards and screen-reader support.
Sources: PRODUCT.md:43-57, AGENTS.md:59-62
Infrastructure Principles
The relationship between OpenWork (the UI) and OpenCode (the Engine) is defined by strict infrastructure boundaries.
The diagram above illustrates OpenWork as an experience layer connecting to the independent OpenCode engine.
Sidecar Composition
OpenWork infrastructure is built to be "sidecar-composable." Every component must be runnable via a standalone CLI, ensuring the UI remains a wrapper that does not lock out power users.
- CLI-First: Components like the
openwork-servermust run standalone. - Unix-like Interfaces: Simple boundaries using JSON over stdout, flags, and environment variables.
- Readiness for Agents: The architecture is designed so that AI agents can interact with the system via CLI/Bash for testing 99% of flows.
Sources: INFRASTRUCTURE.md:12-50, ARCHITECTURE.md:62-70
Security and Permission Framework
OpenWork operates on a "Least Privilege" model, enforcing security through two primary layers of authorization.
Two-Layer Authorization
- UI-Level Authorization: Users explicitly select specific folders they authorize the app to access through a native picker.
- Engine-Level Permissions: The OpenCode engine requests explicit permission for sensitive actions (e.g., file writes outside scope, network calls).
Decision Flow for Permissions
Sequence showing the transparent permission handling process derived from OpenWork principles.
Sources: PRINCIPLES.md:25-31, ARCHITECTURE.md:144-162, PRODUCT.md:124-131
Summary
The vision for OpenWork is to provide a premium, accessible front-end for agentic workflows while adhering to strict technical principles: OpenCode parity, local-first security, and CLI-first infrastructure. By treating the UI as a thin layer over OpenCode primitives, the project ensures extensibility and transparency, making complex AI tasks manageable for non-technical knowledge workers and power users alike.
Sources: README.md:16-24, VISION.md