In one sentence: Andrew Ng has open-sourced OpenWorker, a desktop agent built around “deliver finished work, not chat.” Tell it “prepare a client brief,” and it goes through your files, your calendar, and Slack, then hands you a finished document. MIT license, model-agnostic, local-first.
Not Just Another Agent Project
The AI agent conversation has run for over a year, but most products cluster at two extremes: chatbots in a browser tab, or heavily customized enterprise workflow platforms. What’s missing in the middle is a genuine AI coworker — something that lives on your computer, works across tools, and answers entirely to you.
OpenWorker targets exactly that gap. The project is open source on GitHub under MIT, with a downloadable macOS build and a Windows release also available (pending code signing). Ng’s own framing on X is direct: “an open-source agent that doesn’t just chat with you — it delivers finished work.” Translated: stop keeping me company; get the job done.
The Core Design, in Four Keywords
1. A delivery agent
“Delivery” is the essential difference from a chatbot. The traditional AI workflow: you ask the AI to analyze requirements → it generates text → you manually find files, verify data, adjust formatting → you open Slack, email, or calendar to send the result. AI participated, but your app-hopping didn’t shrink at all. OpenWorker aims to own the whole chain: you state the outcome you want, it decomposes the task, calls local files, the terminal, and connected apps, and delivers a finished artifact you can open, edit, and share directly.
2. Model-agnostic
No model lock-in. Bring your own API key and connect GPT-5.6 Sol, Claude Fable, Gemini 3.6 — or run Kimi, GLM, DeepSeek, Qwen, and Inkling as open-weight models through Ollama. Prices went up today? Swap the model.
3. Local-first with privacy by default
Agent loops, conversation history, connector tokens, and model keys all live in your device’s local secret storage by default. Data leaves the machine only when you deliberately choose a specific LLM provider or third-party integration. The single cloud component is a small proxy service for OAuth handshakes.
4. Request-then-approve
Whenever a task involves sending messages, modifying calendars, writing to external tools, or executing terminal commands, OpenWorker pauses, explains what it intends to do, and waits for approval. If you’re away from the desk, requests queue for your return. This design decides whether agents can enter real offices at all — a competent AI coworker may be diligent, but it may not act on its own authority.
25+ Tool Connections Plus MCP
The project page lists connections to more than 25 tools — GitHub, Slack, Jira, Notion, Linear, HubSpot, Outlook, Gmail, Google Calendar among them — plus local file and terminal access. Anything missing can come in through MCP (Model Context Protocol). Scheduled tasks are supported too: a morning news digest, a weekly work report, watching a particular Slack channel — all delegable.
The Architecture at a Glance
-
Desktop shell (Rust): native GUI; macOS build is signed, Windows pending.
-
Local agent server (Python): engine, tools, and connectors, built on aisuite.
-
Your files, tools, and models: everything runs on your machine, with your keys.
Prerequisites: Python 3.10+, Node 20+, and a Rust toolchain for building the desktop shell.
Why This Could Be the Agent Watershed
OpenWorker’s significance is not a longer feature list. It is the simultaneous achievement of three things:
-
Open source: MIT means developers can read the code, modify behavior, and deploy customized to their own workflow. This is not a closed product; it’s adaptable infrastructure.
-
Local-first: as more enterprises reject cloud agents over data privacy, “data never leaves this machine” is a real competitive advantage, not a slogan.
-
Model-agnostic: both a technical choice and a strategic judgment — the AI substrate is still evolving fast, and binding to any single vendor is a risk.
Ng has spent years arguing that agents and workflows are the next major direction. OpenWorker pushes that argument one step further: the agent’s next home is not the browser and not the code editor — it is the desktop.
It is worth pausing on why “delivery” is the hard part rather than the easy part. Chat is forgiving: a wrong sentence costs a re-prompt. Delivery is unforgiving: a wrong calendar entry, a misfiled document, or a message sent to the wrong channel has already happened by the time you notice. That asymmetry is why most agent products stopped at chat — generation was tractable, accountability was not. The request-then-approve mechanism is OpenWorker’s answer to that asymmetry, and it is also the feature that will decide whether desktop agents feel like coworkers or like liability generators.
What To Do
For developers, OpenWorker doubles as a reference implementation of patterns the industry has been describing but rarely shipping: local secret storage, connector sandboxing, approval gates, and model abstraction are all in a codebase you can read rather than a press release you have to believe. Teams evaluating desktop agents can lift the approval-gate design wholesale even if they never ship OpenWorker itself. Users in enterprise environments where cloud agents are banned should try the Ollama path — a fully local model with local data is the configuration most likely to survive a compliance review.
-
GitHub repo: github.com/andrewyng/openworker
-
Official site: openworker.com
-
macOS users can download and install directly; Windows builds are available too.
-
Bring your own API key, or run local models through Ollama.
OpenWorker is in public beta and still polishing rough edges. But the direction is already legible: AI agents cannot live in chat boxes forever — they have to participate in real work, deliver real outcomes, and hand model choice, tool access, and final authority back to the user.
References: OpenWorker on GitHub · openworker.com · Andrew Ng’s announcement
