Andrew Ng released OpenWorker, an open-source desktop application that acts as an AI agent across a user’s files, terminal, and connected apps instead of answering inside a chat window. The project ships in open beta for macOS and Windows, with the Windows build not yet code-signed. Ng built the agent engine on top of his own aisuite, a Python library he maintains for calling multiple LLM providers through one interface, before giving OpenWorker its own repository.
The architecture is the story here, more than the feature list. OpenWorker runs a local agent server on the user’s own machine, paired with a desktop shell for the interface. Model keys, connector tokens, and stored conversations all sit in that local server’s secret store rather than on a vendor’s infrastructure. The only network traffic that leaves the device is the model API call itself and the OAuth exchange needed to authorize a connected app.
That is a direct counterpoint to how most agent products ship in 2026. Hosted computer-use and coding agents from OpenAI and Anthropic execute inside a sandbox those companies control, with data routed through their servers by default. OpenWorker flips the arrangement: the user supplies the key, whether for OpenAI, Anthropic, Google Gemini, DeepSeek, Mistral, or xAI’s Grok, or points the agent at a fully offline Ollama model, and the task runs on their own hardware. For a team unwilling to route internal documents through someone else’s inference stack, that is the whole pitch.
The task loop follows the pattern now standard for agent products: describe an outcome, such as drafting a report or clearing a backlog, and OpenWorker plans the steps and carries them out across local files and roughly two dozen third-party integrations, among them Slack, GitHub, Notion, Jira, HubSpot, and Google Calendar. It also accepts any tool exposed over MCP, Anthropic’s protocol for tool calling, with permission set per tool. A mention inside Slack can open a session that runs on the user’s desktop and replies back in the thread. Scheduled jobs, such as a recurring status digest or continuous monitoring of a channel, run unattended and log a full transcript of what happened.
The permission model deserves the closest look. OpenWorker pauses and asks for confirmation before it sends a message, edits a calendar entry, or executes a shell command, and waits on the user to approve or redirect it. Unattended jobs do not bypass that gate; the request lands in a review queue rather than executing unattended. That design choice is also the entire security perimeter the tool has. An agent holding terminal access and write permission to a person’s files, inbox, and calendar is a standing attack surface: a prompt injection hidden in a scraped page, a compromised connector token, or a malicious MCP server could turn the approval prompt into the only barrier between a bad instruction and a real action on the machine. Installing OpenWorker means trusting it, and every service it touches, with the entire contents of that computer.
Ng did not publish benchmark scores or adoption numbers with the release, and the documentation makes no claim that OpenWorker beats any cloud agent on capability. What the release signals instead is where a researcher with Ng’s view across enterprise AI deployment thinks the agent stack is heading: not necessarily toward larger hosted agents, but toward a model-agnostic runtime that keeps execution off a vendor’s cloud by default.
Teams evaluating agentic tools for internal work should use OpenWorker’s approval-gated permission model as the baseline against which to measure any cloud-hosted computer-use agent whose execution environment they cannot inspect.
Published on GitHub by Andrew Ng, July 2026.
