Andrew Ng Launches OpenWorker for Local AI Coworkers

OpenWorker, Andrew Ng’s open-source framework for a desktop AI coworker, entered open beta with one clear design priority: keep your work on your own machine unless you deliberately decide otherwise. Published through Ng’s personal GitHub account alongside earlier tooling projects, it gives practitioners a self-hosted alternative to cloud-dependent AI assistants, one capable of handling finished-work tasks such as drafting documents, composing Slack replies, updating calendar entries, and processing a backlogged inbox. The architecture reflects a philosophy consistent with Ng’s other open-source work: composable tooling, flexible model selection, and no requirement to commit to a single vendor or cloud pipeline before you can start being productive.

What separates this from most desktop AI tools is the connector infrastructure. Rather than simulated read-only access to your apps, it authenticates through standard OAuth handshakes, which means the assistant has the same level of account access any trusted third-party app would receive after authorization. For practitioners evaluating local AI tooling, that distinction matters: the assistant can draft and act, not just read and suggest.

What OpenWorker Is

OpenWorker is an open-source, desktop-first framework that acts as a personal AI coworker, handling tasks across the productivity tools you already use rather than asking you to adapt your workflow to a new interface. Andrew Ng, who co-founded Coursera and Google Brain and built the DeepLearning.AI education platform, published the project through his personal GitHub account as an open beta. That means it is actively developed, open for community contribution, and available to any developer willing to test it against real workflows.

The core concept is straightforward. You install the desktop application, connect a model provider, authenticate the apps you want the assistant to work with, and then assign finished-work tasks. Finished-work means tasks with a concrete deliverable: a drafted reply ready to send, a calendar event created from a meeting note, a document assembled from scattered sources. The assistant does not just surface a suggestion and stop; it performs the action and reports back.

For anyone who has followed Ng’s GitHub output, the project fits an established pattern. His aisuite library established a lightweight, unified interface for calling models across multiple AI providers. OpenWorker extends that philosophy to the task layer: aisuite handles how the model is called, OpenWorker handles what the model is asked to do and which real-world tools it can act on.

Because the project is open-source, teams can inspect and audit the code before granting the assistant access to any sensitive system. That transparency is a meaningful advantage over proprietary AI assistant products, where the internal behavior of connectors is not visible to the team deploying them.

How the Local-First Architecture Works

The local-first design is an architectural choice, not a label. OpenWorker stores your conversation history, task context, and OAuth connector tokens on the device running the application. No third-party server operated by the project receives your data. When you ask the assistant to draft a reply to an email or pull notes together for a meeting document, the only external service involved is the model provider you have explicitly configured.

For teams working in environments with data residency requirements or internal data handling policies, that distinction is meaningful. A cloud-dependent AI assistant typically logs request payloads on infrastructure you do not control. A local-first setup keeps that data where your existing device security policies already apply.

The tradeoff is the same one that applies to any self-hosted software: you are responsible for keeping the application updated and securing the device it runs on. But for practitioners who have already accepted that tradeoff for other local tools, adding a local AI coworker is an extension of an existing posture rather than a new category of risk.

The desktop form factor also affects how the assistant integrates into a daily workflow. Running as a native application rather than a browser tab, it can maintain persistent context across work sessions and access local file resources without the repeated permission prompts that browser-based tools often introduce. OAuth tokens for connected apps are stored locally, removing the need to re-authenticate every session.

Supported AI Models

One of the more practically useful aspects of the project is its approach to model selection. The design avoids locking you into a single provider, which aligns directly with the aisuite abstraction layer Ng built separately. That library provides a common interface for calling models from providers including OpenAI and Anthropic, among others, and OpenWorker draws on the same multi-provider philosophy.

For teams that want to avoid sending any data to external model APIs, the project supports fully local inference. Ollama, a widely used tool for running open-weight models directly on desktop and laptop hardware, is compatible with this configuration. Pairing a local Ollama endpoint with OpenWorker gives you a fully on-device AI coworker where neither the application data nor the model inference leaves your machine.

The practical benefit of this separation is that you can match the model to the task and to the sensitivity of the data involved. A low-stakes drafting task might route through a fast cloud model for speed. A task touching confidential documents might run entirely locally. Because the model configuration lives in application settings rather than embedded in connector logic, swapping providers does not require rebuilding any part of the integration layer.

This also insulates the project from churn in the model market. As new models become available from any provider, teams can update their configuration and benefit immediately, without waiting for a project-level compatibility release.

App Integrations and Connectors

The connector system is where OpenWorker becomes a practical productivity tool rather than an interesting architecture demo. Each connector corresponds to a service the assistant can interact with, authenticated via a standard OAuth flow. When you connect a Slack workspace, a Gmail account, or Google Calendar, the assistant receives an OAuth token granting the permissions you approved during the handshake. Those permissions define the exact scope of what it can do.

The documented use cases map to real, high-friction workflow tasks. Inbox triage is a strong fit: the assistant can read, categorize, draft replies, and, depending on the permissions granted, send them. Calendar management works similarly, covering availability reads, event creation, and existing entry updates. For Slack, it can compose replies or draft messages for human review before sending. Document tasks cover drafting, summarization, and assembling materials from multiple local sources.

The open-source nature of the connector framework means teams can extend it. Developers can write custom connectors for internal tools not currently in the default list, either contributing them upstream or maintaining them in a private fork. That extensibility is one of the clearest advantages of the open-source approach over closed AI assistant products, which limit integration options to what the vendor has already built and approved.

Getting Started with OpenWorker

Installation starts at the OpenWorker on GitHub repository. Because the project is in open beta, the README is the primary reference for current setup steps, and it reflects the state of the code at any given point. The general setup flow follows a pattern familiar to anyone who has worked with Python-based desktop projects: clone the repository, install dependencies, configure your model provider, and launch the application.

There is no account creation with the OpenWorker project itself. Your model provider credentials, whether a cloud API key or a local Ollama endpoint URL, are the only external dependency required before the core functionality is available. This keeps the onboarding friction low and avoids the kind of service account setup that slows down evaluation of new tools.

Once the application is running, you add connectors for the services you want the assistant to work with. Each connector triggers an OAuth authorization screen for the corresponding service, which is the same browser-based UI you would see when connecting any trusted third-party application to your Google or Slack account. After authorization, the token is stored locally and the connector is active for subsequent tasks.

For teams considering wider deployment, reviewing the full connector implementation in the repository before granting any OAuth permissions is a reasonable due-diligence step. Understanding what permissions each connector requests, and why, is good practice with any AI tool that has write access to communication or calendar systems.

Practical Application

A realistic first project: clone the OpenWorker repo, add one cloud model provider key, and point a single connector (Slack or Google Calendar) at a low-stakes task such as drafting replies or proposing calendar holds, so you can watch how it turns a natural-language instruction into a concrete drafted action before granting it anything with real consequences. Once that loop is trustworthy, add a local Ollama endpoint for anything touching sensitive data and review each connector’s OAuth scopes, tightening them to the minimum the task needs before you widen access across a team.

Andrew Ng’s choice to keep OpenWorker open-source and desktop-first positions it as a practical foundation for teams that want AI coworker capabilities without surrendering control over their data or their toolchain. The project is early, but the combination of a local-first architecture, flexible model support, and OAuth-authenticated connectors addresses the real reasons practitioners have been reluctant to hand a cloud-dependent AI assistant write access to their communication and scheduling systems. It is worth tracking as the open beta matures and the connector ecosystem grows.

Frequently Asked Questions