Andrew Ng has released OpenWorker, an open-source desktop agent that produces finished work rather than conversation. OpenWorker asks the user for an outcome, not a prompt: a polished document, a Slack reply containing the actual numbers, an updated calendar, a triaged inbox. It then breaks that outcome into steps, works across local files and connected apps, and checks in before anything consequential. This marks a deliberate shift from the chat-based interaction paradigm that has dominated consumer AI tools since the launch of ChatGPT, positioning the agent as a reliable executor of complete tasks rather than a conversational partner.<\/p>\n
The repository contains 119 Python files (~32,400 lines) under The engine is built on aisuite<\/a>, Andrew Ng\u2019s provider-agnostic LLM library. This design means the entire system \u2014 from the user interface through the agent loop to the model calls \u2014 runs locally on the user’s machine. No cloud service processes the user’s data unless they explicitly connect a third-party API. The desktop shell, built with Tauri 2, provides a native experience on macOS, Windows<\/a>, and Linux, while the React 18 frontend delivers a modern, responsive interface.<\/p>\n OpenWorker is an open-source desktop agent that produces finished work \u2014 not conversation. Unlike conventional chatbots that respond to prompts with text, OpenWorker is designed to take an outcome specification (e.g., “draft a quarterly report in Google<\/a> Docs using data from the attached spreadsheet and send a Slack summary to the team”) and then autonomously break that outcome into executable steps, interact with local files and connected applications, and deliver the completed artifact. The system checks in with the user before performing any consequential action \u2014 such as writing to a file, executing a shell command, or sending a message \u2014 unless the user has configured a higher permission mode. This outcome-driven workflow represents a fundamental rethinking of how AI agents should interact with users: instead of mediating every action through a chat window, the agent plans and executes in the background, only surfacing to request approval or clarify ambiguity.<\/p>\n OpenWorker introduces a safety system built around four risk classes and five permission modes. The risk classes are The five permission modes are:<\/p>\n This granular control means users can start with a conservative mode like “discuss” to explore the agent’s planning capabilities, then gradually increase autonomy as they build trust. The system also supports per-workspace mode settings, so a user might run sensitive work in interactive mode while allowing automated mode for less critical tasks.<\/p>\n OpenWorker ships with a curated matrix of 30 models, deliberately small and covering only current-generation, tool-calling models. The matrix includes:<\/p>\n Users can add any other model string manually, but the curated list ensures that only models known to perform well with tool calling are recommended. The model router handles the provider-specific API details, so users only need to provide their API keys \u2014 which are stored locally in a secret store and never placed in prompts or traces. For local inference, OpenWorker supports Ollama, requiring no API key at all.<\/p>\n The connector layer provides 35 integrations that are available at launch, organized by category:<\/p>\n Five more connectors are declared but not yet available: Datadog, Salesforce, PagerDuty, Descript, and Clay. Additionally, any MCP server can be plugged in on top using the same The agent loop is the core of OpenWorker’s execution engine. When a user submits an outcome, the system first parses the request into a structured plan. The agent then iterates through a loop of model calls and tool invocations, with a default cap of 12 iterations per turn. At each step, the model may read files, search code, execute shell commands, or call connectors \u2014 all subject to the permission mode and risk class. The agent logs every action, and the user can inspect the trace at any time. When the agent determines that the outcome has been achieved, it presents the finished work to the user. If the user is not satisfied, they can provide feedback and the agent will adjust its approach.<\/p>\n This loop is powered by aisuite, which provides a single interface over multiple model providers. The agent uses the model’s native tool-calling capability to decide which tool to invoke and with what parameters. The local tools \u2014 files, git, ripgrep-backed search, shell, and todo \u2014 are vetted to ensure they work reliably with the agent loop. The system also includes a code files tool that understands common programming language structures, making it particularly useful for developers.<\/p>\n One of the most significant design decisions in OpenWorker is that the entire system runs on the user’s machine. The Python server, the Tauri shell, and the React UI all execute locally. The only external connections are the model API calls (which go directly to the provider’s API endpoint using the user’s own key) and the connector integrations (which use the user’s OAuth tokens or API keys). No data passes through an OpenWorker-managed server. This local-first approach means the agent can work with sensitive files, internal codebases, and confidential communications without ever uploading them to a third party.<\/p>\n The architecture also includes an optional Rust speech-to-text sidecar called OpenWorker enters a landscape where most AI agents are either cloud-based services or experimental open-source projects. By releasing a fully functional, open-source desktop agent that can be installed and run immediately, Andrew Ng is challenging the industry to move beyond chat interfaces. The emphasis on outcomes rather than prompts aligns with the growing recognition that the ultimate value of AI lies in task completion, not conversation.<\/p>\ncoworker\/<\/code>codecodecodecodecode, 149 TypeScript\/TSX files under surfaces\/gui\/<\/code>codecodecodecodecode, and 78 backend test modules. The stack breaks down as follows:<\/p>\n\n
com.openworker.desktop<\/code>codecodecodecodecode, and the shell supervises the Python server itself.<\/li>\n127.0.0.1:8765<\/code>codecodecodecodecode by default. The example config caps a turn at 12 model\u2194tool iterations.<\/li>\nWhat is OpenWorker and how does it differ from traditional AI assistants?<\/h2>\n
Four risk classes and five permission modes control every action<\/h2>\n
read<\/code>codecodecodecodecode, write_local<\/code>codecodecodecodecode, exec<\/code>codecodecodecodecode, and external<\/code>codecodecodecodecode. Each tool and connector is assigned a risk class, and the user’s chosen permission mode determines what the agent can do without explicit approval.<\/p>\n\n
auto_allow<\/code>codecodecodecodecode list.<\/li>\n<\/ul>\nModel matrix: 30 curated models from 10 providers<\/h2>\n
\n
35 connectors ship with published access copy<\/h2>\n
\n
mcpServers<\/code>codecodecodecodecode JSON format that Claude Desktop uses, with per-tool approval required. The model router also includes a keyless default web search via DuckDuckGo, with Tavily and Brave as optional alternatives.<\/p>\nHow does the agent loop work?<\/h2>\n
Local-first architecture ensures privacy and offline capability<\/h2>\n
ocw-stt<\/code>codecodecodecodecode that runs Whisper fully offline, enabling voice input without any network dependency. The signed updater feed at download.openworker.com\/latest.json<\/code>codecodecodecodecode ensures that users can receive updates through the native update mechanism without compromising the local-first security model.<\/p>\nStrategic implications for the AI agent market<\/h2>\n