Andrew Ng and Rohit Prasad Release OpenWorker, an Open-Source, Local-First AI Assistant

Artificial intelligence pioneers Andrew Ng and Rohit Prasad have released OpenWorker, an open-source, local-first desktop AI coworker designed to automate multi-step workflows directly on a user’s machine. Unlike conversational assistants that only generate text in a chat window, OpenWorker is built to deliver finished deliverables—such as compiled reports, formatted spreadsheets, and updated calendar invites—across third-party applications like Slack, email, GitHub, and HubSpot, while keeping data local and requiring human approval before taking consequential external actions.

Local-First Architecture and Privacy Safeguards

OpenWorker operates on a local-first architecture, keeping user data, conversation history, and access credentials on the physical machine. According to the project’s documentation, all passwords, model keys, and connector tokens are stored directly on the user’s device inside the application’s local secret store.

No user account is required to operate the software. Users can run the desktop application entirely signed out, managing their own direct API keys and manual integrations. While a free, optional OpenWorker account is available, its purpose is limited to brokering OAuth handshakes for third-party tools with specific vendor restrictions, such as Slack. The developers state that these authentication tokens are handed straight back to the user’s local machine and are never stored in the cloud.

To protect users when interacting with external data, OpenWorker features a robust prompt-injection defense. The platform’s default system prompt instructs the underlying agent to treat any content retrieved from external tools, terminal logs, web pages, local files, or incoming messages strictly as untrusted data rather than instructions.

Because OpenWorker is released under the permissive MIT license, the desktop client itself is free to download and inspect. Users do not pay the project developers for compute; instead, they fund their operations by paying their chosen model providers directly for raw API consumption.

Model Agnostic Integration and Support

The platform does not lock users into a specific artificial intelligence model. It is powered by aisuite, a provider-agnostic Python library developed by Andrew Ng’s team that translates a single standardized API call across different model providers. This design allows users to register their own API keys or configure local open-weight model instances.

Supported cloud and open-weight model providers verified for tool-calling include:

• OpenAI
• Anthropic
• Google Gemini
• xAI (Grok)
• Mistral
• DeepSeek
• Qwen
• Moonshot Kimi
• GLM (Z.ai)
• MiniMax
• Together AI
• Fireworks

For users who prioritize complete data privacy, OpenWorker integrates directly with Ollama to run open-weight models locally. Users can change model configurations on a per-task basis, even switching models in the middle of a live conversation.

To execute tasks, the client connects to more than 25 different productivity and business software tools. Supported integrations include Slack, Outlook, Gmail, Google Calendar, Notion, HubSpot, GitHub, Attio, Google Drive, Jira, Linear, Asana, Dropbox, Box, and monday.com.

Task Execution and Human-in-the-Loop Approvals

OpenWorker focuses on delivering finished outcomes rather than drafting conversational responses. The application decomposes broad user requests into a series of logical steps, displaying its progress in real time as it interacts with local files and APIs.

During task execution, OpenWorker generates “artifacts” such as Markdown documents, HTML files, spreadsheets, or PDFs. The agent operates on a gated risk engine with defined permission modes (covering actions like reading files, writing locally, executing scripts, or making external calls). It is restricted from performing consequential external actions—such as dispatching an email, posting a message to a public Slack channel, running terminal shell commands, or updating a database—without explicit human approval. These actions trigger a prompt in the user interface featuring “Approve” or “Not now” buttons, keeping final control with the user.

Pre-Configured Roles and Background Triggers

OpenWorker includes pre-built role profiles tailored to specific operational requirements. Each configuration maps specific toolsets, guidelines, and communication boundaries:

• Sales: Researches target accounts, drafts follow-up messages, and prepares meeting notes. It integrates with HubSpot, email, and calendar tools, requiring approval before dispatching any communications.
• Executive Assistant: Triages inboxes, schedules meetings, and manages calendar conflicts across email, calendar, and Slack.
• Marketing: Gathers performance metrics, ad spend, and attribution details to build reports. It currently integrates with HubSpot and Slack, with Google Analytics 4 support in development.
• Ops On-call: Triages system alerts, reviews runbooks, and drafts incident timelines. It currently integrates with Slack, while direct integrations with PagerDuty and GitHub are in progress.

The assistant also supports scheduled background automations. Users can configure OpenWorker to run automated routines on a trigger, such as generating a daily morning briefing summarizing the previous day’s Slack messages and GitHub updates, compiling weekly progress reports, or monitoring specific communication channels. When running unattended background tasks, any action requiring approval is parked in an interactive, centralized inbox for the user to review later.

How OpenWorker is Built and Run from Source

The architecture of OpenWorker consists of a native desktop shell built on Tauri 2, which wraps a React-based frontend. This frontend interface communicates with a local Python FastAPI agent server running on the machine (binding by default to port 8765). Speech-to-text input is handled locally by a Rust-based sidecar process.

Developers who wish to run and build OpenWorker from source can do so by meeting the prerequisites of Python 3.10+, Node 20+, and the Rust toolchain via rustup.

Step-by-Step Build Instructions

1. Clone the repository and navigate to the project directory:

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

2. Run the one-time development environment bootstrap script to create the Python virtual environment under .venv (On Windows, execute this using Git Bash or WSL):

bash packaging/setup_dev_env.sh

3. Initialize and start the local agent server:

.venv/bin/openworker-server --cwd ~/some/project --port 8765

(On Windows systems, execute .venv\Scripts\openworker-server.exe instead)

4. Open a second terminal window, navigate to the React frontend folder, install dependencies, and launch the development environment:

cd surfaces/gui
npm install
npm run dev

To build and run the full desktop application shell rather than the browser-based interface, replace npm run dev with:

npm run tauri dev

The test suite can be verified by running .venv/bin/pytest for the backend, or running npm test and npm run e2e in the surfaces/gui directory to check GUI unit and hermetic end-to-end tests.

Operating System Availability and Installation

The desktop client is officially available for download on macOS (requiring Apple Silicon and macOS 12+) as a signed, notarized package that supports automatic updates.

While the project’s website lists the Windows version of the client as “coming soon”, a prebuilt Windows installer (Windows 10/11 x64) is already available for download on the project’s official GitHub repository. The developers note that these early Windows builds are not yet code-signed, meaning users will encounter a Microsoft Defender SmartScreen warning during installation while signing remains in progress.