1. Concept

OpenWorker's core claim is outcomes, not conversation. It is not a chatbot that returns answers to prompts. You specify a desired outcome, and a desktop agent decomposes it into steps, walks local files and connected tools, and produces real artifacts.

The flow has four stages.

Stage What happens
1 User specifies an outcome ("prepare a client briefing", "clean up my calendar", "check release status in Jira and GitHub")
2 Work is broken into substeps and executed across local files and connected apps
3 Before hard-to-undo actions — sending messages, changing calendars, shell commands — the agent asks for approval
4 Final deliverable is returned as files you can open and share

Architecture

OpenWorker desktop app          Tauri 2 native shell + React 18 UI
        |
Local agent server (Python)     FastAPI/uvicorn, 127.0.0.1:8765, aisuite-based
        |
Local files · terminal | 25+ connectors | User-chosen model

The agent loop itself runs on the user's machine (local-first). OpenWorker does not operate an inference service. The only cloud piece is a small relay for connector OAuth handshakes — and even that can be skipped by registering API keys manually, with no login required.

Permission model

Every tool call is typed into one of four risk classes, each with an approval gate. Treating the approval layer as a type-system concern rather than a UI add-on is a real design differentiator.

Class Nature Default policy
read Read Auto-allow
write_local Local write Approval required
exec Command execution Approval mandatory
external External send Approval mandatory

In unattended (automation) mode, actions that need approval are queued in an inbox instead of running freely, and wait for the user.

2. Strengths

Area Detail
Model-agnostic aisuite-based BYOK. Supports OpenAI, Anthropic, Google Gemini, Inkling, GLM, DeepSeek, Kimi, Qwen, MiniMax, Mistral, Grok. Open-weight models via Together/Fireworks; fully local via Ollama
Data-path control Chat history, connector tokens, and model keys live in a local secret store. Sensitive work can stay on Ollama while routine work routes to the cloud
Structured approval gates Risk classes are code-level types and auditable. Shrinks the surface for "the agent emailed someone on its own" incidents
Connector breadth 25+ native connectors (GitHub, Slack, Jira, Notion, Linear, HubSpot, Outlook, monday.com, Gmail, Google Calendar, …) plus terminal, local files, and arbitrary MCP
Artifact-oriented Returns documents, spreadsheets, reports, and web pages as files — openable deliverables, not just summaries
Scheduled runs Automate morning briefs, weekly reports, always-on channel watch. Full transcripts retained
Slack entry point Mention @OpenWorker in a channel; a desktop session opens and results reply in-thread
License MIT — audit, fork, and commercial use unrestricted

3. Weaknesses and caveats

Area Detail
Local-first ≠ local-complete Only the agent loop is local. The moment you use a cloud API key, file contents and context leave for the model provider. Real privacy essentially means the Ollama path — with weaker tool-calling accuracy than frontier models
Maturity Open beta at launch; ~45 commits — early repo. Star counts cited elsewhere range from ~46 to ~3,400; cite carefully
Unsigned Windows Windows code signing is in progress; SmartScreen warnings appear. Not ready for enterprise rollout
Cost shift The app is free; model spend is entirely on the user. Agent loops burn tokens heavily per task
Ops burden Install, key management, connector auth, and model choice are all user-owned — higher entry cost than managed cloud agents
Local attack surface Built-in terminal and file access raise prompt-injection risk. When reading external docs, email, or issue bodies, the exec approval screen is the last line of defense. Habitual clicks from approval fatigue are the practical vulnerability
MCP double edge Arbitrary MCP servers mean supply-chain verification is also on the user
Contribution policy Internal roadmap first; PRs off-direction are declined. Open source with centralized governance
Curated models only ~30 models verified for tool calling; anything outside that list is at your own risk

4. Related and competing projects

