If you're tired of the "AI writes you a to-do list, and you still do everything yourself" pattern, Andrew Ng's newly open-sourced OpenWorker wants to take that whole chunk of work off your plate. It's an AI agent that lives on your desktop (MIT License) with a very direct positioning: deliver finished work, not just chat — no chatting, no advice-giving; it hands you documents, Slack replies, calendar updates, and inbox cleanups as shareable finished files. It fits developers and ops folks who bounce between GitHub / Jira / Slack / Notion / email every day, and it does not fit users who just want a chat box.

What OpenWorker Is

OpenWorker is Andrew Ng's open-source desktop AI agent, and local-first + model-agnostic are its two defining lines:

• Local-first: the agent loop, conversation history, connector tokens, and model keys all live in the app's local secret store; the only cloud component handles nothing but the OAuth handshake.
• Model-agnostic: you bring your own API key, with out-of-the-box support for OpenAI, Anthropic, Google Gemini, Inkling (Thinking Machines), GLM (Z.ai), DeepSeek, Kimi (Moonshot), Qwen, MiniMax, Mistral, Grok (xAI), plus open-weight models on Together / Fireworks and local models via Ollama.

It's built on Andrew Ng's own lightweight unified LLM library, aisuite, and the whole architecture splits cleanly into three layers: desktop shell (native shell + React/Tauri GUI) → local agent server (Python, with engine / tools / connectors) → your files, terminal, 25+ connectors, and any model provider. Every call runs on your key, on your machine.

GitHub repository: https://github.com/andrewyng/openworker

Core Capabilities

Deliver Finished Work, Not a To-Do List

The most direct difference is in the deliverable. An ordinary chatbot gives you words about "what you should do"; OpenWorker gives you a document, spreadsheet, report, or web file that you can open, edit, and forward. Ask it to "prepare a customer brief" and it finds the material, organizes the information, and generates a complete document; ask it to "check where the release stands across Jira and GitHub" and it collects status across tools instead of waiting for you to feed it background material paragraph by paragraph.

25+ Connectors + MCP Extension

The out-of-the-box integrations cover most of a developer's daily tool stack:

• Code / projects: GitHub, Jira, Linear, Notion
• Communication / scheduling: Slack, Outlook, Gmail, Google Calendar, monday.com, HubSpot
• Local: terminal, file system

Not enough? Any MCP-compatible tool can be wired in, with per-tool permission control — not a blunt "allow / deny," but authorization at the granularity of each tool.

Approval-Gated: High-Risk Actions Need Your Nod

When an AI moves from "answering questions" to "operating your computer," the nature of the risk changes. Sending a venting message to your boss, deleting an unbacked-up file, mangling a schedule — none of these can be fixed by "regenerate." OpenWorker's design: check back for approval before executing any consequential action.

Action categories that trigger approval:

• Sending messages (Slack / email)
• Modifying calendars
• Writing to external tools
• Running shell commands

Not at your computer? Requests sit in the inbox waiting — the confirmation step is never skipped in the name of progress. This unglamorous design decides whether it can enter real office scenarios: diligent, but never acting on its own authority.

Slack Triggers + Scheduled Automations

Two capabilities that make OpenWorker genuinely "grow into your workflow":

• Slack triggers: @OpenWorker in a channel and a desktop session opens automatically, with the result posted back as a thread reply — you never switch windows.
• Automations (scheduled tasks): daily briefings, weekly reports, standing watch over a channel — every run keeps a full transcript for traceability.

Installation and Getting Started

Option 1: Desktop Install (Recommended for Most Users)

Open the GitHub README and download for your platform:

Open the app → add any model API key (or point it at a local Ollama) → state a real task, and it starts working.

Option 2: Run from Source (Recommended for Developers)

Requires Python 3.10+, Node 20+, and a Rust toolchain.

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

# One-shot dev environment setup (creates .venv)
bash packaging/setup_dev_env.sh

# Start the local agent server
.venv/bin/openworker-server --cwd ~/some/project --port 8765

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

If you want the full desktop shell (with a native window):

npm run tauri dev

Running tests:

# Backend
.venv/bin/pytest

# Frontend
npm test
npm run e2e

💡 Tip: SmartScreen warnings on Windows are expected — the README explicitly notes signing in progress. For production distribution, wait until signing completes or build from source yourself before rolling it out broadly.

The Execution Flow of One Complete Task

Take "prepare a customer brief" as the example; OpenWorker's internal chain runs like this:

1. You tell it the outcome you want (not the steps)
2. It decomposes the task into steps, working across your desktop / files / connected apps
3. Whenever it reaches a consequential action — sending a message, changing a calendar, running a command — it checks in and waits for your approval
4. You receive a finished file you can open, edit, and share (not a todo list)

Throughout, the model choice, the tool calls, and the final say all stay in your hands — this is how Andrew Ng framed it on X: a work layer users can choose, control, and modify.

Use Cases and Limits

A good fit for:

• Developers, PMs, and ops people who switch between 5+ SaaS tools daily and need to produce materials in bulk (briefs / reports / weekly updates)
• Teams that care about data locality and want model keys never to leave the machine
• Anyone already using Ollama / DeepSeek / Kimi or other open-weight models who doesn't want to be locked to a single vendor

Current limitations:

• Still in open beta — usable, but many rough edges are being polished
• The Windows build is unsigned; evaluate on your own before deploying it inside a corporate network
• Heavily dependent on third-party tools' API tokens; enterprise SSO scenarios may need extra configuration

Final Thoughts

OpenWorker is clear about where the AI agent goes next: not in the browser, not only in the code editor, but on the desktop, with decision-making handed back to people. For a project backed by Andrew Ng, under the MIT License, model-agnostic, and local-first, it's worth trying as the baseline "AI coworker" option in your 2026 developer toolbox. Code, docs, and installers are all in the repository — there is no waitlist.

Repository: https://github.com/andrewyng/openworker