Project License Character vs OpenWorker
Goose (Agentic AI Foundation) Apache 2.0 Rust local agent runtime; desktop + CLI + embeddable API Closest peer. 25+ providers, 70+ MCP extensions, subagents, macOS/Windows/Linux. Linux Foundation governance. Far ahead on maturity and ecosystem
OpenHands (All Hands AI) MIT Coding agent in Docker sandbox; SDK/CLI/cloud SWE-bench-oriented development work; stronger sandbox than OpenWorker
Open Interpreter Apache 2.0 CLI-first local agent More raw/general; no GUI or connector ecosystem
Cline / Kilo Code Open source IDE-embedded agents (VS Code, JetBrains) Coding-session focused; not knowledge-work tooling
Claude Cowork / Claude Desktop Commercial Managed agentic knowledge-work No install/key burden; no model choice or data locality
Manus Commercial Credit-based autonomous task agent Polished product experience; not open source
Messaging-native agents (e.g. Poke) Commercial Personal assistants inside chat Conversation-centric, not file artifacts
n8n / Dify / Zapier Agents Mixed Workflow orchestration Predefined flows — not goal-based autonomous decomposition

Positioning in one line

If Goose is the local agent for developers, OpenWorker aims to be the local agent for knowledge workers. Goose is expanding beyond code too, so the remaining wedge is mainly artifact-first UX and typed approval. Andrew Ng's brand will drive early adoption; a deep technical moat is not yet obvious.

5. Getting Started

5.1 Binary install (recommended)

OS Download Notes
macOS 12+ (Apple Silicon) download.openworker.com/mac Signed & notarized; auto-update
Windows 10/11 (x64) download.openworker.com/windows Unsigned; SmartScreen warning

After install:

  1. Launch the app
  2. Pick a model provider and enter an API key (or point at an Ollama endpoint)
  3. Authenticate needed connectors (OAuth or manual API key)
  4. Give it a real work instruction

5.2 Fully local (no cloud keys)

# Install Ollama, then pull a model
ollama pull qwen3
# In app settings: provider = Ollama, endpoint = http://localhost:11434

No data leaves the machine in this setup. Tool-calling reliability still needs separate validation.

5.3 Build from source

Prerequisites: Python 3.10+, Node 20+, Rust toolchain (rustup) for the desktop shell.

git clone https://github.com/andrewyng/openworker
cd openworker

# 1. One-time bootstrap (.venv)
#    On Windows use Git Bash or WSL
bash packaging/setup_dev_env.sh

# 2. Start local agent server
.venv/bin/openworker-server --cwd ~/some/project --port 8765
#    Windows: .venv\Scripts\openworker-server.exe

# 3. In another terminal, start the UI
cd surfaces/gui
npm install
npm run dev          # browser UI via Vite

For the full desktop app instead of the browser UI, replace step 3 with npm run tauri dev. The Tauri shell also manages the server process.

Tests and packaging:

.venv/bin/pytest                    # backend tests
cd surfaces/gui && npm test         # GUI unit tests
cd surfaces/gui && npm run e2e      # E2E tests
bash packaging/build_dmg.sh         # macOS DMG
pwsh packaging/build_windows.ps1    # Windows installer

5.4 Repository layout

Directory Contents
coworker/ Python backend: agent engine, providers, connectors, MCP client, memory, automation
surfaces/gui/ React UI + Tauri shell
stt/ Rust STT sidecar for voice input
packaging/ Installer builds, auto-update manifests, dev bootstrap
docs/ Design docs, decision log
tests/ Backend test suite

5.5 Pre-adoption checklist

Check Guidance
Data sensitivity Confidential internal work → Ollama-only is effectively the only option
Approval policy For org rollout, write down defaults for exec/external classes
Connector scopes Keep OAuth scopes minimal; avoid blanket Gmail/Slack grants
Cost caps Set provider usage limits before day-one usage
Alternatives Heavy coding workload → evaluate Goose or OpenHands first

References

#OpenWorker #AndrewNg #AIAgent #OpenSource #WorkAutomation #GenerativeAI #LLM